From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 20:44:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcrt-0000Ms-34 for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:44:37 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEcrs-0002Gz-LW for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:44:37 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEcqX-0002tZ-Pn for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 01:43:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEcqP-0002st-I9 for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 01:43:05 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FEcqM-00075L-2k for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 01:43:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9A.A2C56542" Date: Wed, 1 Mar 2006 17:42:59 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062DFB@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 thread-index: AcY9mqPKV3DWJR/BQwej8K0jmcaxOw== From: "Kevin Wiggen" To: Received-SPF: none (maggie.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FEcqM-00075L-2k 81c4ff1aa19ab92be4fe2e01a0419e83 X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062DFB@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12155 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 01:43:13 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9A.A2C56542 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Section 15 makes "Display Name" a customizable live property. Putting on my SERVER hat, this seems easy (although not something that Xythos allows today). That being said, I am concerned about what this really means in the client world. The three most used Webdav Clients (that I know of at least) attempt to make a webdav server look and feel to the end user like a mounted file system. We can argue that this is not a good idea, but in practice, this is what has been implemented. The question for a client developer is "what to show to the end user, the display name or the URL." I would argue that most end users would want to see the display name (especially with servers that give names to resource URLs that are not friendly). Let's look at some scenarios (assuming that the client is a command line interface with display names being used as the directory/file names): =20 * /123/234/345.txt is a valid URL while the display names map to /foo/bar/fee.txt * /123/234/456.txt is also valid at /foo/bar/fuu.txt * mv fee.txt lala.txt =3D> proppatch (possibly giving the user 2 filenames that are the same, which most operating systems don't like) * mv fee.txt ../fee.txt =3D> move (it is possible this would fail because a different 345.txt already exists in 123, this would be very confusing to the user as they would have no clue WHY there move is failing) * mv fee.txt ../lala.txt =3D> move + proppatch (notice there is no way in Webdav to do this as a single transaction, it is possible this command could leave the user in a messed up state) =20 If we do have display name as separate, can it be non-unique? The whole fact that there are two names for things (with different rules) seems very confusing to end users. Of course a client could ignore display name completely (or make a new column for it in a directory listing detail) but that has lead to some usability issues for some end users as well. (Note that "some" of the MS webfolder clients show display name although they issue MOVE's to nonexistent resources if you try to rename them). =20 ------_=_NextPart_001_01C63D9A.A2C56542 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Section 15 makes “Display Name” a = customizable live property. Putting on my SERVER hat, this seems easy (although not something that Xythos allows today).  That being said, I am = concerned about what this really means in the client world.  The three most = used Webdav Clients (that I know of at least) attempt to make a webdav server = look and feel to the end user like a mounted file system.  We can argue = that this is not a good idea, but in practice, this is what has been = implemented.  The question for a client developer is “what to show to the end = user, the display name or the URL.”  I would argue that most end users = would want to see the display name (especially with servers that give names to resource URLs that are not friendly).  Let’s look at some = scenarios (assuming that the client is a command line interface with display names = being used as the directory/file names):

 

n       = /123/234/345.txt is a valid URL while the display names map to = /foo/bar/fee.txt

n       = /123/234/456.txt is also valid at /foo/bar/fuu.txt

n       = mv fee.txt lala.txt =3D> proppatch (possibly giving the user 2 filenames that = are the same, which most operating systems don’t = like)

n       = mv fee.txt ../fee.txt =3D> move (it is possible this would fail because a = different 345.txt already exists in 123, this would be very confusing to the user = as they would have no clue WHY there move is = failing)

n       = mv fee.txt ../lala.txt =3D> move + proppatch (notice there is no way in Webdav = to do this as a single transaction, it is possible this command could leave the = user in a messed up state)

 

If we do have display name as separate, can it be non-unique?  The whole fact that there are two names for things = (with different rules) seems very confusing to end users.  Of course a = client could ignore display name completely (or make a new column for it in a directory listing detail) but that has lead to some usability issues for = some end users as well.  (Note that “some” of the MS = webfolder clients show display name although they issue MOVE’s to = nonexistent resources if you try to rename them).

 

------_=_NextPart_001_01C63D9A.A2C56542-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 20:46:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEctK-00019p-O1 for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:46:06 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEctK-0002JC-Cw for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:46:06 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEct7-0004bc-KM for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 01:45:53 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FEct3-0004ar-Di for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 01:45:49 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FEcsV-00082F-J8 for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 01:45:48 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9A.CBC6F730" Date: Wed, 1 Mar 2006 17:44:07 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062DFC@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 thread-index: AcY9mszVwC1lSKtWQiCz+dWoAZt46w== From: "Kevin Wiggen" To: Received-SPF: none (aji.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FEcsV-00082F-J8 7051f97c460df93c7c2e1e9961e1bfda X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062DFC@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12156 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 01:45:53 +0000 X-Spam-Score: 2.0 (++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9A.CBC6F730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that the definition of Move, Copy, and Delete have been changed and the change is not backwardly compatible. In the old spec the entire operation succeeded or failed, now the spec says do your best. I am "ok" with this on a COPY, but I hate it for Move and Delete. Pretend I have a directory with 4 objects I can see in it and 1000 I can't, doing a Delete will simply destroy the stuff I have access to and not the entire tree. This could be very confusing to the user especially if there are resources they can't even SEE in the collection. (I could live with delete operating like this, although I find it confusing in some circumstances) Move IMHO needs to be all moved or not. Leaving a person with half of a move is almost always a terrible thing. In fact a half completed move will end up with MULTIPLE collection resources on the server (which could be illegal on the server). Thus the MOVE is really doing a COPY then DELETE except that I would guess most people want things like creation dates to be preserved. Has anyone been happy when a MOVE completes half way ever in their life?? A move should succeed or fail. ------_=_NextPart_001_01C63D9A.CBC6F730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that the definition of Move, Copy, and = Delete have been changed and the change is not backwardly compatible.  In the = old spec the entire operation succeeded or failed, now the spec says do your = best.  I am “ok” with this on a COPY, but I hate it for Move and Delete.  Pretend I have a directory with 4 objects I can see in it = and 1000 I can’t, doing a Delete will simply destroy the stuff I have = access to and not the entire tree.  This could be very confusing to the = user especially if there are resources they can’t even SEE in the collection.  (I could live with delete operating like this, = although I find it confusing in some circumstances)  Move IMHO needs to be all = moved or not.  Leaving a person with half of a move is almost always a = terrible thing.  In fact a half completed move will end up with MULTIPLE = collection resources on the server (which could be illegal on the server).  = Thus the MOVE is really doing a COPY then DELETE except that I would guess most = people want things like creation dates to be preserved.   Has anyone = been happy when a MOVE completes half way ever in their life??  A move = should succeed or fail.

------_=_NextPart_001_01C63D9A.CBC6F730-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 20:46:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEctS-0001Bz-7D for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:46:14 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEctQ-0002JI-Ug for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:46:14 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEctG-0004f3-RE for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 01:46:02 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FEctC-0004cC-8w for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 01:45:58 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FEct9-00087V-7x for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 01:45:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9B.0ABE80C0" Date: Wed, 1 Mar 2006 17:45:53 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062DFD@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 thread-index: AcY9mwvFoT7gk7/9R7+JSq+0+EOulg== From: "Kevin Wiggen" To: Received-SPF: none (aji.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1FEct9-00087V-7x e80e500113d76dab80def2450a1be803 X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062DFD@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12157 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 01:46:02 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9B.0ABE80C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 9.1, I know this isn't backwardly compatible but can't we make the default for PROPFIND =3D depth 0 and PROPNAME? Move, Copy, Delete aren't backward compatible (see other email), why not make this better. ------_=_NextPart_001_01C63D9B.0ABE80C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 9.1, I know this isn’t backwardly compatible but can’t we make the default for PROPFIND =3D depth 0 = and PROPNAME?  Move, Copy, Delete aren’t backward compatible (see = other email), why not make this better.

------_=_NextPart_001_01C63D9B.0ABE80C0-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 20:47:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcub-00023D-23 for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:47:25 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEcuZ-0002LF-Po for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:47:25 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEcuO-0004qs-6P for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 01:47:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEcuL-0004pn-CT for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 01:47:09 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FEcuI-0007m7-Sv for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 01:47:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9B.359A86A4" Date: Wed, 1 Mar 2006 17:47:05 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062E00@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518-- Dav Namespace thread-index: AcY9mzahDPmyDzMaSVWZk9GBKHF/yw== From: "Kevin Wiggen" To: Received-SPF: none (maggie.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FEcuI-0007m7-Sv a3974ac5c3c40f398d4179061036edae X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518-- Dav Namespace X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062E00@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12158 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 01:47:12 +0000 X-Spam-Score: 2.1 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9B.359A86A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How about a note somewhere that states people should NOT use the DAV: namespace =20 ------_=_NextPart_001_01C63D9B.359A86A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How about a note somewhere that states people should = NOT use the DAV: namespace

 

------_=_NextPart_001_01C63D9B.359A86A4-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 20:48:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcvY-0002yL-IB for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:48:24 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEcvX-0002U9-8Y for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 20:48:24 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEcvN-00050D-5n for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 01:48:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEcvI-0004zA-Dt for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 01:48:08 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FEcvF-0007to-SY for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 01:48:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9B.589324C2" Date: Wed, 1 Mar 2006 17:48:04 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062E01@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 -- Compliance Level thread-index: AcY9m1mPPmlSloLOR1+2sLBiTfBE0g== From: "Kevin Wiggen" To: Received-SPF: none (maggie.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FEcvF-0007to-SY fcb87926c13d094c4e69b024afaa53be X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518 -- Compliance Level X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062E01@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12159 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 01:48:13 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9B.589324C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since the actions of Move, Copy, Delete are not backwardly compatible, I don't agree with the Compliance Classes that are listed in the document. A client will probably want to know if it's talking to an OLDER server or a NEWER server before it takes action. Thus there needs to be a way for a client to tell. Also can a server implement both (again for backward compatibility) and thus let the client tell the server what type of MOVE it would like (adding a DAV: 1 header or something). Maybe DAV:1 =3D old RFC2518, DAV:2 =3D either RFC2518 w/ locks, and DAV:3 =3D = new RFC2518. I am not sure how a server can be 1 & 3 with the changes to MOVE/COPY/DELETE. ------_=_NextPart_001_01C63D9B.589324C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since the actions of Move, Copy, Delete are not = backwardly compatible, I don’t agree with the Compliance Classes that are = listed in the document.  A client will probably want to know if it’s = talking to an OLDER server or a NEWER server before it takes action.  Thus = there needs to be a way for a client to tell.  Also can a server = implement both (again for backward compatibility) and thus let the client tell the = server what type of MOVE it would like (adding a DAV: 1 header or = something). Maybe DAV:1 =3D old RFC2518, DAV:2 =3D either RFC2518 w/ locks, and DAV:3 =3D = new RFC2518.  I am not sure how a server can be 1 & 3 with the = changes to MOVE/COPY/DELETE.

------_=_NextPart_001_01C63D9B.589324C2-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 21:13:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEdEh-0006rL-LS for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 21:08:11 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEdCA-0003Jd-Jm for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 21:05:35 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEdBt-0000Fi-0Y for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 02:05:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEdBp-0000FA-Ru for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 02:05:13 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FEdBn-0007P6-W4 for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 02:05:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63D9D.BC398988" Date: Wed, 1 Mar 2006 18:05:10 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602062E14@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 -- XSS thread-index: AcY9nb0mHV4ixhpsT7CparGy7fWjEg== From: "Kevin Wiggen" To: Received-SPF: none (lisa.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEdBn-0007P6-W4 6784f67066350bf7dd249b9d6c21aef7 X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the "new" 2518 -- XSS X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602062E14@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12160 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 02:05:17 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e This is a multi-part message in MIME format. ------_=_NextPart_001_01C63D9D.BC398988 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Webdav needs to mention (and hopefully help) solve XSS attack problems. XSS (Cross-Site Scripting) is aimed at inserting active code in an HTML document to either abuse client-side active scripting holes, or to send privileged information (e.g. authentication/session cookies) to a previously unknown evil collection site.=20 =20 Webdav to date is content agnostic and allows for clients to retrieve and save information to/from a server. Unfortunately with Javascript and some knowledge of webdav, people can start to "hack" webdav servers to do unexpected things. Imagine I upload (using PUT) a HTML page that uses a browser xmlHTTP() to send a propfind to the server and then issue DELETE to everything I could find. By simply sending you a link to a URL on a common secured server, a browser will ask you to log in and then execute the javascript AS YOU. There are a lot of problems that smart people can create because the GET and other Webdav methods all originate from the same server. There are possible solutions (from scraping all input and not allowing certain content) but each always has some drawbacks (hey I want that javascript to do something important on my webpage, you can't cut it out when I upload it). =20 A separate but related issue is the MS "translate" issue. If someone uploads a jsp to a server, when they request it back, do they want the server to give the jsp? Or execute the jsp and return the result? =20 It seems that Webdav (web distributed AUTHORING and versioning) could take some steps to help out both of these areas. One line of thinking (notice I don't say solution) is to have Webdav separate the authoring world from the view (or execute world). In this world there would be two different namespaces (one for Webdav and one for GET/Execute). The webdav world would tell clients that it is meant for authoring and thus servers will NOT execute things like jsps and clients should NOT render and execute these objects (like javascript in HTML) in things like browsers but rather a edit mode (like HTML editor). In this way, Javascript should not be executed by HTML Editors and the namespace will be protected from malicious code stored in the sheep's clothing of HTML. Again I believe it important for Webdav to speak about these problems and try to give solutions. ------_=_NextPart_001_01C63D9D.BC398988 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Webdav needs to mention (and hopefully help) solve = XSS attack problems.  XSS (Cross-Site Scripting) is aimed at inserting = active code in an HTML document to either abuse client-side active scripting = holes, or to send privileged information (e.g. authentication/session cookies) to = a previously unknown evil collection site.

 

Webdav to date is content agnostic and allows for = clients to retrieve and save information to/from a server.  Unfortunately with Javascript and some knowledge of webdav, people can start to = “hack” webdav servers to do unexpected things.  Imagine I upload (using = PUT) a HTML page that uses a browser xmlHTTP() to send a propfind to the server = and then issue DELETE to everything I could find.  By simply sending = you a link to a URL on a common secured server, a browser will ask you to log = in and then execute the javascript AS YOU.  There are a lot of problems = that smart people can create because the GET and other Webdav methods all = originate from the same server.  There are possible solutions (from scraping = all input and not allowing certain content) but each always has some drawbacks = (hey I want that javascript to do something important on my webpage, you = can’t cut it out when I upload it). 

A separate but related issue is the MS “translate” = issue.  If someone uploads a jsp to a server, when they request it back, do they = want the server to give the jsp? Or execute the jsp and return the result?  =

It seems that Webdav (web distributed AUTHORING and versioning) could = take some steps to help out both of these areas.  One line of thinking = (notice I don’t say solution) is to have Webdav separate the authoring world = from the view (or execute world).  In this world there would be two = different namespaces (one for Webdav and one for GET/Execute).  The webdav = world would tell clients that it is meant for authoring and thus servers will = NOT execute things like jsps and clients should NOT render and execute these objects (like javascript in HTML) in things like browsers but rather a = edit mode (like HTML editor).  In this way, Javascript should not be = executed by HTML Editors and the namespace will be protected from malicious code = stored in the sheep’s clothing of HTML.

Again I believe it important for Webdav to speak about these problems = and try to give solutions.

------_=_NextPart_001_01C63D9D.BC398988-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 22:34:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeag-0004NA-Mc for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 22:34:58 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEeag-0007bf-88 for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 22:34:58 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEeZi-0007SI-IP for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 03:33:58 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FEeZX-0007Qt-TG; Thu, 02 Mar 2006 03:33:48 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.50) id 1FEeZT-0005DW-Gf; Thu, 02 Mar 2006 03:33:46 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k223XdbA018145; Wed, 1 Mar 2006 22:33:39 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k223XdTf125644; Wed, 1 Mar 2006 22:33:39 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k223Xd8D011321; Wed, 1 Mar 2006 22:33:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k223XdjV011318; Wed, 1 Mar 2006 22:33:39 -0500 In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062DFC@NSNOVPS00411.nacio.xythos.com> To: "Kevin Wiggen" 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 From: Geoffrey M Clemm Message-ID: Date: Wed, 1 Mar 2006 22:33:45 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF124 | January 12, 2006) at 03/01/2006 22:33:38, Serialize complete at 03/01/2006 22:33:38 Content-Type: multipart/alternative; boundary="=_alternative 00138FEC85257125_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1FEeZT-0005DW-Gf 6e8b185f496c4cedff9ea27719562150 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/OF80954C8D.4A2B0633-ON85257125.0012B5D4-85257125.0013905B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12161 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 03:33:58 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 This is a multipart message in MIME format. --=_alternative 00138FEC85257125_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Both COPY and DELETE are explicitly defined by 2518 to be best effort (at=20 the SHOULD level), and not all or nothing.=20 >From the definition of COPY: "After detecting an error, the COPY operation SHOULD try to finish as much = of the original copy operation as possible (i.e., the server should still attempt to copy other = subtrees and their members, that are not descendents of an error-causing collection)." >From the definition of MOVE: "after detecting the error, the move operation SHOULD try to finish as much of the original move as possible (i.e., the=20 server should still attempt to move other subtrees and the resources identified by their members, that=20 are not descendents of an errorcausing collection)." Although DELETE is not that specific, the language is completely=20 compatible with partial delete (and if you ask any of the authors of 2518, = they will confirm that DELETE, like COPY and MOVE, was intended to be best = effort). Servers that want to support atomic MOVE/DELETE should support the bind=20 protocol's REBIND/UNBIND operations, which are guaranteed to be all or=20 nothing. Cheers, Geoff Kevin wrote on 03/01/2006 08:44:07 PM: > It seems that the definition of Move, Copy, and Delete have been=20 > changed and the change is not backwardly compatible. In the old=20 > spec the entire operation succeeded or failed, now the spec says do=20 > your best. I am ?ok? with this on a COPY, but I hate it for Move=20 > and Delete. Pretend I have a directory with 4 objects I can see in=20 > it and 1000 I can?t, doing a Delete will simply destroy the stuff I=20 > have access to and not the entire tree. This could be very=20 > confusing to the user especially if there are resources they can?t=20 > even SEE in the collection. (I could live with delete operating=20 > like this, although I find it confusing in some circumstances) Move > IMHO needs to be all moved or not. Leaving a person with half of a=20 > move is almost always a terrible thing. In fact a half completed=20 > move will end up with MULTIPLE collection resources on the server=20 > (which could be illegal on the server). Thus the MOVE is really=20 > doing a COPY then DELETE except that I would guess most people want=20 > things like creation dates to be preserved. Has anyone been happy=20 > when a MOVE completes half way ever in their life?? A move should=20 > succeed or fail. --=_alternative 00138FEC85257125_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Both COPY and DELETE are explicitly defined by 2518 to be best effort (at the SHOULD level),
and not all or nothing.  

From the definition of COPY:

"After detecting an error, the COPY operation SHOULD try to finish as much of the original copy
operation as possible (i.e., the server should still attempt to copy other subtrees and their members, that
are not descendents of an error-causing collection).= "

From the definition of MOVE:

"after detecting the error, the move operation<= /tt>
SHOULD try to finish as much of the original move as possible (i.e., the server should still attempt to
move other subtrees and the resources identified by their members, that are not descendents of an errorcausing
collection)."

Although DELETE is not that specific, the language is completely compatible with partial delete (and if you ask any of the authors of 2518, they will confirm that DELETE, like COPY and MOVE, was intended to be best effort).

Servers that want to support atomic MOVE/DELETE shou= ld support the bind protocol's REBIND/UNBIND operations, which are guaranteed to be all or nothing.

Cheers,
Geoff

Kevin wrote on 03/01/2006 08:44:07 PM:
> It seems that the definition of Move, Copy, and Delete have been
> changed and the change is not backwardly compatible.  In the old
> spec the entire operation succeeded or failed, now the spec says do
> your best.  I am “ok” with this on a COPY, but I hate= it for Move
> and Delete.  Pretend I have a directory with 4 objects I can see in
> it and 1000 I can’t, doing a Delete will simply destroy the stuff I
> have access to and not the entire tree.  This could be very
> confusing to the user especially if there are resources they can’= ;t
> even SEE in the collection.  (I could live with delete operating
> like this, although I find it confusing in some circumstances)  M= ove
> IMHO needs to be all moved or not.  Leaving a person with half of a
> move is almost always a terrible thing.  In fact a half completed
> move will end up with MULTIPLE collection resources on the server
> (which could be illegal on the server).  Thus the MOVE is really
> doing a COPY then DELETE except that I would guess most people want
> things like creation dates to be preserved.   Has anyone been happy
> when a MOVE completes half way ever in their life??  A move should
> succeed or fail. --=_alternative 00138FEC85257125_=-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 01 22:54:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEet9-0006WS-Hr for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 22:54:03 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEet8-00007n-Vz for webdav-archive@lists.ietf.org; Wed, 01 Mar 2006 22:54:03 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEesi-0003CT-0e for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 03:53:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEesZ-0003BM-8h; Thu, 02 Mar 2006 03:53:27 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by maggie.w3.org with esmtp (Exim 4.50) id 1FEesV-0000EU-1P; Thu, 02 Mar 2006 03:53:26 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k223rLMe032500; Wed, 1 Mar 2006 22:53:21 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k223rLTf119108; Wed, 1 Mar 2006 22:53:21 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k223rLob005328; Wed, 1 Mar 2006 22:53:21 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k223rLvA005325; Wed, 1 Mar 2006 22:53:21 -0500 In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062DFB@NSNOVPS00411.nacio.xythos.com> To: "Kevin Wiggen" 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 From: Geoffrey M Clemm Message-ID: Date: Wed, 1 Mar 2006 22:53:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF124 | January 12, 2006) at 03/01/2006 22:53:20, Serialize complete at 03/01/2006 22:53:20 Content-Type: multipart/alternative; boundary="=_alternative 00155D2485257125_=" Received-SPF: none (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1FEesV-0000EU-1P 56705fb8a821051f606ab7d00001df3d X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/OFA2744FFE.589C4B3E-ON85257125.0013ACED-85257125.00155DB5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12162 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 03:53:36 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 This is a multipart message in MIME format. --=_alternative 00155D2485257125_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Kevin wrote on 03/01/2006 08:42:59 PM: > Section 15 makes ?Display Name? a customizable live property.=20 > Putting on my SERVER hat, this seems easy (although not something=20 > that Xythos allows today). That being said, I am concerned about=20 > what this really means in the client world. The three most used=20 > Webdav Clients (that I know of at least) attempt to make a webdav=20 > server look and feel to the end user like a mounted file system. We > can argue that this is not a good idea, but in practice, this is=20 > what has been implemented. The question for a client developer is=20 > ?what to show to the end user, the display name or the URL.? That depends on what the end user is going to do with it. If they are going to copy the string and paste it into their web browser, then you'd better show them the URL. If they are just going to look at the string, then the display name is better. =20 > I=20 > would argue that most end users would want to see the display name=20 > (especially with servers that give names to resource URLs that are=20 > not friendly).=20 They are two different strings, with different properties, so in some cases they want one, and in other cases, they want to other. > Let?s look at some scenarios (assuming that the=20 > client is a command line interface with display names being used as=20 > the directory/file names): In this scenario, they clearly want the URI (if "being used as the directory/file names", you mean that they want to be able to use those strings to locate the resources). > n /123/234/345.txt is a valid URL while the display names map=20 > to /foo/bar/fee.txt Concatenating the display names, separated by slashes, has no guarantee of producing anything sensible. The displaynames can contain slashes and spaces and random other punctuation (and non-legal URL characters). > n /123/234/456.txt is also valid at /foo/bar/fuu.txt I don't know what you mean by "is valid at". > n mv fee.txt lala.txt =3D> proppatch (possibly giving the user 2 > filenames that are the same, which most operating systems don?t like) You cannot use the concatenated displaynames as a filename. If you want a pathname, the only sensible choice is to use the URI. > If we do have display name as separate, can it be non-unique? Yes. There was never any guarantee of uniqueness. > The=20 > whole fact that there are two names for things (with different=20 > rules) seems very confusing to end users.=20 There are always many different names for things. There are pathnames, that allow you to locate an object, and there are descriptive names, that do not allow you to locate an object, but do allow you to describe the object in a less constrained way than a pathname segment. > Of course a client could=20 > ignore display name completely (or make a new column for it in a=20 > directory listing detail) but that has lead to some usability issues > for some end users as well. If a client doesn't want to display the displayname, that is up to the client. There are many repositories for which a displayname is very useful (especially those which have large flat collections, where the resources in the collection have obscure last segments, such as UUIDs). > (Note that ?some? of the MS webfolder=20 > clients show display name although they issue MOVE?s to nonexistent=20 > resources if you try to rename them). Poorly written or buggy clients will always exist. Cheers, Geoff --=_alternative 00155D2485257125_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Kevin wrote on 03/01/2006 08:42:59 PM:

> Section 15 makes “Display Name” a customizable live proper= ty.
> Putting on my SERVER hat, this seems easy (alth= ough not something
> that Xythos allows today).  That being said, I am concerned about
> what this really means in the client world.  The three most used
> Webdav Clients (that I know of at least) attempt to make a webdav
> server look and feel to the end user like a mounted file system.  = ;We
> can argue that this is not a good idea, but in practice, this is
> what has been implemented.  The question for a client developer is
> “what to show to the end user, the display name or the URL.̶= 1;

That depends on what the end user is going to do with it.
If they are going to copy the string and paste it into their web browser,
then you'd better show them the URL.  If they are just going to look at
the string, then the display name is better.
 
> I
> would argue that most end users would want to see the display name
> (especially with servers that give names to resource URLs that are
> not friendly).  

They are two different strings, with different prope= rties, so in some
cases they want one, and in other cases, they want to other.

> Let’s look at some scenarios (assuming th= at the
> client is a command line interface with display names being used as
> the directory/file names):

In this scenario, they clearly want the URI (if &quo= t;being used as the
directory/file names", you mean that they want to be able to use those
strings to locate the resources).

> n       /123/234/345.txt is a valid URL while the display names map
> to /foo/bar/fee.txt

Concatenating the display names, separated by slashe= s, has no guarantee
of producing anything sensible.  The displaynam= es can contain slashes and
spaces and random other punctuation (and non-legal URL characters).

> n       /123/234/456.txt is also valid at /foo/bar/fuu.txt

I don't know what you mean by "is valid at"= ;.

> n       mv fee.txt lala.txt =3D&= gt; proppatch (possibly giving the user 2
> filenames that are the same, which most operating systems don’t = like)

You cannot use the concatenated displaynames as a filename.
If you want a pathname, the only sensible choice is to use the URI.

> If we do have display name as separate, can it be non-unique?

Yes.  There was never any guarantee of uniquene= ss.

> The
> whole fact that there are two names for things (with different
> rules) seems very confusing to end users.  

There are always many different names for things.  There are pathnames,
that allow you to locate an object, and there are descriptive names,
that do not allow you to locate an object, but do allow you to describe
the object in a less constrained way than a pathname segment.

> Of course a client could
> ignore display name completely (or make a new column for it in a
> directory listing detail) but that has lead to some usability issues > for some end users as well.

If a client doesn't want to display the displayname, that is up to the
client.  There are many repositories for which a displayname is very
useful (especially those which have large flat colle= ctions, where the
resources in the collection have obscure last segmen= ts, such as UUIDs).

> (Note that “some” of the MS webfold= er
> clients show display name although they issue MOVE’s to nonexist= ent
> resources if you try to rename them).

Poorly written or buggy clients will always exist.

Cheers,
Geoff
--=_alternative 00155D2485257125_=-- From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 03:14:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEiws-00008p-N9 for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:14:10 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEiwr-0001aN-CR for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:14:10 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEivw-00077c-PB for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:13:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEivo-00076u-Ap for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:13:04 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1FEivk-0003Co-Vf for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:13:03 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:12:59 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp031) with SMTP; 02 Mar 2006 09:12:59 +0100 X-Authenticated: #1915285 Message-ID: <4406A8D3.5000602@gmx.de> Date: Thu, 02 Mar 2006 09:12:03 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HTTP Working Group , WebDAV , discuss@apps.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEivk-0003Co-Vf 193f3979444b36ba354f079b318856c2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-whitehead-http-etag-00.txt X-Archived-At: http://www.w3.org/mid/4406A8D3.5000602@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12163 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:13:12 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi, while working on the revision of RFC2518 (WebDAV), the WebDAV working group came to the conclusion that what HTTP says about returning ETag headers in write operations (such as PUT) is insufficient. Jim's draft summarizes the various issues and also contains some thoughts about what to do, from which we'd like to start a discussion on the HTTP mailing list (). Feedback appreciated, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Design Considerations for State Identifiers in HTTP and WebDAV > Author(s) : J. Whitehead > Filename : draft-whitehead-http-etag-00.txt > Pages : 13 > Date : 2006-3-1 > > This document discusses design considerations for state identifiers > in the Hypertext Transfer Protocol (HTTP) and related protocols such > as WebDAV. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.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-whitehead-http-etag-00.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-whitehead-http-etag-00.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 03:21:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEj3X-0008U5-3k for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:21:03 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEj3T-0001vM-PS for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:21:03 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEj3A-00018C-9A for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:20:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEj35-00017S-5i for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:20:35 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FEj2z-0005Yl-SJ for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:20:33 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:20:26 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp034) with SMTP; 02 Mar 2006 09:20:26 +0100 X-Authenticated: #1915285 Message-ID: <4406AA90.504@gmx.de> Date: Thu, 02 Mar 2006 09:19:28 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602062DFB@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062DFB@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FEj2z-0005Yl-SJ 4bb7b662db1d2a274d18c7ab4d9ad9a6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/4406AA90.504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12164 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:20:40 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Kevin Wiggen wrote: > > > Section 15 makes “Display Name” a customizable live property. Putting on ...clarifies. As far as I can tell, this has always been the intent. Implementing it as a protected property that always has the same value as the last path segment (after un-escaping), such as in IIS, simply is completely useless for clients (because it just mirrors information that is already there). > my SERVER hat, this seems easy (although not something that Xythos > allows today). That being said, I am concerned about what this really > means in the client world. The three most used Webdav Clients (that I > know of at least) attempt to make a webdav server look and feel to the > end user like a mounted file system. We can argue that this is not a > good idea, but in practice, this is what has been implemented. The > question for a client developer is “what to show to the end user, the > display name or the URL.” I would argue that most end users would want The URL. > to see the display name (especially with servers that give names to > resource URLs that are not friendly). Let’s look at some scenarios > (assuming that the client is a command line interface with display names > being used as the directory/file names): > > > > n /123/234/345.txt is a valid URL while the display names map to > /foo/bar/fee.txt > > n /123/234/456.txt is also valid at /foo/bar/fuu.txt > > n mv fee.txt lala.txt => proppatch (possibly giving the user 2 > filenames that are the same, which most operating systems don’t like) > > n mv fee.txt ../fee.txt => move (it is possible this would fail > because a different 345.txt already exists in 123, this would be very > confusing to the user as they would have no clue WHY there move is failing) > > n mv fee.txt ../lala.txt => move + proppatch (notice there is no > way in Webdav to do this as a single transaction, it is possible this > command could leave the user in a messed up state) > > > > If we do have display name as separate, can it be non-unique? The whole Yes. It's a description, not an identifier. BTW: lots of servers have been implementing it this way for years, so this shouldn't come as a surprise to clients... > fact that there are two names for things (with different rules) seems > very confusing to end users. Of course a client could ignore display > name completely (or make a new column for it in a directory listing > detail) but that has lead to some usability issues for some end users as > well. (Note that “some” of the MS webfolder clients show display name > although they issue MOVE’s to nonexistent resources if you try to rename > them). Which has been reported as a bug and indeed been fixed. As a matter of fact, I think this is the only case where I've been able to convince Microsoft in immediately fixing something in the client :-). See and . Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 03:24:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEj7C-00071B-Rm for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:24:50 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEj7B-0002BF-Kd for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:24:50 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEj6z-0001YF-UN for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:24:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEj6v-0001XM-RX for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:24:33 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1FEj6t-0006Ip-Vq for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:24:33 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:24:30 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp016) with SMTP; 02 Mar 2006 09:24:30 +0100 X-Authenticated: #1915285 Message-ID: <4406AB85.7090603@gmx.de> Date: Thu, 02 Mar 2006 09:23:33 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602062DFD@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062DFD@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEj6t-0006Ip-Vq 8094344ec5cad9c3b322c90ed3151842 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/4406AB85.7090603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12165 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:24:37 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Kevin Wiggen wrote: > In section 9.1, I know this isn’t backwardly compatible but can’t we > make the default for PROPFIND = depth 0 and PROPNAME? Move, Copy, > Delete aren’t backward compatible (see other email), why not make this > better. MOVE, COPY and DELETE *are* backwards compatible. And that's exactly the reason why we didn't make changes like the one you just proposed: old clients should be able to interact with new servers, and the other way around. Note that this is the main reason why I'm opposed to change the LOCK refresh marshalling. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 03:27:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEj9i-0002wp-Hp for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:27:26 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEj9f-0002KJ-AO for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:27:26 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEj9N-0002EW-Mo for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:27:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEj9K-0002Dw-4z for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:27:02 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1FEj9I-0006tn-Aq for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:27:02 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:26:59 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp037) with SMTP; 02 Mar 2006 09:26:59 +0100 X-Authenticated: #1915285 Message-ID: <4406AC1C.6070001@gmx.de> Date: Thu, 02 Mar 2006 09:26:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602062E00@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062E00@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEj9I-0006tn-Aq e36a7344f26695dbb5486efe1028934f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518-- Dav Namespace X-Archived-At: http://www.w3.org/mid/4406AC1C.6070001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12166 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:27:05 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Kevin Wiggen wrote: > How about a note somewhere that states people should NOT use the DAV: > namespace We currently have the statement in , but maybe that should be expanded or (gasp!) repeated somewhere else. Any particular suggestion where to say that (property definitions?). Best regards, Julian (and thanks for the last-call comments!) From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 03:34:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEjGw-0003k5-7n for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:34:54 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEjGv-0002oR-S3 for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:34:54 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEjGf-00058O-I3 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:34:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEjGZ-00057V-Dd for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:34:31 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1FEjGX-0000L4-0g for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:34:31 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:34:28 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp027) with SMTP; 02 Mar 2006 09:34:28 +0100 X-Authenticated: #1915285 Message-ID: <4406ADDC.1020201@gmx.de> Date: Thu, 02 Mar 2006 09:33:32 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602062E14@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062E14@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEjGX-0000L4-0g 49f23518174f5fb360c1fdbde20169a6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 -- XSS X-Archived-At: http://www.w3.org/mid/4406ADDC.1020201@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12168 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:34:37 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Kevin Wiggen wrote: > Webdav needs to mention (and hopefully help) solve XSS attack problems. > XSS (Cross-Site Scripting) is aimed at inserting active code in an HTML > document to either abuse client-side active scripting holes, or to send > privileged information (e.g. authentication/session cookies) to a > previously unknown evil collection site. We currently have , which says: "HTTP has the ability to host programs which are executed on client machines. These programs can take many forms including web scripts, executables, plug in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs yet often WebDAV is used in contexts where a wide range of users can publish documents on a server. The server might not have a close trust relationship with the author that is publishing the document. Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server." I don't think that saying more would be good. This is a general problem *not* specific to WebDAV. > Webdav to date is content agnostic and allows for clients to retrieve > and save information to/from a server. Unfortunately with Javascript > and some knowledge of webdav, people can start to “hack” webdav servers > to do unexpected things. Imagine I upload (using PUT) a HTML page that > uses a browser xmlHTTP() to send a propfind to the server and then issue > DELETE to everything I could find. By simply sending you a link to a > URL on a common secured server, a browser will ask you to log in and > then execute the javascript AS YOU. There are a lot of problems that > smart people can create because the GET and other Webdav methods all > originate from the same server. There are possible solutions (from > scraping all input and not allowing certain content) but each always has > some drawbacks (hey I want that javascript to do something important on > my webpage, you can’t cut it out when I upload it). So do you have any specific proposal about what to do? > A separate but related issue is the MS “translate” issue. If someone > uploads a jsp to a server, when they request it back, do they want the > server to give the jsp? Or execute the jsp and return the result? > > It seems that Webdav (web distributed AUTHORING and versioning) could > take some steps to help out both of these areas. One line of thinking > (notice I don’t say solution) is to have Webdav separate the authoring > world from the view (or execute world). In this world there would be > two different namespaces (one for Webdav and one for GET/Execute). The > webdav world would tell clients that it is meant for authoring and thus > servers will NOT execute things like jsps and clients should NOT render > and execute these objects (like javascript in HTML) in things like > browsers but rather a edit mode (like HTML editor). In this way, > Javascript should not be executed by HTML Editors and the namespace will > be protected from malicious code stored in the sheep’s clothing of HTML. That's basically the question the DAV:source property was supposed to solve. It has been removed from the spec due to a complete lack of implementation experience. It's an interesting and important topic, but it was impossible to solve within the time that has been allocated to us. > Again I believe it important for Webdav to speak about these problems > and try to give solutions. > Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 04:47:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkOp-0007qm-2t for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 04:47:07 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEjEa-0002hU-H0 for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:32:28 -0500 Received: from frink.w3.org ([128.30.52.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEjAd-0005O6-Ja for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 03:28:23 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEjAR-0002QW-Aq for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 08:28:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEjAN-0002Pr-Tq for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 08:28:07 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1FEjAM-0007CZ-AS for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 08:28:07 +0000 Received: (qmail invoked by alias); 02 Mar 2006 08:28:05 -0000 Received: from p508FB4A1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.180.161] by mail.gmx.net (mp039) with SMTP; 02 Mar 2006 09:28:05 +0100 X-Authenticated: #1915285 Message-ID: <4406AC5C.4000202@gmx.de> Date: Thu, 02 Mar 2006 09:27:08 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602062E01@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602062E01@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEjAM-0007CZ-AS 051e6a515c0b3de378915a9d5fc17a25 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 -- Compliance Level X-Archived-At: http://www.w3.org/mid/4406AC5C.4000202@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12167 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 08:28:11 +0000 X-Spam-Score: 0.8 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Kevin Wiggen wrote: > Since the actions of Move, Copy, Delete are not backwardly compatible, I > don’t agree with the Compliance Classes that are listed in the > document. A client will probably want to know if it’s talking to an > OLDER server or a NEWER server before it takes action. Thus there needs > to be a way for a client to tell. Also can a server implement both > (again for backward compatibility) and thus let the client tell the > server what type of MOVE it would like (adding a DAV: 1 header or > something). Maybe DAV:1 = old RFC2518, DAV:2 = either RFC2518 w/ locks, > and DAV:3 = new RFC2518. I am not sure how a server can be 1 & 3 with > the changes to MOVE/COPY/DELETE. Again, there are no changes for MOVE/COPY/DELETE, and older clients are supposed to work with newer servers. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 17:31:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwKb-00062m-J8 for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 17:31:33 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwKa-0000TQ-3O for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 17:31:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEwIj-0005ck-Ms for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 22:29:37 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FEwIa-0005cA-Or for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 22:29:29 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FEwIW-0000wO-CH for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 22:29:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 14:29:19 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC60206304C@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518--Display Name thread-index: AcY+Cd3U6mEKMZMoQqOAh83Dk5/w0wAPTlnQ From: "Kevin Wiggen" To: "Julian Reschke" Cc: Received-SPF: none (aji.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FEwIW-0000wO-CH f1995923ba1d99a9dc8b08dbcc6a3d7d X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC60206304C@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12169 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 22:29:37 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Ok let me make sure I understand both Julian and Geoff correctly. Assume I am the architect of Microsoft Web Folders (a Webdav client). I am using Webdav to represent a file system to the user and want people to use windows explorer like functionality to be able to move/copy/delete/put/rename/etc files on a web server. =20 When my client does a Propfind to the server to request information to show to the user, I MUST use the last segment of the URL in my display to show the name of the resource. It is possible for me to show display name somewhere else (in a details screen or in a column next to last update date), but the name of the resource shown to the user should be from the URL. Thus if my client attempts to view one of Geoff's repositories where "those which have large flat collections, where the resources in the collection have obscure last segments, such as UUIDs," we will be showing UUID in the interface and display name somewhere else. I think there is confusion over what is expected and possible by file system like Webdav clients (which I would argue are the most used Webdav clients in the world as MS and Apple have them native) and some clarity in the spec around the use of display name would be nice. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Thursday, March 02, 2006 12:19 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 Kevin Wiggen wrote: > =20 >=20 > Section 15 makes "Display Name" a customizable live property. Putting on=20 ...clarifies. As far as I can tell, this has always been the intent.=20 Implementing it as a protected property that always has the same value=20 as the last path segment (after un-escaping), such as in IIS, simply is=20 completely useless for clients (because it just mirrors information that is already there). > my SERVER hat, this seems easy (although not something that Xythos=20 > allows today). That being said, I am concerned about what this really > means in the client world. The three most used Webdav Clients (that I > know of at least) attempt to make a webdav server look and feel to the > end user like a mounted file system. We can argue that this is not a=20 > good idea, but in practice, this is what has been implemented. The=20 > question for a client developer is "what to show to the end user, the=20 > display name or the URL." I would argue that most end users would want=20 The URL. > to see the display name (especially with servers that give names to=20 > resource URLs that are not friendly). Let's look at some scenarios=20 > (assuming that the client is a command line interface with display names=20 > being used as the directory/file names): >=20 > =20 >=20 > n /123/234/345.txt is a valid URL while the display names map to > /foo/bar/fee.txt >=20 > n /123/234/456.txt is also valid at /foo/bar/fuu.txt >=20 > n mv fee.txt lala.txt =3D> proppatch (possibly giving the user 2 = > filenames that are the same, which most operating systems don't like) >=20 > n mv fee.txt ../fee.txt =3D> move (it is possible this would = fail=20 > because a different 345.txt already exists in 123, this would be very=20 > confusing to the user as they would have no clue WHY there move is failing) >=20 > n mv fee.txt ../lala.txt =3D> move + proppatch (notice there is = no > way in Webdav to do this as a single transaction, it is possible this=20 > command could leave the user in a messed up state) >=20 > =20 >=20 > If we do have display name as separate, can it be non-unique? The whole=20 Yes. It's a description, not an identifier. BTW: lots of servers have been implementing it this way for years, so=20 this shouldn't come as a surprise to clients... > fact that there are two names for things (with different rules) seems=20 > very confusing to end users. Of course a client could ignore display=20 > name completely (or make a new column for it in a directory listing=20 > detail) but that has lead to some usability issues for some end users as=20 > well. (Note that "some" of the MS webfolder clients show display name > although they issue MOVE's to nonexistent resources if you try to rename=20 > them). Which has been reported as a bug and indeed been fixed. As a matter of=20 fact, I think this is the only case where I've been able to convince=20 Microsoft in immediately fixing something in the client :-). See=20 =20 and=20 . Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 17:43:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwVp-00065x-IQ for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 17:43:09 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwVo-0000sk-5I for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 17:43:09 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEwVS-0008K8-HZ for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 22:42:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEwVN-0008JH-CC for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 22:42:41 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FEwVK-0005Mj-Bp for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 22:42:40 +0000 Received: (qmail invoked by alias); 02 Mar 2006 22:42:37 -0000 Received: from p508F941C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.28] by mail.gmx.net (mp016) with SMTP; 02 Mar 2006 23:42:37 +0100 X-Authenticated: #1915285 Message-ID: <440774A3.6020506@gmx.de> Date: Thu, 02 Mar 2006 23:41:39 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC60206304C@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC60206304C@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FEwVK-0005Mj-Bp 11970a59304991aef7faa4f15bfa7809 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/440774A3.6020506@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12170 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 22:42:46 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Kevin Wiggen wrote: > > Ok let me make sure I understand both Julian and Geoff correctly. > > Assume I am the architect of Microsoft Web Folders (a Webdav client). I > am using Webdav to represent a file system to the user and want people > to use windows explorer like functionality to be able to > move/copy/delete/put/rename/etc files on a web server. > > When my client does a Propfind to the server to request information to > show to the user, I MUST use the last segment of the URL in my display > to show the name of the resource. It is possible for me to show display > name somewhere else (in a details screen or in a column next to last > update date), but the name of the resource shown to the user should be > from the URL. > > Thus if my client attempts to view one of Geoff's repositories where > "those which have large flat collections, where the resources in the > collection have obscure last segments, such as UUIDs," we will be > showing UUID in the interface and display name somewhere else. > > I think there is confusion over what is expected and possible by file > system like Webdav clients (which I would argue are the most used Webdav > clients in the world as MS and Apple have them native) and some clarity > in the spec around the use of display name would be nice. > > Kevin Kevin, I'm not sure exactly what you're asking for. DAV:displayname never had any guarantee to be unique within a collection, many servers are implemented that way, and no generic client I'm aware of gets this wrong (in the latest version). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 18:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwtM-0001YF-Qo for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:07:28 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwtL-000230-Dc for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:07:28 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEwsr-0004ch-Op for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 23:06:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FEwsh-0004bi-Uo for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 23:06:47 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FEwsf-0006rn-S1 for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 23:06:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 15:06:44 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC602063076@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518--Display Name thread-index: AcY+SpvRrgZnbOd0T7GQsBPW7zlWwwAAfjFQ From: "Kevin Wiggen" To: "Julian Reschke" Cc: Received-SPF: none (lisa.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FEwsf-0006rn-S1 3f4aa7b034d7f21f4b0526b78f939da0 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC602063076@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12171 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 23:06:57 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Not sure you understood my question. I would like readers of the spec to understand the difference between a URL and Display Name and understand how that operates in the real world (MS Webfolders, Apple OSX, Xythos). Webdav clients that make Webdav server look like file systems should expect the URL to be used in displays to users and NOT display name. As client developers we often get into conflict on this point. We of course can add a column in windows explorer to SHOW the display name, but the URL is the correct item to show users in this generic Webdav client. -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Thursday, March 02, 2006 2:42 PM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name Kevin Wiggen wrote: >=20 > Ok let me make sure I understand both Julian and Geoff correctly. >=20 > Assume I am the architect of Microsoft Web Folders (a Webdav client). I > am using Webdav to represent a file system to the user and want people > to use windows explorer like functionality to be able to > move/copy/delete/put/rename/etc files on a web server. =20 >=20 > When my client does a Propfind to the server to request information to > show to the user, I MUST use the last segment of the URL in my display > to show the name of the resource. It is possible for me to show display > name somewhere else (in a details screen or in a column next to last > update date), but the name of the resource shown to the user should be > from the URL. >=20 > Thus if my client attempts to view one of Geoff's repositories where > "those which have large flat collections, where the resources in the > collection have obscure last segments, such as UUIDs," we will be > showing UUID in the interface and display name somewhere else. >=20 > I think there is confusion over what is expected and possible by file > system like Webdav clients (which I would argue are the most used Webdav > clients in the world as MS and Apple have them native) and some clarity > in the spec around the use of display name would be nice. >=20 > Kevin Kevin, I'm not sure exactly what you're asking for. DAV:displayname never had=20 any guarantee to be unique within a collection, many servers are=20 implemented that way, and no generic client I'm aware of gets this wrong (in the latest version). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 18:19:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx52-0004sN-3Z for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:19:32 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEx50-0003Kv-Ho for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:19:32 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEx4i-0007hO-12 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 23:19:12 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FEx4O-0007fH-P1; Thu, 02 Mar 2006 23:18:53 +0000 Received: from exprod6og8.obsmtp.com ([64.18.1.128]) by aji.w3.org with smtp (Exim 4.50) id 1FEx4K-00077Q-7j; Thu, 02 Mar 2006 23:18:51 +0000 Received: from source ([192.150.20.142]) by exprod6ob8.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 02 Mar 2006 15:18:44 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k22NIn46017656; Thu, 2 Mar 2006 15:18:49 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k22NIfrw014437; Thu, 2 Mar 2006 15:18:42 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVI0054LWR493@mailsj-v1.corp.adobe.com>; Thu, 02 Mar 2006 15:18:40 -0800 (PST) Received: from MasinterT43p (c-131-70.corp.adobe.com [153.32.131.70]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IVI00E7AWR4XS@mailsj-v1.corp.adobe.com>; Thu, 02 Mar 2006 15:18:40 -0800 (PST) Date: Thu, 02 Mar 2006 15:18:20 -0800 From: Larry Masinter In-reply-to: <4406A8D3.5000602@gmx.de> To: "'Julian Reschke'" , "'HTTP Working Group'" , "'WebDAV'" , discuss@apps.ietf.org Message-id: <000301c63e4f$988cca60$46832099@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcY9/AMeH+TliMw7R4GW9jON/UhTAQAUVM7w Received-SPF: none (aji.w3.org: domain of LMM@acm.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FEx4K-00077Q-7j b657e32e2e151500eab5fc402c1b63c2 X-Original-To: w3c-dist-auth@w3.org Subject: RE: I-D ACTION:draft-whitehead-http-etag-00.txt X-Archived-At: http://www.w3.org/mid/000301c63e4f$988cca60$46832099@corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12172 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 23:19:12 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > Jim's draft summarizes the various issues=20 Looking through this for the issues, this is what I come up with: It looks like the HTTP spec doesn't say enough about ETag headers in 200 and 204 responses to PUT.=20 And there is a question, when a HTTP server accepts a PUT but will modify the octet stream before a subsequent GET of whether it can return a strong ETag (presumably for the data it has, not for what was sent). But doing so wouldn=92t be useful -- the client stored something, but gets back a strong etag for data that it doesn't have. So, I'd suggest a couple of things: (a) any server response for a successful PUT may contain an ETag header (200 and 204 as well as 201). (b) If a strong ETag is returned, then the client can=20 assume that the data was stored exactly as sent. (c) If the server modifies the data before storing it in a way that it cannot guarantee a byte-for-byte copy in a subsequent GET, it shouldn't use strong eTags. Larry --=20 http://larry.masinter.net From w3c-dist-auth-request@listhub.w3.org Thu Mar 02 18:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx8v-0006UV-4q for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:23:33 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEx8t-0003sT-Q1 for webdav-archive@lists.ietf.org; Thu, 02 Mar 2006 18:23:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FEx8f-0008VY-I7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Mar 2006 23:23:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FEx8c-0008Tg-11 for w3c-dist-auth@listhub.w3.org; Thu, 02 Mar 2006 23:23:14 +0000 Received: from [207.151.156.98] (helo=paris.ubudesign.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FEx8Z-0001w5-5R for w3c-dist-auth@w3.org; Thu, 02 Mar 2006 23:23:13 +0000 Received: from www.ubudesign.com (ubudesign.com [207.151.156.98]) by paris.ubudesign.com (8.12.8/8.12.8) with SMTP id k22N9mmr028721; Thu, 2 Mar 2006 15:09:48 -0800 Received: from 12.46.14.45 (SquirrelMail authenticated user ubudesign) by www.ubudesign.com with HTTP; Thu, 2 Mar 2006 15:09:48 -0800 (PST) Message-ID: <5379.12.46.14.45.1141340988.squirrel@www.ubudesign.com> In-Reply-To: <440774A3.6020506@gmx.de> References: <03E7D3E231BB7B4A915A6581D4296CC60206304C@NSNOVPS00411.nacio.xythos.co m> <440774A3.6020506@gmx.de> Date: Thu, 2 Mar 2006 15:09:48 -0800 (PST) From: "Alex Jalali" To: w3c-dist-auth@w3.org Cc: w3c-dist-auth@w3.org Reply-To: alex@ubudesign.com User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Received-SPF: none (maggie.w3.org: domain of alex@ubudesign.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.6 X-W3C-Scan-Sig: maggie.w3.org 1FEx8Z-0001w5-5R a6bcba54a02ac3fc729033a18bb1a3ce X-Original-To: w3c-dist-auth@w3.org Subject: Comments on the 2518 X-Archived-At: http://www.w3.org/mid/5379.12.46.14.45.1141340988.squirrel@www.ubudesign.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12173 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 02 Mar 2006 23:23:17 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I am planning on adding ACL to our dav server. are there things that would effect that? Also currently we have dav class 1 and 2 should I implement class 3 before going into ACL and versioning or it wouldn't matter? Thanks From w3c-dist-auth-request@listhub.w3.org Fri Mar 03 09:08:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAxE-0000up-1j for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 09:08:24 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFAxB-0006R8-Ow for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 09:08:24 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FFAvn-00044c-Hr for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Mar 2006 14:06:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FFAvf-00043q-Gs for w3c-dist-auth@listhub.w3.org; Fri, 03 Mar 2006 14:06:47 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1FFAvc-0007Tb-Cr for w3c-dist-auth@w3.org; Fri, 03 Mar 2006 14:06:47 +0000 Received: (qmail invoked by alias); 03 Mar 2006 14:06:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 03 Mar 2006 15:06:41 +0100 X-Authenticated: #1915285 Message-ID: <44084D2F.4070305@gmx.de> Date: Fri, 03 Mar 2006 15:05:35 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC602063076@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC602063076@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FFAvc-0007Tb-Cr ac1f9089c9774e8fa7cda11d712b2034 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/44084D2F.4070305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12174 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Mar 2006 14:06:55 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Kevin Wiggen wrote: > > Not sure you understood my question. I would like readers of the spec > to understand the difference between a URL and Display Name and > understand how that operates in the real world (MS Webfolders, Apple > OSX, Xythos). Webdav clients that make Webdav server look like file > systems should expect the URL to be used in displays to users and NOT > display name. As client developers we often get into conflict on this > point. We of course can add a column in windows explorer to SHOW the > display name, but the URL is the correct item to show users in this > generic Webdav client. Well, I wanted to make sure that what you're after is a clarification of how WebDAV has been working all the time, not something we changed in RFC2518bis. So yes, I agree that it would be useful to state that the DAV:displayname property is not a replacement for the URL, that even in presence of nice DAV:displayname there are still good reason to assign meaningful URLs, and that clients can not assume that displaynames will be unique for the members of a collection. Do you want to propose specific text? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Fri Mar 03 18:34:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJn0-0001mA-9F for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 18:34:26 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJmw-0002vb-QQ for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 18:34:26 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FFJkg-00065U-Hg for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Mar 2006 23:32:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FFJkT-0005zO-1Q for w3c-dist-auth@listhub.w3.org; Fri, 03 Mar 2006 23:31:49 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FFJkP-0000zB-Po for w3c-dist-auth@w3.org; Fri, 03 Mar 2006 23:31:48 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 15:30:38 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC60206325B@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518 -- XSS thread-index: AcY+CdqBFGBfkFnKTza0Q5O0psceYAA3lJGQ From: "Kevin Wiggen" To: "Julian Reschke" Cc: Received-SPF: none (lisa.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FFJkP-0000zB-Po 3a0e03b1283dcd274d829360bb4107c1 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 -- XSS X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC60206325B@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12175 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Mar 2006 23:32:02 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 I believe this is way too weak of language on what the risks are around Webdav (and HTTP for that matter). We need to point out to people that there is a LARGE risk in allowing users to post data to servers because of the way HTTP and Webdav work. "The server might not have a close trust relationship with the author that is publishing the document." -- Even in corporate, I don't have a strong trust relationship with every employee... There are also numerous servers that are being used by multiple sets of people. If someone for ANY reason can PUT information on the server, it is possible for others to be compromised by that person. I think we need to spell this out for people so they understand the risks. =20 "Servers that allow clients to publish arbitrary content can usefully implement precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as restricting the types of content that is allowed to be published and running virus and malware detection software on published content." -- Again this is a catch 22. Basically there is a line between usefulness and security. People have valid reasons for posting lots of different content. How do you know if they are malicious or not? Also I know of no virus protection software that flags xmlHTTP() as a virus. Right now clicking on index.html in web folders launches my browser which can then execute code (and since IE shares login info) that will make any type of Webdav calls to the server using xmlHTTP and my security permissions. The major problem I believe we need to solve is the relationship between a GET and HTML. =20 "Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server." -- This makes it seem like valid ACL will solve the problem. This is not necessarily true. If you allow me to write to ANY part of your server, I can trick you into letting me have access to the rest of it. I think this language is vague and leads people to believe things are safe when they are not. We need to spell out what the risks are and let people know. I remember a few years ago when MS had a buffer overflow exploit in there Webdav server, it took a lot of convincing to prove to people that it was a problem with the MS server and not the protocol. "Webdav is insecure" is what people kept saying. We need to discuss these issues else Webdav could get a really bad rap (even though most of these problems also affect HTTP itself). -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Thursday, March 02, 2006 12:34 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 -- XSS Kevin Wiggen wrote: > Webdav needs to mention (and hopefully help) solve XSS attack problems. =20 > XSS (Cross-Site Scripting) is aimed at inserting active code in an HTML=20 > document to either abuse client-side active scripting holes, or to send=20 > privileged information (e.g. authentication/session cookies) to a=20 > previously unknown evil collection site. We currently have=20 ,=20 which says: "HTTP has the ability to host programs which are executed on client=20 machines. These programs can take many forms including web scripts,=20 executables, plug in modules, and macros in documents. WebDAV does not=20 change any of the security concerns around these programs yet often=20 WebDAV is used in contexts where a wide range of users can publish=20 documents on a server. The server might not have a close trust=20 relationship with the author that is publishing the document. Servers=20 that allow clients to publish arbitrary content can usefully implement=20 precautions to check that content published to the server is not harmful to other clients. Servers could do this by techniques such as=20 restricting the types of content that is allowed to be published and=20 running virus and malware detection software on published content.=20 Servers can also mitigate the risk by having appropriate access=20 restriction and authentication of users that are allowed to publish=20 content to the server." I don't think that saying more would be good. This is a general problem=20 *not* specific to WebDAV. > Webdav to date is content agnostic and allows for clients to retrieve=20 > and save information to/from a server. Unfortunately with Javascript=20 > and some knowledge of webdav, people can start to "hack" webdav servers=20 > to do unexpected things. Imagine I upload (using PUT) a HTML page that=20 > uses a browser xmlHTTP() to send a propfind to the server and then issue=20 > DELETE to everything I could find. By simply sending you a link to a=20 > URL on a common secured server, a browser will ask you to log in and=20 > then execute the javascript AS YOU. There are a lot of problems that=20 > smart people can create because the GET and other Webdav methods all=20 > originate from the same server. There are possible solutions (from=20 > scraping all input and not allowing certain content) but each always has=20 > some drawbacks (hey I want that javascript to do something important on=20 > my webpage, you can't cut it out when I upload it).=20 So do you have any specific proposal about what to do? > A separate but related issue is the MS "translate" issue. If someone=20 > uploads a jsp to a server, when they request it back, do they want the > server to give the jsp? Or execute the jsp and return the result?=20 >=20 > It seems that Webdav (web distributed AUTHORING and versioning) could=20 > take some steps to help out both of these areas. One line of thinking > (notice I don't say solution) is to have Webdav separate the authoring > world from the view (or execute world). In this world there would be=20 > two different namespaces (one for Webdav and one for GET/Execute). The=20 > webdav world would tell clients that it is meant for authoring and thus=20 > servers will NOT execute things like jsps and clients should NOT render=20 > and execute these objects (like javascript in HTML) in things like=20 > browsers but rather a edit mode (like HTML editor). In this way,=20 > Javascript should not be executed by HTML Editors and the namespace will=20 > be protected from malicious code stored in the sheep's clothing of HTML. That's basically the question the DAV:source property was supposed to=20 solve. It has been removed from the spec due to a complete lack of=20 implementation experience. It's an interesting and important topic, but it was impossible to solve=20 within the time that has been allocated to us. > Again I believe it important for Webdav to speak about these problems=20 > and try to give solutions. >=20 Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Fri Mar 03 18:37:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJqM-0000do-TP for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 18:37:54 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJqM-0002zN-KC for webdav-archive@lists.ietf.org; Fri, 03 Mar 2006 18:37:54 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FFJpb-0006wU-5y for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Mar 2006 23:37:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FFJpT-0006vi-Us for w3c-dist-auth@listhub.w3.org; Fri, 03 Mar 2006 23:36:59 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FFJpS-0001nL-7D for w3c-dist-auth@w3.org; Fri, 03 Mar 2006 23:36:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 15:36:57 -0800 Message-ID: <03E7D3E231BB7B4A915A6581D4296CC60206325F@NSNOVPS00411.nacio.xythos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the "new" 2518--Display Name thread-index: AcY+y7T/x8UV+yDgTBS/8mundjcn1gARcoUA From: "Kevin Wiggen" To: "Julian Reschke" Cc: Received-SPF: none (lisa.w3.org: domain of kwiggen@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FFJpS-0001nL-7D eebad5fa9260d9d851d94d0817c10088 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/03E7D3E231BB7B4A915A6581D4296CC60206325F@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12176 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Mar 2006 23:37:07 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Well I am not a spec writer nor an English major and I often say Pascal is my native language BUT: Webdav servers and clients must understand that the method for identifying resources is still the URL. While generic Webdav clients will be able to display DAV:displayname to end users, both sides of the Webdav protocol must understand that if users are allowed to do things like rename, move, copy etc, generic clients must show the URLs to these end users to allow these operations. Changes to DAV:displayname do not issue moves or copies to the server, but simply change a piece of meta-data on the individual resource. Language should be added to the spec that makes this clear, as we routinely hear from people whom have read the spec that expectations around displayname are not the same as what the spec designers are telling me on this list. -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Friday, March 03, 2006 6:06 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name Kevin Wiggen wrote: >=20 > Not sure you understood my question. I would like readers of the spec > to understand the difference between a URL and Display Name and > understand how that operates in the real world (MS Webfolders, Apple > OSX, Xythos). Webdav clients that make Webdav server look like file > systems should expect the URL to be used in displays to users and NOT > display name. As client developers we often get into conflict on this > point. We of course can add a column in windows explorer to SHOW the > display name, but the URL is the correct item to show users in this > generic Webdav client. Well, I wanted to make sure that what you're after is a clarification of how WebDAV has been working all the time, not something we changed in=20 RFC2518bis. So yes, I agree that it would be useful to state that the=20 DAV:displayname property is not a replacement for the URL, that even in=20 presence of nice DAV:displayname there are still good reason to assign=20 meaningful URLs, and that clients can not assume that displaynames will=20 be unique for the members of a collection. Do you want to propose specific text? Best regards, Julian From fractionate@dotexpress.com Sat Mar 04 08:56:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFXFV-0004Be-Vq for webdav-archive@lists.ietf.org; Sat, 04 Mar 2006 08:56:45 -0500 Received: from [221.147.131.142] (helo=kbwwiwya.info) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFXFT-0000P1-UD for webdav-archive@lists.ietf.org; Sat, 04 Mar 2006 08:56:45 -0500 Received: (stonecrop 1418 invoked from network); Sat, 04 Mar 2006 08:33:20 -0500 Date: Sat, 04 Mar 2006 08:58:17 -0500 Message-Id: <4183826425088437753171600@microsoft.com> From: Hannah Childers To: webdav-archive@lists.ietf.org Subject: Hi, hit me Content-Type: multipart/mixed;boundary="------=5344180828" Content-Transfer-Encoding: base64 X-Spam-Score: 4.9 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 --------=5344180828 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit Lose weight without exercise or diets. Even if you have no erection problems Cialis rocks!




Valium bestseller.



Tamiflu bestseller.
Xanax bestseller.
http://au.geocities.com/dev59812cheryl4954/


In this game, by trying to win you automatically lose.God gave burdens, also shoulders. --------=5344180828 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit When angry, count to ten before you speak. If very angry, count to one hundred.You can't depend on your judgment when your imagination is out of focus. --------=5344180828-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 09:02:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGI2-0001Dm-K1 for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 09:02:22 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGHz-0003Aa-AW for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 09:02:22 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGGFz-0000kV-Cs for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 14:00:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FGGFq-0000Zr-Hg for w3c-dist-auth@listhub.w3.org; Mon, 06 Mar 2006 14:00:06 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1FGGFn-0006SM-H6 for w3c-dist-auth@w3.org; Mon, 06 Mar 2006 14:00:05 +0000 Received: (qmail invoked by alias); 06 Mar 2006 14:00:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 06 Mar 2006 15:00:00 +0100 X-Authenticated: #1915285 Message-ID: <440C4021.2010406@gmx.de> Date: Mon, 06 Mar 2006 14:58:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kevin Wiggen CC: w3c-dist-auth@w3.org References: <03E7D3E231BB7B4A915A6581D4296CC60206325F@NSNOVPS00411.nacio.xythos.com> In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC60206325F@NSNOVPS00411.nacio.xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FGGFn-0006SM-H6 592b20b6a422b976505c2d0fd0f1fc8d X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/440C4021.2010406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12177 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 14:00:15 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Kevin Wiggen wrote: > > Well I am not a spec writer nor an English major and I often say Pascal > is my native language BUT: > > Webdav servers and clients must understand that the method for > identifying resources is still the URL. While generic Webdav clients > will be able to display DAV:displayname to end users, both sides of the > Webdav protocol must understand that if users are allowed to do things > like rename, move, copy etc, generic clients must show the URLs to these > end users to allow these operations. Changes to DAV:displayname do not > issue moves or copies to the server, but simply change a piece of > meta-data on the individual resource. > > Language should be added to the spec that makes this clear, as we > routinely hear from people whom have read the spec that expectations > around displayname are not the same as what the spec designers are > telling me on this list. +1 on the language proposed by Kevin. best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 09:08:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGOO-0006Ju-Aj for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 09:08:56 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGON-0003Sf-Ul for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 09:08:56 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGGNX-0003ch-PV for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 14:08:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FGGNT-0003av-3r; Mon, 06 Mar 2006 14:07:59 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1FGGNQ-00083F-1T; Mon, 06 Mar 2006 14:07:58 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k26E7sdm028980; Mon, 6 Mar 2006 09:07:54 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k26E7slL172418; Mon, 6 Mar 2006 09:07:54 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k26E7sAE026213; Mon, 6 Mar 2006 09:07:54 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k26E7rcq026147; Mon, 6 Mar 2006 09:07:53 -0500 In-Reply-To: <440C4021.2010406@gmx.de> To: Julian Reschke Cc: Kevin Wiggen , 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 From: Geoffrey M Clemm Message-ID: Date: Mon, 6 Mar 2006 09:07:59 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/06/2006 09:07:52, Serialize complete at 03/06/2006 09:07:52 Content-Type: multipart/alternative; boundary="=_alternative 004D9F8385257129_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1FGGNQ-00083F-1T b62778a7f38a156644a394f05e2c4bf7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518--Display Name X-Archived-At: http://www.w3.org/mid/OFEAF58992.3354F35A-ON85257129.004D7454-85257129.004DA0B0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12178 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 14:08:03 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is a multipart message in MIME format. --=_alternative 004D9F8385257129_= Content-Type: text/plain; charset="US-ASCII" +1 from me as well. I believe Kevin's paragraph addresses the key confusions around DAV:displayname. Cheers, Geoff Julian wrote on 03/06/2006 08:58:57 AM: > > Kevin Wiggen wrote: > > > > Well I am not a spec writer nor an English major and I often say Pascal > > is my native language BUT: > > > > Webdav servers and clients must understand that the method for > > identifying resources is still the URL. While generic Webdav clients > > will be able to display DAV:displayname to end users, both sides of the > > Webdav protocol must understand that if users are allowed to do things > > like rename, move, copy etc, generic clients must show the URLs to these > > end users to allow these operations. Changes to DAV:displayname do not > > issue moves or copies to the server, but simply change a piece of > > meta-data on the individual resource. > > > > Language should be added to the spec that makes this clear, as we > > routinely hear from people whom have read the spec that expectations > > around displayname are not the same as what the spec designers are > > telling me on this list. > > +1 on the language proposed by Kevin. > > best regards, Julian > --=_alternative 004D9F8385257129_= Content-Type: text/html; charset="US-ASCII"
+1 from me as well.  I believe Kevin's paragraph addresses the key
confusions around DAV:displayname.

Cheers,
Geoff

Julian wrote on 03/06/2006 08:58:57 AM:
>
> Kevin Wiggen wrote:
> >
> > Well I am not a spec writer nor an English major and I often say Pascal
> > is my native language BUT:
> >
> > Webdav servers and clients must understand that the method for
> > identifying resources is still the URL.  While generic Webdav clients
> > will be able to display DAV:displayname to end users, both sides of the
> > Webdav protocol must understand that if users are allowed to do things
> > like rename, move, copy etc, generic clients must show the URLs to these
> > end users to allow these operations.  Changes to DAV:displayname do not
> > issue moves or copies to the server, but simply change a piece of
> > meta-data on the individual resource.
> >
> > Language should be added to the spec that makes this clear, as we
> > routinely hear from people whom have read the spec that expectations
> > around displayname are not the same as what the spec designers are
> > telling me on this list.
>
> +1 on the language proposed by Kevin.
>
> best regards, Julian
>
--=_alternative 004D9F8385257129_=-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 14:35:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGLUQ-0004qh-Fv for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 14:35:30 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGLUQ-0006rY-65 for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 14:35:30 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGLTE-0003tA-7o for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 19:34:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FGLT4-0003ri-SQ for w3c-dist-auth@listhub.w3.org; Mon, 06 Mar 2006 19:34:07 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FGLT0-0006Y7-9b for w3c-dist-auth@w3.org; Mon, 06 Mar 2006 19:34:05 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 6 Mar 2006 11:33:56 -0800 From: "John Barone" To: "'Julian Reschke'" , "'Kevin Wiggen'" Cc: Date: Mon, 6 Mar 2006 11:33:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcY90se7iHpADAj9TDCxRU40qflYMwDgd3qQ In-Reply-To: <4406AB85.7090603@gmx.de> Message-ID: X-OriginalArrivalTime: 06 Mar 2006 19:33:56.0316 (UTC) FILETIME=[E8AA21C0:01C64154] Received-SPF: none (maggie.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FGLT0-0006Y7-9b 1897e6f6e68bc79e3ffff6e77bbb3c86 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS00411bN2tEwL000005df@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12179 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 19:34:16 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a The concern for us on a MOVE is that the currently specified behavior is contrary to (what our immediate customer experience tells us) many users want or expect. Imagine that I as a user issue a MOVE on the server via an integrated file explorer on the desktop. I start out with a whole collection, and I drag-and-drop it to a new location on the server (or simply rename it), and I end up with 2 incomplete collections, due to permissions or lock conflicts on sub-collections/resource, with no real indication as to why it happened, and worse, no indication how to correct the mess I've just created. Our own customer experience tells us that, in this use case, users don't want you to allow them to "shoot themselves in the foot". So, understanding that the specification of MOVE behavior has not changed between 2518 and 2518-bis, Xythos would like to propose the following additional capability to the MOVE section: Add support for a new header on MOVE, that will allow client applications to request that the server perform an atomic operation on MOVE, meaning an all-or-nothing operation. We'd like to see the header: Allow-partial: T/F ... added for MOVEs, with the default value being 'T', to preserve backward-compatibility, and a value of 'F' meaning attempt to perform the MOVE as an all-or-nothing operation; if the MOVE cannot be performed as an all-or-nothing operation, return a 412 - precondition failed response (or, alternatively, a 207 response, that includes all the 412 response for specific resources). If implementing servers choose not to support this header, and the value is set to 'F', they MAY return a 400 bad request response. -John -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Thursday, March 02, 2006 12:24 AM To: Kevin Wiggen Cc: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 Kevin Wiggen wrote: > In section 9.1, I know this isn't backwardly compatible but can't we > make the default for PROPFIND = depth 0 and PROPNAME? Move, Copy, > Delete aren't backward compatible (see other email), why not make this > better. MOVE, COPY and DELETE *are* backwards compatible. And that's exactly the reason why we didn't make changes like the one you just proposed: old clients should be able to interact with new servers, and the other way around. Note that this is the main reason why I'm opposed to change the LOCK refresh marshalling. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 16:17:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN5T-0005ND-66 for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 16:17:51 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGN5Q-0006mS-Jq for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 16:17:51 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGN4W-0006ee-KD for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 21:16:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FGN4N-0006e4-8t for w3c-dist-auth@listhub.w3.org; Mon, 06 Mar 2006 21:16:43 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1FGN4K-0006Gv-Uj for w3c-dist-auth@w3.org; Mon, 06 Mar 2006 21:16:43 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k26LGdqP016167 for ; Mon, 6 Mar 2006 16:16:39 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k26LGdvE125302 for ; Mon, 6 Mar 2006 16:16:39 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k26LGdHf010116 for ; Mon, 6 Mar 2006 16:16:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k26LGdX4010096; Mon, 6 Mar 2006 16:16:39 -0500 In-Reply-To: To: "John Barone" Cc: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 6 Mar 2006 16:16:37 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/06/2006 16:16:39, Serialize complete at 03/06/2006 16:16:39 Content-Type: multipart/alternative; boundary="=_alternative 0074DF9885257129_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1FGN4K-0006Gv-Uj c720587bc9489438f42d94ab1a567c39 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/OF66332AA7.18FB90E5-ON85257129.0074942D-85257129.0074E01B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12180 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 21:16:52 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b This is a multipart message in MIME format. --=_alternative 0074DF9885257129_= Content-Type: text/plain; charset="US-ASCII" The BIND specification (which hopefully will be last-called soon after the 2518bis last-call is completed), provides this feature in the REBIND method. So rather than upgrade your sever to support a new header, you would upgrade your server to support the REBIND method. Similarly, if you wanted to provide atomic DELETE functionality, you would support the UNBIND method. Cheers, Geoff John wrote on 03/06/2006 02:33:57 PM: > > The concern for us on a MOVE is that the currently specified behavior is > contrary to (what our immediate customer experience tells us) many users > want or expect. Imagine that I as a user issue a MOVE on the server via an > integrated file explorer on the desktop. I start out with a whole > collection, and I drag-and-drop it to a new location on the server (or > simply rename it), and I end up with 2 incomplete collections, due to > permissions or lock conflicts on sub-collections/resource, with no real > indication as to why it happened, and worse, no indication how to correct > the mess I've just created. Our own customer experience tells us that, in > this use case, users don't want you to allow them to "shoot themselves in > the foot". > > So, understanding that the specification of MOVE behavior has not changed > between 2518 and 2518-bis, Xythos would like to propose the following > additional capability to the MOVE section: > > Add support for a new header on MOVE, that will allow client applications to > request that the server perform an atomic operation on MOVE, meaning an > all-or-nothing operation. We'd like to see the header: > > Allow-partial: T/F > > ... added for MOVEs, with the default value being 'T', to preserve > backward-compatibility, and a value of 'F' meaning attempt to perform the > MOVE as an all-or-nothing operation; if the MOVE cannot be performed as an > all-or-nothing operation, return a 412 - precondition failed response (or, > alternatively, a 207 response, that includes all the 412 response for > specific resources). If implementing servers choose not to support this > header, and the value is set to 'F', they MAY return a 400 bad request > response. > > > -John > > -----Original Message----- > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On > Behalf Of Julian Reschke > Sent: Thursday, March 02, 2006 12:24 AM > To: Kevin Wiggen > Cc: w3c-dist-auth@w3.org > Subject: Re: Comments on the "new" 2518 > > > Kevin Wiggen wrote: > > In section 9.1, I know this isn't backwardly compatible but can't we > > make the default for PROPFIND = depth 0 and PROPNAME? Move, Copy, > > Delete aren't backward compatible (see other email), why not make this > > better. > > MOVE, COPY and DELETE *are* backwards compatible. > > And that's exactly the reason why we didn't make changes like the one you > just proposed: old clients should be able to interact with new servers, and > the other way around. Note that this is the main reason why I'm opposed to > change the LOCK refresh marshalling. > > Best regards, Julian > > > --=_alternative 0074DF9885257129_= Content-Type: text/html; charset="US-ASCII"
The BIND specification (which hopefully will be last-called soon after
the 2518bis last-call is completed), provides this feature in the REBIND
method.  So rather than upgrade your sever to support a new header, you
would upgrade your server to support the REBIND method.  Similarly, if
you wanted to provide atomic DELETE functionality, you would support the
UNBIND method.

Cheers,
Geoff

John wrote on 03/06/2006 02:33:57 PM:
>
> The concern for us on a MOVE is that the currently specified behavior is
> contrary to (what our immediate customer experience tells us) many users
> want or expect.  Imagine that I as a user issue a MOVE on the server via an
> integrated file explorer on the desktop.  I start out with a whole
> collection, and I drag-and-drop it to a new location on the server (or
> simply rename it), and I end up with 2 incomplete collections, due to
> permissions or lock conflicts on sub-collections/resource, with no real
> indication as to why it happened, and worse, no indication how to correct
> the mess I've just created.  Our own customer experience tells us that, in
> this use case, users don't want you to allow them to "shoot themselves in
> the foot".
>
> So, understanding that the specification of MOVE behavior has not changed
> between 2518 and 2518-bis, Xythos would like to propose the following
> additional capability to the MOVE section:
>
> Add support for a new header on MOVE, that will allow client applications to
> request that the server perform an atomic operation on MOVE, meaning an
> all-or-nothing operation.  We'd like to see the header:
>
> Allow-partial: T/F
>
> ... added for MOVEs, with the default value being 'T', to preserve
> backward-compatibility, and a value of 'F' meaning attempt to perform the
> MOVE as an all-or-nothing operation; if the MOVE cannot be performed as an
> all-or-nothing operation, return a 412 - precondition failed response (or,
> alternatively, a 207 response, that includes all the 412 response for
> specific resources).  If implementing servers choose not to support this
> header, and the value is set to 'F', they MAY return a 400 bad request
> response.  
>
>
> -John
>
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
> Behalf Of Julian Reschke
> Sent: Thursday, March 02, 2006 12:24 AM
> To: Kevin Wiggen
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Comments on the "new" 2518
>
>
> Kevin Wiggen wrote:
> > In section 9.1, I know this isn't backwardly compatible but can't we
> > make the default for PROPFIND = depth 0 and PROPNAME?  Move, Copy,
> > Delete aren't backward compatible (see other email), why not make this
> > better.
>
> MOVE, COPY and DELETE *are* backwards compatible.
>
> And that's exactly the reason why we didn't make changes like the one you
> just proposed: old clients should be able to interact with new servers, and
> the other way around. Note that this is the main reason why I'm opposed to
> change the LOCK refresh marshalling.
>
> Best regards, Julian
>
>
>
--=_alternative 0074DF9885257129_=-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 17:05:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNpn-0008HI-MP for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 17:05:43 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNpn-0002FN-6t for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 17:05:43 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGNpF-0002F4-9n for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 22:05:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FGNou-0001lM-S8 for w3c-dist-auth@listhub.w3.org; Mon, 06 Mar 2006 22:04:48 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1FGNor-0007MV-AZ for w3c-dist-auth@w3.org; Mon, 06 Mar 2006 22:04:48 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 255EC142264; Mon, 6 Mar 2006 14:04:41 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06774-10; Mon, 6 Mar 2006 14:04:40 -0800 (PST) Received: from [192.168.101.217] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 25C1B142262; Mon, 6 Mar 2006 14:04:40 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/alternative; boundary=Apple-Mail-2-166703546 Message-Id: <974154F5-DAD8-4CB0-8E31-B716A63330AD@osafoundation.org> Cc: "John Barone" , " webdav" From: Lisa Dusseault Date: Mon, 6 Mar 2006 14:04:20 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1FGNor-0007MV-AZ 5b73ef023e4f13669ca0f49179974950 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/974154F5-DAD8-4CB0-8E31-B716A63330AD@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12181 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 22:05:09 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 --Apple-Mail-2-166703546 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I am on the fence for how to go with this issue, but I do note that your solution doesn't solve John's problem. There are many existing, deployed clients who already implement MOVE and John wants WFS to behave appropriately for them without forcing widespread client (in some cases, operating system) upgrade. Lisa On Mar 6, 2006, at 1:16 PM, Geoffrey M Clemm wrote: > > The BIND specification (which hopefully will be last-called soon after > the 2518bis last-call is completed), provides this feature in the > REBIND > method. So rather than upgrade your sever to support a new header, > you > would upgrade your server to support the REBIND method. Similarly, if > you wanted to provide atomic DELETE functionality, you would > support the > UNBIND method. > > Cheers, > Geoff > > John wrote on 03/06/2006 02:33:57 PM: > > > > The concern for us on a MOVE is that the currently specified > behavior is > > contrary to (what our immediate customer experience tells us) > many users > > want or expect. Imagine that I as a user issue a MOVE on the > server via an > > integrated file explorer on the desktop. I start out with a whole > > collection, and I drag-and-drop it to a new location on the > server (or > > simply rename it), and I end up with 2 incomplete collections, > due to > > permissions or lock conflicts on sub-collections/resource, with > no real > > indication as to why it happened, and worse, no indication how to > correct > > the mess I've just created. Our own customer experience tells us > that, in > > this use case, users don't want you to allow them to "shoot > themselves in > > the foot". > > > > So, understanding that the specification of MOVE behavior has not > changed > > between 2518 and 2518-bis, Xythos would like to propose the > following > > additional capability to the MOVE section: > > > > Add support for a new header on MOVE, that will allow client > applications to > > request that the server perform an atomic operation on MOVE, > meaning an > > all-or-nothing operation. We'd like to see the header: > > > > Allow-partial: T/F > > > > ... added for MOVEs, with the default value being 'T', to preserve > > backward-compatibility, and a value of 'F' meaning attempt to > perform the > > MOVE as an all-or-nothing operation; if the MOVE cannot be > performed as an > > all-or-nothing operation, return a 412 - precondition failed > response (or, > > alternatively, a 207 response, that includes all the 412 response > for > > specific resources). If implementing servers choose not to > support this > > header, and the value is set to 'F', they MAY return a 400 bad > request > > response. > > > > > > -John > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth- > request@w3.org] On > > Behalf Of Julian Reschke > > Sent: Thursday, March 02, 2006 12:24 AM > > To: Kevin Wiggen > > Cc: w3c-dist-auth@w3.org > > Subject: Re: Comments on the "new" 2518 > > > > > > Kevin Wiggen wrote: > > > In section 9.1, I know this isn't backwardly compatible but > can't we > > > make the default for PROPFIND = depth 0 and PROPNAME? Move, Copy, > > > Delete aren't backward compatible (see other email), why not > make this > > > better. > > > > MOVE, COPY and DELETE *are* backwards compatible. > > > > And that's exactly the reason why we didn't make changes like the > one you > > just proposed: old clients should be able to interact with new > servers, and > > the other way around. Note that this is the main reason why I'm > opposed to > > change the LOCK refresh marshalling. > > > > Best regards, Julian > > > > > > --Apple-Mail-2-166703546 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I am on the fence for how to go = with this issue,=A0 but I do note that your solution doesn't solve = John's problem.=A0 There are many existing, deployed clients who already = implement MOVE and John wants WFS to behave appropriately for them = without forcing widespread client (in some cases, operating system) = upgrade.

Lisa

On = Mar 6, 2006, at 1:16 PM, Geoffrey M Clemm wrote:


The BIND specification (which hopefully will be = last-called soon after
the 2518bis = last-call is completed), provides this feature in the REBIND =
method. =A0So rather than upgrade your sever to = support a new header, you
would = upgrade your server to support the REBIND method. =A0Similarly, = if
you wanted to provide atomic = DELETE functionality, you would support the
UNBIND method.

= Cheers,
Geoff
=
John wrote on 03/06/2006 02:33:57 PM:
> =
> The concern for us on a MOVE is that the currently specified = behavior is
> contrary to (what our immediate customer experience = tells us) many users
> want or expect. =A0Imagine that I as a = user issue a MOVE on the server via an
> integrated file explorer = on the desktop. =A0I start out with a whole
> collection, and I = drag-and-drop it to a new location on the server (or
> simply = rename it), and I end up with 2 incomplete collections, due to
> = permissions or lock conflicts on sub-collections/resource, with no = real
> indication as to why it happened, and worse, no indication = how to correct
> the mess I've just created. =A0Our own customer = experience tells us that, in
> this use case, users don't want = you to allow them to "shoot themselves in
> the foot".
> =
> So, understanding that the specification of MOVE behavior has = not changed
> between 2518 and 2518-bis, Xythos would like to = propose the following
> additional capability to the MOVE = section:
>
> Add support for a new header on MOVE, that = will allow client applications to
> request that the server = perform an atomic operation on MOVE, meaning an
> all-or-nothing = operation. =A0We'd like to see the header:
>
> = Allow-partial: T/F
>
> ... added for MOVEs, with the = default value being 'T', to preserve
> backward-compatibility, = and a value of 'F' meaning attempt to perform the
> MOVE as an = all-or-nothing operation; if the MOVE cannot be performed as an
> = all-or-nothing operation, return a 412 - precondition failed response = (or,
> alternatively, a 207 response, that includes all the 412 = response for
> specific resources). =A0If implementing servers = choose not to support this
> header, and the value is set to 'F', = they MAY return a 400 bad request
> response. =A0
>
= >
> -John
>
> -----Original Message-----
= > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@= w3.org] On
> Behalf Of Julian Reschke
> Sent: = Thursday, March 02, 2006 12:24 AM
> To: Kevin Wiggen
> Cc: = w3c-dist-auth@w3.org
= > Subject: Re: Comments on the "new" 2518
>
>
= > Kevin Wiggen wrote:
> > In section 9.1, I know this isn't = backwardly compatible but can't we
> > make the default for = PROPFIND =3D depth 0 and PROPNAME? =A0Move, Copy,
> > Delete = aren't backward compatible (see other email), why not make this
= > > better.
>
> MOVE, COPY and DELETE *are* = backwards compatible.
>
> And that's exactly the reason = why we didn't make changes like the one you
> just proposed: old = clients should be able to interact with new servers, and
> the = other way around. Note that this is the main reason why I'm opposed = to
> change the LOCK refresh marshalling.
>
> Best = regards, Julian
>
>
>
=

= --Apple-Mail-2-166703546-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 18:01:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOiD-0007d0-WD for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 18:01:58 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGOiB-0005Wo-O6 for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 18:01:57 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGOhF-000065-PB for w3c-dist-auth-dist@listhub.w3.org; Mon, 06 Mar 2006 23:00:58 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FGOgs-0008JQ-H6 for w3c-dist-auth@listhub.w3.org; Mon, 06 Mar 2006 23:00:34 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.50) id 1FGOgp-0000bl-CH for w3c-dist-auth@w3.org; Mon, 06 Mar 2006 23:00:33 +0000 Received: (qmail invoked by alias); 06 Mar 2006 23:00:26 -0000 Received: from p508FB3ED.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.237] by mail.gmx.net (mp028) with SMTP; 07 Mar 2006 00:00:26 +0100 X-Authenticated: #1915285 Message-ID: <440CBED0.2060701@gmx.de> Date: Mon, 06 Mar 2006 23:59:28 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , John Barone , webdav References: <974154F5-DAD8-4CB0-8E31-B716A63330AD@osafoundation.org> In-Reply-To: <974154F5-DAD8-4CB0-8E31-B716A63330AD@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FGOgp-0000bl-CH 16babbc6e5771f1df256b408873bdc95 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/440CBED0.2060701@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12182 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 06 Mar 2006 23:00:57 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Lisa Dusseault wrote: > I am on the fence for how to go with this issue, but I do note that > your solution doesn't solve John's problem. There are many existing, > deployed clients who already implement MOVE and John wants WFS to behave > appropriately for them without forcing widespread client (in some cases, > operating system) upgrade. Sorry? John asked for an extension that allows clients to state that MOVE should be atomic (the default staying non-atomic for backwards compatibility). Geoff pointed out that that extension already exists and is called REBIND. Clients that would want to take advantage of it would need to be upgraded in both cases. And, as a matter of fact, they would still need to be able to handle servers with non-atomic MOVE implementations. What am I missing? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 20:01:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQZe-0004XY-Cc for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 20:01:14 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQZe-0001Va-4Y for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 20:01:14 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGQYg-0007FN-Bf for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Mar 2006 01:00:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FGQYT-0006Rk-OE for w3c-dist-auth@listhub.w3.org; Tue, 07 Mar 2006 01:00:01 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1FGQYR-00081W-8T for w3c-dist-auth@w3.org; Tue, 07 Mar 2006 01:00:01 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D90514228B; Mon, 6 Mar 2006 16:59:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28663-03; Mon, 6 Mar 2006 16:59:57 -0800 (PST) Received: from [192.168.101.217] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 95130142289; Mon, 6 Mar 2006 16:59:57 -0800 (PST) In-Reply-To: <440CBED0.2060701@gmx.de> References: <974154F5-DAD8-4CB0-8E31-B716A63330AD@osafoundation.org> <440CBED0.2060701@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Geoffrey M Clemm , John Barone , webdav Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Mon, 6 Mar 2006 16:59:39 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: none (maggie.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1FGQYR-00081W-8T b4c570de9d6b8724b77c550ced721707 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/CA78DAC2-49A0-433E-A9B7-D72924B34385@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12183 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Mar 2006 01:00:14 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 I read 'T' for 'F' when I initially read John's email, so I guess that would require clients to change their code to get atomicity. John would a solution that required clients to change their code to require atomicity be acceptable? Lisa On Mar 6, 2006, at 2:59 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> I am on the fence for how to go with this issue, but I do note >> that your solution doesn't solve John's problem. There are many >> existing, deployed clients who already implement MOVE and John >> wants WFS to behave appropriately for them without forcing >> widespread client (in some cases, operating system) upgrade. > > Sorry? > > John asked for an extension that allows clients to state that MOVE > should be atomic (the default staying non-atomic for backwards > compatibility). > > Geoff pointed out that that extension already exists and is called > REBIND. > > Clients that would want to take advantage of it would need to be > upgraded in both cases. And, as a matter of fact, they would still > need to be able to handle servers with non-atomic MOVE > implementations. > > What am I missing? > > Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 06 20:17:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQp2-0002RJ-J5 for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 20:17:08 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQp0-00029P-6R for webdav-archive@lists.ietf.org; Mon, 06 Mar 2006 20:17:08 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGQoX-0002vr-LI for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Mar 2006 01:16:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FGQoP-0002un-Q6 for w3c-dist-auth@listhub.w3.org; Tue, 07 Mar 2006 01:16:30 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by maggie.w3.org with esmtp (Exim 4.50) id 1FGQoM-000204-Tr for w3c-dist-auth@w3.org; Tue, 07 Mar 2006 01:16:29 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k271GPV0030256 for ; Mon, 6 Mar 2006 20:16:25 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k271GPvE129910 for ; Mon, 6 Mar 2006 20:16:25 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k271GPOl014078 for ; Mon, 6 Mar 2006 20:16:25 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k271GP0X014071 for ; Mon, 6 Mar 2006 20:16:25 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 6 Mar 2006 20:16:23 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/06/2006 20:16:25, Serialize complete at 03/06/2006 20:16:25 Content-Type: multipart/alternative; boundary="=_alternative 0006FD698525712A_=" Received-SPF: none (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1FGQoM-000204-Tr 668616edf03b1db281de60c3535591e1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/OF7087D5E1.95DE469D-ON8525712A.0005D2AB-8525712A.0006FE20@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12184 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Mar 2006 01:16:37 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multipart message in MIME format. --=_alternative 0006FD698525712A_= Content-Type: text/plain; charset="US-ASCII" The request from an unmodified client cannot be interpreted by a server as requiring atomic move semantics, since 2518 requires the standard request to be interpreted as "best effort". Therefore a client is going to have to modify its request to indicate it wants atomic move semantics, and should use the request we already have defined (REBIND). Cheers, Geoff Lisa wrote on 03/06/2006 07:59:39 PM: > > I read 'T' for 'F' when I initially read John's email, so I guess > that would require clients to change their code to get atomicity. > John would a solution that required clients to change their code to > require atomicity be acceptable? > > Lisa > > On Mar 6, 2006, at 2:59 PM, Julian Reschke wrote: > > > Lisa Dusseault wrote: > >> I am on the fence for how to go with this issue, but I do note > >> that your solution doesn't solve John's problem. There are many > >> existing, deployed clients who already implement MOVE and John > >> wants WFS to behave appropriately for them without forcing > >> widespread client (in some cases, operating system) upgrade. > > > > Sorry? > > > > John asked for an extension that allows clients to state that MOVE > > should be atomic (the default staying non-atomic for backwards > > compatibility). > > > > Geoff pointed out that that extension already exists and is called > > REBIND. > > > > Clients that would want to take advantage of it would need to be > > upgraded in both cases. And, as a matter of fact, they would still > > need to be able to handle servers with non-atomic MOVE > > implementations. > > > > What am I missing? > > > > Best regards, Julian > > --=_alternative 0006FD698525712A_= Content-Type: text/html; charset="US-ASCII"
The request from an unmodified client cannot be interpreted
by a server as requiring atomic move semantics,
since 2518 requires the standard request to be
interpreted as "best effort".  Therefore a client is going to
have to modify its request to indicate it wants atomic
move semantics, and should use the request we already have
defined (REBIND).

Cheers,
Geoff

Lisa wrote on 03/06/2006 07:59:39 PM:
>
> I read 'T' for 'F' when I initially read John's email, so I guess  
> that would require clients to change their code to get atomicity.  
> John would a solution that required clients to change their code to  
> require atomicity be acceptable?
>
> Lisa
>
> On Mar 6, 2006, at 2:59 PM, Julian Reschke wrote:
>
> > Lisa Dusseault wrote:
> >> I am on the fence for how to go with this issue,  but I do note  
> >> that your solution doesn't solve John's problem.  There are many  
> >> existing, deployed clients who already implement MOVE and John  
> >> wants WFS to behave appropriately for them without forcing  
> >> widespread client (in some cases, operating system) upgrade.
> >
> > Sorry?
> >
> > John asked for an extension that allows clients to state that MOVE  
> > should be atomic (the default staying non-atomic for backwards  
> > compatibility).
> >
> > Geoff pointed out that that extension already exists and is called  
> > REBIND.
> >
> > Clients that would want to take advantage of it would need to be  
> > upgraded in both cases. And, as a matter of fact, they would still  
> > need to be able to handle servers with non-atomic MOVE  
> > implementations.
> >
> > What am I missing?
> >
> > Best regards, Julian
>
>
--=_alternative 0006FD698525712A_=-- From w3c-dist-auth-request@listhub.w3.org Tue Mar 07 03:46:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXq3-0005sN-B6 for webdav-archive@lists.ietf.org; Tue, 07 Mar 2006 03:46:39 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGXq3-000186-2q for webdav-archive@lists.ietf.org; Tue, 07 Mar 2006 03:46:39 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGXob-0000R1-O5 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Mar 2006 08:45:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FGXoS-0007yJ-Fd for w3c-dist-auth@listhub.w3.org; Tue, 07 Mar 2006 08:45:00 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1FGXoP-0000mq-OE for w3c-dist-auth@w3.org; Tue, 07 Mar 2006 08:44:59 +0000 Received: (qmail invoked by alias); 07 Mar 2006 08:44:56 -0000 Received: from p508FB6D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.182.216] by mail.gmx.net (mp004) with SMTP; 07 Mar 2006 09:44:56 +0100 X-Authenticated: #1915285 Message-ID: <440D47CE.8090203@gmx.de> Date: Tue, 07 Mar 2006 09:43:58 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Kevin Wiggen' , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FGXoP-0000mq-OE ea26037e3551a9ba7b1e6325259205db X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/440D47CE.8090203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12185 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Mar 2006 08:45:09 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 John Barone wrote: > The concern for us on a MOVE is that the currently specified behavior is > contrary to (what our immediate customer experience tells us) many users > want or expect. Imagine that I as a user issue a MOVE on the server via an > integrated file explorer on the desktop. I start out with a whole > collection, and I drag-and-drop it to a new location on the server (or > simply rename it), and I end up with 2 incomplete collections, due to > permissions or lock conflicts on sub-collections/resource, with no real > indication as to why it happened, and worse, no indication how to correct > the mess I've just created. Our own customer experience tells us that, in > this use case, users don't want you to allow them to "shoot themselves in > the foot". > ... For the record: but that's exactly the same behavior that the user gets when moving data across partitions or network shared. > ... > So, understanding that the specification of MOVE behavior has not changed > between 2518 and 2518-bis, Xythos would like to propose the following > additional capability to the MOVE section: > > Add support for a new header on MOVE, that will allow client applications to > request that the server perform an atomic operation on MOVE, meaning an > all-or-nothing operation. We'd like to see the header: > > Allow-partial: T/F > > ... added for MOVEs, with the default value being 'T', to preserve > backward-compatibility, and a value of 'F' meaning attempt to perform the > MOVE as an all-or-nothing operation; if the MOVE cannot be performed as an > all-or-nothing operation, return a 412 - precondition failed response (or, > alternatively, a 207 response, that includes all the 412 response for > specific resources). If implementing servers choose not to support this > header, and the value is set to 'F', they MAY return a 400 bad request > response. > ... So what will the client do if the server fails the request? Retry with Allow-Partial: T? How would that be reflected in the UI? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Tue Mar 07 08:42:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcSM-0003OF-Bq for webdav-archive@lists.ietf.org; Tue, 07 Mar 2006 08:42:30 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGcSL-0002ZU-02 for webdav-archive@lists.ietf.org; Tue, 07 Mar 2006 08:42:30 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FGcRB-0001Wt-Mo for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Mar 2006 13:41:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FGcR4-0001Vb-BY for w3c-dist-auth@listhub.w3.org; Tue, 07 Mar 2006 13:41:10 +0000 Received: from agminet01.oracle.com ([141.146.126.228]) by lisa.w3.org with esmtp (Exim 4.50) id 1FGcR1-00076C-HW for w3c-dist-auth@w3.org; Tue, 07 Mar 2006 13:41:09 +0000 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27Devri017415; Tue, 7 Mar 2006 07:40:57 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k27DeuaI002847; Tue, 7 Mar 2006 06:40:56 -0700 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k27Deos3002815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 7 Mar 2006 06:40:51 -0700 Message-ID: <440D8CFC.3040706@oracle.com> Date: Tue, 07 Mar 2006 08:39:08 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList , Calsify WG , WebDAV WG CC: Ted Hardie , Lisa Dusseault , Cyrus Daboo References: <43FD273E.3020702@oracle.com> In-Reply-To: <43FD273E.3020702@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (lisa.w3.org: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FGcR1-00076C-HW 66a4bd708aa2121b11351679867cfbf4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: CalDAV draft Informal Last-Call X-Archived-At: http://www.w3.org/mid/440D8CFC.3040706@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12186 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Mar 2006 13:41:17 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Quick update. We will submit the CalDAV draft for Last Call when Internet-Draft posting will resume after the next IETF meeting. That will give more time to people to review the draft. Cheers, Bernard Bernard Desruisseaux wrote: > > We submitted CalDAV draft -10 to the IETF yesterday. The draft has > not been officially announced yet, but it is already available for > you to review at the following URL: > > http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt > > We would like to submit the CalDAV draft for Last Call in time for > the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do > so, we would like to get as much feedback as possible from the > participants of the "ietf-caldav" mailing list as well as from the > members of the WebDAV and Calsify Working Groups. > > Once officially announced the draft should be available at: > > http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt > > Previous versions of the draft are available at: > > http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ > > Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: > > mailto:ietf-caldav@osafoundation.org > > which is archived at: > > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Reports on the 4 CalDAV Interoperability Events organized by the > Calendaring and Scheduling Consortium (CalConnect) can be found at: > > http://www.calconnect.org/ioppast.html > > Finally, additional information on CalDAV can also be found at: > > http://ietf.webdav.org/caldav/ > > Please review draft -10 and send us feedback/questions/comments. > > Thanks for you help! > > Cheers, > Bernard > > -- > > C.1. Changes in -10 > > a. Added new section about support for X- items when storing data. > > b. Added new precondition to allow servers to reject queries on > unsupported X- items, and a new example. > > c. Added new text about always supporting X- in calendar-data. > > d. Created new section for PUT, COPY and MOVE preconditions. > > e. Report examples re-done with full listing of calendar data in > Appendix. > > f. Removed description of using UID, SUMMARY etc as resource name. > > g. Indicate that calendar object resource may contain only > overridden components. > > h. Add security consideration about not expose details in resource > names. > > i. Add constraint that free-busy-query can only be run on a > collection. > > j. Add preconditions for calendar-timezone property/elements in > MKCALENDAR, PROPPATCH and calendar-query REPORT. > > k. Fix principal-match example. > > > From w3c-dist-auth-request@listhub.w3.org Thu Mar 09 11:01:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNZv-0007Jt-MQ for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 11:01:27 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNZu-0006UI-FE for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 11:01:27 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FHNXS-0006w2-Ka for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Mar 2006 15:58:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FHNXJ-0006uc-PE for w3c-dist-auth@listhub.w3.org; Thu, 09 Mar 2006 15:58:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1FHNXG-0000zo-Qz for w3c-dist-auth@w3.org; Thu, 09 Mar 2006 15:58:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id k29Fwfft025510; Thu, 9 Mar 2006 07:58:41 -0800 Date: Thu, 9 Mar 2006 07:58:41 -0800 Message-Id: <200603091558.k29Fwfft025510@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1FHNXG-0000zo-Qz b28f159676a0c861f85a53e2dd31df22 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 230] tagged lists and repeating URIs X-Archived-At: http://www.w3.org/mid/200603091558.k29Fwfft025510@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12187 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Mar 2006 15:58:54 +0000 X-Spam-Score: 2.0 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=230 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Version|-13 |-14 ------- Additional Comments From julian.reschke@greenbytes.de 2006-03-09 07:58 ------- Checked with IIS 5/Apache moddav/Xythos/SAP KM; none of the servers rejected requests because the same URI appeared in multiple tagged lists. Recommend to close the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@listhub.w3.org Thu Mar 09 11:36:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHO86-0003FZ-JG for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 11:36:46 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHO86-0007pR-1O for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 11:36:46 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FHO7W-0004AY-4L for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Mar 2006 16:36:10 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FHO7N-00048u-8E for w3c-dist-auth@listhub.w3.org; Thu, 09 Mar 2006 16:36:01 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FHO69-0004YQ-PD for w3c-dist-auth@w3.org; Thu, 09 Mar 2006 16:35:59 +0000 Received: from jbaroned600 ([69.107.70.231]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Mar 2006 08:34:38 -0800 From: "John Barone" To: "'Julian Reschke'" Cc: "'Kevin Wiggen'" , Date: Thu, 9 Mar 2006 08:34:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <440D47CE.8090203@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZBw2oIbK5d3eg0SVi3FXsSLwQMtwB0JPsQ Message-ID: X-OriginalArrivalTime: 09 Mar 2006 16:34:38.0453 (UTC) FILETIME=[5BB7C250:01C64397] Received-SPF: none (aji.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FHO69-0004YQ-PD c09fb6f0be8c7dbcecdd97de172ae828 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS00411xIt1Ytx0000080b@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12188 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Mar 2006 16:36:10 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 So, Xythos' opinion is actually that MOVE should be atomic. That's what our customers tell us they expect, that's what we want to provide for them. And honestly, I can think of a real good reason why I'd want to start off with a whole collection, and end up with 2 incomplete collections, that have to be cleaned up. This not only causes problems for the user who performed the operation, but also, potentially, any users that had/have read access to the collection(s) (source and/or target). I was trying to strike a middle ground, since what we're proposing is a change to the spec. The bottom line, is that we'd much prefer the spec. changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then provide some mechanism (maybe Header) to indicate otherwise. Yes, our proposed "compromise" would require clients to change, so in that sense it's not ideal from our perspective. We could change our client technology to make use of the proposed header, but other ubiquitous clients (i.e. Web Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise, and would result in a less than ideal solution for our customers. I don't see the suggestion of implementing REBIND as a workable solution, since that entails implementing/supporting an entirely different spec. for both server and client, introducing a whole host of additional requirements and functionality. While Xythos can certainly choose to implement the Bind spec. on its server, there's nothing to say that clients (particularly the most ubiquitous ones our customers are using) would follow suite; in fact, I'd venture to say they wouldn't, at least not in the foreseeable future. Besides, what we're talking about is the basic WebDAV spec. (2518, 2518-bis), which has established client and server applications supporting it. I don't see suggesting the use of REBIND (which means implementing the Bind spec.) as particularly germane to this discussion. The issue at hand is the behavior and functionality provided by the MOVE method. Regarding your comments Julian... >For the record: but that's exactly the same behavior that the user >gets when moving data across partitions or network shared. ... not sure what OS/filesystem you're referring to here, but if I recall correctly, on Windows, if you try to drag-and-drop a directory across drives (local or network), the OS/filesystem will actually force a copy, and thus a best-effort result would be expected, and is not in dispute (for COPY) by Xythos. Regards, -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, March 07, 2006 12:44 AM To: John Barone Cc: 'Kevin Wiggen'; w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 John Barone wrote: > The concern for us on a MOVE is that the currently specified behavior > is contrary to (what our immediate customer experience tells us) many > users want or expect. Imagine that I as a user issue a MOVE on the > server via an integrated file explorer on the desktop. I start out > with a whole collection, and I drag-and-drop it to a new location on > the server (or simply rename it), and I end up with 2 incomplete > collections, due to permissions or lock conflicts on > sub-collections/resource, with no real indication as to why it > happened, and worse, no indication how to correct the mess I've just > created. Our own customer experience tells us that, in this use case, > users don't want you to allow them to "shoot themselves in the foot". > ... For the record: but that's exactly the same behavior that the user gets when moving data across partitions or network shared. > ... > So, understanding that the specification of MOVE behavior has not > changed between 2518 and 2518-bis, Xythos would like to propose the > following additional capability to the MOVE section: > > Add support for a new header on MOVE, that will allow client > applications to request that the server perform an atomic operation on > MOVE, meaning an all-or-nothing operation. We'd like to see the header: > > Allow-partial: T/F > > ... added for MOVEs, with the default value being 'T', to preserve > backward-compatibility, and a value of 'F' meaning attempt to perform > the MOVE as an all-or-nothing operation; if the MOVE cannot be > performed as an all-or-nothing operation, return a 412 - precondition > failed response (or, alternatively, a 207 response, that includes all > the 412 response for specific resources). If implementing servers > choose not to support this header, and the value is set to 'F', they MAY return a 400 bad request > response. > ... So what will the client do if the server fails the request? Retry with Allow-Partial: T? How would that be reflected in the UI? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 09 16:06:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSLB-0000nJ-Ex for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 16:06:33 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSL8-0001yO-MS for webdav-archive@lists.ietf.org; Thu, 09 Mar 2006 16:06:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FHSKB-0000y1-2Q for w3c-dist-auth-dist@listhub.w3.org; Thu, 09 Mar 2006 21:05:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FHSK2-0000wH-O0; Thu, 09 Mar 2006 21:05:22 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.50) id 1FHSJz-0004cP-NA; Thu, 09 Mar 2006 21:05:22 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k29L52p5020454; Thu, 9 Mar 2006 16:05:02 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k29L52CF225916; Thu, 9 Mar 2006 16:05:02 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k29L52s4030384; Thu, 9 Mar 2006 16:05:02 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k29L52FB030381; Thu, 9 Mar 2006 16:05:02 -0500 In-Reply-To: To: "John Barone" Cc: "'Julian Reschke'" , "'Kevin Wiggen'" , 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 From: Geoffrey M Clemm Message-ID: Date: Thu, 9 Mar 2006 16:04:54 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/09/2006 16:05:01, Serialize complete at 03/09/2006 16:05:01 Content-Type: multipart/alternative; boundary="=_alternative 0073CE0E8525712C_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1FHSJz-0004cP-NA b99eb80b315d988386691ad1f6f9d4d1 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/OFE8E4E2AE.5F6DE514-ON8525712C.0068A93C-8525712C.0073CE80@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12189 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 09 Mar 2006 21:05:31 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b This is a multipart message in MIME format. --=_alternative 0073CE0E8525712C_= Content-Type: text/plain; charset="US-ASCII" John wrote on 03/09/2006 11:34:40 AM: > So, Xythos' opinion is actually that MOVE should be atomic. That's what our > customers tell us they expect, that's what we want to provide for them. I think there are two reasonable desires being expressed here: (1) Your customers want "move" (the logical operation they invoke from your client) to be atomic. Fair enough. You should do what you can to satisfy that desire. (2) Your customers want "MOVE" (the WebDAV method) to be implemented atomically (and not "best effort") by your repository. Fair enough. You are of course free to make MOVE be atomic in your repository (that is certainly what we do). 2518 says that it "SHOULD" be best effort, but given a "SHOULD" from 2518, and a "want" from my customers, I'll go with the "want" from my customers every time (:-). But note that neither of these desires imply that we need to change the definition of MOVE from "SHOULD be best effort" (as defined in 2518) to "SHOULD be atomic". There is no point in doing that because it would just be misleading ... a large number (probably, majority) of WebDAV servers do not make MOVE atomic (unsurprising, since 2518 states that MOVE SHOULD be "best effort", which means non-atomic). Changing the definition in 2518bis would just mislead clients into incorrectly expecting a MOVE to be implemented atomically on the server. Any attempt to make this change is pointless because: - existing servers won't magically change their behavior on MOVE just because the language in the new spec has changed - most of the servers that support best-effort MOVE do so because they cannot implement atomic MOVE. Given the choice of changing their implementation so that it fails all MOVE calls from a client (because it cannot guarantee they are atomic), or continuing to act in a 2518 compliant manner and implements a best-effort MOVE, I have no doubt as to which option they will pick. So what is the only interoperable recourse? Have your server implement atomic MOVE, and define an extension to the protocol that allows a client to say "I insist on an atomic MOVE". There are two possibilities: add a new header to MOVE (that says "I want this to be atomic"), or add a new method whose semantics are "atomic MOVE". The difference between these two is that with a new header, an old server may just ignore the header it doesn't recognize, and do the non-atomic MOVE anyway, whereas with a new method, you are guaranteed that an old server will just fail the operation. When designing the Bind protocol, we concluded that the new method is preferable since the client can simulate the "fall-back to non-atomic" behavior by just issuing a MOVE after a failed REBIND, but cannot simulate the "fail if not supported" with just the header. > And > honestly, I can think of a real good reason why I'd want to start off with a > whole collection, and end up with 2 incomplete collections, that have to be > cleaned up. This not only causes problems for the user who performed the > operation, but also, potentially, any users that had/have read access to the > collection(s) (source and/or target). The repositories that implement a best-effort move argue that this is what their users want. Trying to convince them that their users are wrong or that they do not understand what their users want is usually not a very productive use of any of our time (:-). > I was trying to strike a middle ground, since what we're proposing is a > change to the spec. The bottom line, is that we'd much prefer the spec. > changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then > provide some mechanism (maybe Header) to indicate otherwise. Yes, our > proposed "compromise" would require clients to change, so in that sense it's > not ideal from our perspective. That's not a middle ground ... that is misleading clients into coding against an incorrect assumption ... changing the spec has no effect on all the existing servers that do a best effort MOVE, and all the server implementors who believe that their customers prefer a best effort MOVE and therefore would not agree to the spec change in any case. > We could change our client technology to > make use of the proposed header, but other ubiquitous clients (i.e. Web > Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise, > and would result in a less than ideal solution for our customers. If you think that users of those clients would prefer that your server perform an atomic move (and fail a MOVE if it cannot be guaranteed to be atomic), your server is free to do so. > I don't > see the suggestion of implementing REBIND as a workable solution, since that > entails implementing/supporting an entirely different spec. for both server > and client, introducing a whole host of additional requirements and > functionality. You are confusing two issues: how to marshall an atomic move request, and whether that marshalling is packaged up with other features. We can easily unpackage the REBIND request into a separately supportable feature, if that is what is desired. As indicated above, you cannot get some functionality from existing servers by declaring in some future spec that what they are currently doing violates a new "SHOULD". That is what would be unworkable. Whereas you can implement atomic MOVE on your server, and also upgrade your clients and servers to support an explicit REBIND. > While Xythos can certainly choose to implement the Bind > spec. on its server, there's nothing to say that clients (particularly the > most ubiquitous ones our customers are using) would follow suite; in fact, > I'd venture to say they wouldn't, at least not in the foreseeable future. I don't see how that is relevant to this discussion. The only reason you are implementing REBIND on your server is to be friendly to those clients that explicitly want a REBIND. For all existing clients, you just implement MOVE atomically, since you believe that is what your users want. > Besides, what we're talking about is the basic WebDAV spec. (2518, > 2518-bis), which has established client and server applications supporting > it. I don't see suggesting the use of REBIND (which means implementing the > Bind spec.) as particularly germane to this discussion. The issue at hand > is the behavior and functionality provided by the MOVE method. And that behavior is etched in the stone of many tens (hundreds?) of thousands of existing servers. That just isn't something that is up for debate. So the only relevant discussion for this topic is on how to marshall the new atomic behavior. Cheers, Geoff --=_alternative 0073CE0E8525712C_= Content-Type: text/html; charset="US-ASCII"
John wrote on 03/09/2006 11:34:40 AM:
> So, Xythos' opinion is actually that MOVE should be atomic.  That's what our
> customers tell us they expect, that's what we want to provide for them.

I think there are two reasonable desires being expressed here:

(1) Your customers want "move" (the logical operation they invoke from your client)
to be atomic.  Fair enough.  You should do what you can to satisfy that desire.

(2) Your customers want "MOVE" (the WebDAV method) to be implemented atomically
(and not "best effort") by your repository.  Fair enough.  You are of course
free to make MOVE be atomic in your repository (that is certainly what we do).
2518 says that it "SHOULD" be best effort, but given a "SHOULD" from 2518,
and a "want" from my customers, I'll go with the "want" from my customers
every time (:-).

But note that neither of these desires imply that we need to change the
definition of MOVE from "SHOULD be best effort" (as defined in 2518) to
"SHOULD be atomic".  There is no point in doing that because it would just
be misleading ... a large number (probably, majority) of WebDAV servers do
not make MOVE atomic (unsurprising, since 2518 states that MOVE
SHOULD be "best effort", which means non-atomic).  Changing the definition
in 2518bis would just mislead clients into incorrectly expecting a MOVE
to be implemented atomically on the server.  Any attempt to make this
change is pointless because:
- existing servers won't magically change their behavior on MOVE just
  because the language in the new spec has changed
- most of the servers that support best-effort MOVE do so because they
  cannot implement atomic MOVE.  Given the choice of changing their implementation
  so that it fails all MOVE calls from a client (because it cannot guarantee
  they are atomic), or continuing to act in a 2518 compliant manner and
  implements a best-effort MOVE, I have   no doubt as to which option they will pick.

So what is the only interoperable recourse?  Have your server implement
atomic MOVE, and define an extension to the protocol that allows a
client to say "I insist on an atomic MOVE".  There are two possibilities:
add a new header to MOVE (that says "I want this to be atomic"), or add
a new method whose semantics are "atomic MOVE".  The difference between
these two is that with a new header, an old server may just ignore the
header it doesn't recognize, and do the non-atomic MOVE anyway, whereas
with a new method, you are guaranteed that an old server will just fail
the operation.  When designing the Bind protocol, we concluded that the
new method is preferable since the client can simulate the "fall-back
to non-atomic" behavior by just issuing a MOVE after a failed REBIND,
but cannot simulate the "fail if not supported" with just the header.

> And
> honestly, I can think of a real good reason why I'd want to start off with a
> whole collection, and end up with 2 incomplete collections, that have to be
> cleaned up.  This not only causes problems for the user who performed the
> operation, but also, potentially, any users that had/have read access to the
> collection(s) (source and/or target).  

The repositories that implement a best-effort move argue that this
is what their users want.  Trying to convince them that their users are wrong
or that they do not understand what their users want is usually not a very
productive use of any of our time (:-).

> I was trying to strike a middle ground, since what we're proposing is a
> change to the spec.  The bottom line, is that we'd much prefer the spec.
> changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then
> provide some mechanism (maybe Header) to indicate otherwise.  Yes, our
> proposed "compromise" would require clients to change, so in that sense it's
> not ideal from our perspective.

That's not a middle ground ... that is misleading clients into coding against
an incorrect assumption ... changing the spec has no effect on all the existing
servers that do a best effort MOVE, and all the server implementors who believe
that their customers prefer a best effort MOVE and therefore would not agree to
the spec change in any case.

> We could change our client technology to
> make use of the proposed header, but other ubiquitous clients (i.e. Web
> Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise,
> and would result in a less than ideal solution for our customers.

If you think that users of those clients would prefer that your server
perform an atomic move (and fail a MOVE if it cannot be guaranteed to be
atomic), your server is free to do so.

>  I don't
> see the suggestion of implementing REBIND as a workable solution, since that
> entails implementing/supporting an entirely different spec. for both server
> and client, introducing a whole host of additional requirements and
> functionality.

You are confusing two issues: how to marshall an atomic move request, and whether
that marshalling is packaged up with other features.  We can easily unpackage
the REBIND request into a separately supportable feature, if that is what
is desired.  As indicated above, you cannot get some functionality from existing
servers by declaring in some future spec that what they are currently doing
violates a new "SHOULD".  That is what would be unworkable.  Whereas you can
implement atomic MOVE on your server, and also upgrade your clients
and servers to support an explicit REBIND.

>  While Xythos can certainly choose to implement the Bind
> spec. on its server, there's nothing to say that clients (particularly the
> most ubiquitous ones our customers are using) would follow suite; in fact,
> I'd venture to say they wouldn't, at least not in the foreseeable future.

I don't see how that is relevant to this discussion.
The only reason you are implementing REBIND on your server is to be friendly
to those clients that explicitly want a REBIND.  For all
existing clients, you just implement MOVE atomically, since you believe that is
what your users want.

> Besides, what we're talking about is the basic WebDAV spec. (2518,
> 2518-bis), which has established client and server applications supporting
> it.  I don't see suggesting the use of REBIND (which means implementing the
> Bind spec.) as particularly germane to this discussion.  The issue at hand
> is the behavior and functionality provided by the MOVE method.

And that behavior is etched in the stone of many tens (hundreds?) of thousands
of existing servers.  That just isn't something that is up for debate.  So the only
relevant discussion for this topic is on how to marshall the new atomic behavior.

Cheers,
Geoff
--=_alternative 0073CE0E8525712C_=-- From volodymlentini@assumption.edu Fri Mar 10 03:49:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHdJM-0001IA-Ij for webdav-archive@ietf.org; Fri, 10 Mar 2006 03:49:24 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHdJM-0006rS-GE for webdav-archive@ietf.org; Fri, 10 Mar 2006 03:49:24 -0500 Received: from ar7-m214.net.t-com.hr ([195.29.70.214] helo=assumption.edu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FHdJK-0005Jt-FP for webdav-archive@ietf.org; Fri, 10 Mar 2006 03:49:24 -0500 Message-ID: <000001c6441f$753d89c0$8137a8c0@qro46> Reply-To: "Volodymyr Lentini" From: "Volodymyr Lentini" To: webdav-archive@ietf.org Subject: Re: PaFhramcy news Date: Fri, 10 Mar 2006 03:48:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C643F5.8C6781C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C643F5.8C6781C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x V a a m I e i a u x m $ z 105 (30 mm tabIet ds s) a V r i n a y g b r q a $ n 69 (1 zZ 0 tab aD Iets) a C x i t a q I z i o s $ l 99 (1 aQ 0 tab Yq Iets) =20 And many othe JR r http://gey33.teelialtea.com ------=_NextPart_000_0001_01C643F5.8C6781C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
x V a = a m I e i a u x m $ z 105 = (30 mm  tabIet ds s)
a V r = i n a y g b r q a $ n 69 = (1 zZ 0 tab aD Iets)
a C x = i t a q I z i o s $ l 99 = (1 aQ 0 tab Yq Iets)
 
And many othe JR r http://gey33.teelialtea.com
------=_NextPart_000_0001_01C643F5.8C6781C0-- From vivekaamumfo@fireball.de Fri Mar 10 05:13:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHecr-00058b-El for webdav-archive@ietf.org; Fri, 10 Mar 2006 05:13:37 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHecr-0001Hj-C9 for webdav-archive@ietf.org; Fri, 10 Mar 2006 05:13:37 -0500 Received: from [84.36.5.225] (helo=fireball.de) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FHeco-0005kn-6K for webdav-archive@ietf.org; Fri, 10 Mar 2006 05:13:36 -0500 Message-ID: <000001c6442b$4098dc40$cdf9a8c0@tqr68> Reply-To: "Viveka Mumford" From: "Viveka Mumford" To: webdav-archive@ietf.org Subject: Re: ParEamcy news Date: Fri, 10 Mar 2006 05:13:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64401.57C2D440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64401.57C2D440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable z V x a u I v i j u r m $ s 105 (30 fT tabIet 8D s) u V u i y a d g e r y a $6 s 9 (1 k0 0 tab Uk Iets) u C c i n a s I m i a s $ i 99 ( Hs 10 tabIe 9Z ts) =20 And many my other http://weo19.inthorld.com ------=_NextPart_000_0001_01C64401.57C2D440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
z V x = a u I v i j u r m $ s 105 = (30 fT  tabIet 8D s)
u V u = i y a d g e r y a $6 s 9 = (1 k0 0 tab Uk Iets)
u C c = i n a s I m i a s $ i 99 = ( Hs 10 tabIe 9Z ts)
 
And manyhttp://weo19.inthorld.com ------=_NextPart_000_0001_01C64401.57C2D440-- From w3c-dist-auth-request@listhub.w3.org Sat Mar 11 16:10:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIBLw-000200-8m for webdav-archive@lists.ietf.org; Sat, 11 Mar 2006 16:10:20 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIBLu-0002t2-S7 for webdav-archive@lists.ietf.org; Sat, 11 Mar 2006 16:10:20 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIBKH-0001Wk-08 for w3c-dist-auth-dist@listhub.w3.org; Sat, 11 Mar 2006 21:08:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FIBK9-0001VF-Ag for w3c-dist-auth@listhub.w3.org; Sat, 11 Mar 2006 21:08:29 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1FIBK0-0001XA-5Q for w3c-dist-auth@w3.org; Sat, 11 Mar 2006 21:08:28 +0000 Received: (qmail invoked by alias); 11 Mar 2006 20:41:38 -0000 Received: from p508F95CD.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.149.205] by mail.gmx.net (mp031) with SMTP; 11 Mar 2006 21:41:38 +0100 X-Authenticated: #1915285 Message-ID: <441335AE.3090303@gmx.de> Date: Sat, 11 Mar 2006 21:40:14 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1FIBK0-0001XA-5Q ee1e1aee0e7b0f16e77d45ca6455a153 X-Original-To: w3c-dist-auth@w3.org Subject: Issue 177 (status descriptions) X-Archived-At: http://www.w3.org/mid/441335AE.3090303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12190 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 11 Mar 2006 21:08:37 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f While reviewing issue 177 (), I came to the conclusion that the currently conflates the different usages of status codes inside multistatus. Also, the description of multistatus (Section 13) currently contains incorrect information which is new compared to RFC2518. Below are proposed changes trying to address these problems (see also ): Section 9.1.1., para. 3: OLD: 9.1.2. Status codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. NEW: 9.1.2. Status Codes for use in 'propstat' Element In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. (clarify that this is about status codes in *propstat*). Section 9.2., para. 6: OLD: 9.2.1. Status Codes for use in 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. NEW: 9.2.1. Status Codes for use in 'propstat' Element In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. (clarify that this is about status codes in *propstat*). Section 13., para. 1: OLD: A Multi-Status response contains one 'response' element for each resource in the scope of the request (in no required order) or MAY be empty if no resources match the request. The default 207 (Multi- Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called 'multistatus', which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element. The 207 status code itself MUST NOT be considered a success response, it is only completely successful if all 'response' elements inside contain success status codes. The body of a 207 Multi-Status response MUST contain a URL associated with each specific status code, so that the client can tell whether the error occurred with the source resource, destination resource or some other resource in the scope of the request. (note that the first sentence is plainly incorrect) NEW: The default 207 (Multi-Status) response body is a text/xml or application/xml HTTP entity that contains a single XML element called 'multistatus', which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element. Note that the usage of status code 207 indicates that the recipient needs to consult the contents of the multistatus response body for further information about the result of the method execution, thus it can occur in success, partial success and also in failure situations. Each 'response' element inside the body holds information about one individual resource, identified by the 'href' element, and uses one out of two distinct formats for representing the status: 1. A 'status' element as child of the 'response' element indicates the status of the message excecution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616]. 2. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1.2 and 9.2.1. (rewrite removes incorrect stuff and (hopefully) clarifies the distinct use cases of status codes in multistatus responses). Section 14., para. 0: OLD: Section 9.2.1, Section 9.1.2, Section 9.6.1, Section 9.8.3 and Section 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses. NEW: (deleted) From w3c-dist-auth-request@listhub.w3.org Sun Mar 12 05:53:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIOCV-000080-3z for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 05:53:27 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIOCT-0007kg-TR for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 05:53:27 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIOAf-0000bu-HC for w3c-dist-auth-dist@listhub.w3.org; Sun, 12 Mar 2006 10:51:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FIOAT-0000Yz-8W for w3c-dist-auth@listhub.w3.org; Sun, 12 Mar 2006 10:51:21 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1FIOAR-0001cD-8k for w3c-dist-auth@w3.org; Sun, 12 Mar 2006 10:51:20 +0000 Received: (qmail invoked by alias); 12 Mar 2006 10:51:17 -0000 Received: from p508FA36A.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.106] by mail.gmx.net (mp010) with SMTP; 12 Mar 2006 11:51:17 +0100 X-Authenticated: #1915285 Message-ID: <4413FCE1.9010008@gmx.de> Date: Sun, 12 Mar 2006 11:50:09 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FIOAR-0001cD-8k 6a5028ced7884a3c28ce00fd38f19061 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC of draft-ietf-webdav-rfc2518bis-14.txt X-Archived-At: http://www.w3.org/mid/4413FCE1.9010008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12191 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 12 Mar 2006 10:51:33 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cullen Jennings wrote: > > I am absolutely thrilled to be able to Working Group Last Call (WGLC) > draft-ietf-webdav-rfc2518bis. The WGLC will end on March 15, 2006. > ... Reminder: the last call ends in three days from now. So far we've seen some comments (thanks!), but I'm sure that more people have started reading the draft, but didn't have time to finish and write down their comments. Now is the time! Please post your comments, even if they aren't complete yet! Thanks, Julian From w3c-dist-auth-request@listhub.w3.org Sun Mar 12 07:38:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIPqb-0000w6-07 for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 07:38:57 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIPqZ-0002Yp-Ee for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 07:38:56 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIPp8-000473-Va for w3c-dist-auth-dist@listhub.w3.org; Sun, 12 Mar 2006 12:37:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FIPoz-00044y-Ri for w3c-dist-auth@listhub.w3.org; Sun, 12 Mar 2006 12:37:17 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1FIPow-0006bx-6H for w3c-dist-auth@w3.org; Sun, 12 Mar 2006 12:37:17 +0000 Received: (qmail invoked by alias); 12 Mar 2006 12:37:12 -0000 Received: from p508FA36A.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.106] by mail.gmx.net (mp028) with SMTP; 12 Mar 2006 13:37:12 +0100 X-Authenticated: #1915285 Message-ID: <441415B1.7070703@gmx.de> Date: Sun, 12 Mar 2006 13:36:01 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FIPow-0006bx-6H 4603b22988ddb3faad35a2fc0491d821 X-Original-To: w3c-dist-auth@w3.org Subject: Issue 181, DAV:error X-Archived-At: http://www.w3.org/mid/441415B1.7070703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12192 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 12 Mar 2006 12:37:26 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Following up on issue 181 (), which is about preconditions/postconditions and the DAV:error element, mainly in Section 16. IMHO, the spec as it is today is really in a bad shape, both from an editorial point of view, and regarding correctness/preciseness. The main issues are: 1) General confusion about whether we're talking about condition codes or errors. This is a left-over from early drafts where the RFC3253 was borrowed without actually using it's semantics. As a guideline, every time the spec says "error code" it's likely to be incorrect, because it either should say "status code" (this is the numerical status code defined in RFC2616, and "status" != "error") or "condition code" (that's what we use for pre/postconditions). 2) Spec organization: there's no structure within Section 16, which makes it extremely hard to read, and impossible to directly reference pre/postcondition names. Right now, they don't appear in the TOC nor in an index (because we don't have one; another issue). See for instance ). 3) Mostly, the individual condition descriptions do not define a precondition or a postcondition, but instead talk about error marshalling. This is inconsistent with the usage in all other specs. 4) Condition descriptions are given with an HTTP status code labeled "Used with". Again, this is misleading (a precondition/postcondition is independant of a specific status, and in general the status may vary for the same condition). Also, the same information is already provided in the method definitions; yet another useless repetition of information (with the risk t be inconsistent). 5) Providing DTD fragments for error conditions that are EMPTY is just distracting; please restrict them to the cases where they actually are needed. Some of these issues have been discussed before on teleconferences, see BugZilla issues 220 (), 221 (), 222 () and 223 (), but it doesn't seem I've been able to convince the participants of the calls. So to those who agree, PLEASE SPEAK UP. Also see for a proposal how all problems with this section could be resolved. Below is a set of proposed changes that attempts to address the main problems with terminology. Section 8.7., para. 1: OLD: HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16 NEW: HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (Section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16. Section 9.1.1., para. 2: OLD: 403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body. NEW: 403 Forbidden (with the condition code 'propfind-finite-depth' defined in Section 16) - A server MAY reject PROPFIND requests on collections with depth header of "Infinity". Section 9.2., para. 10: OLD: 403 (Forbidden): The client has attempted to set a read-only property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body. NEW: 403 (Forbidden) (with the condition code 'cannot-modify-protected- property' defined in Section 16) - The client has attempted to set a protected property, such as DAV:getetag. Section 14.5., para. 2: OLD: Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' element SHOULD include an XML element with the code of a failed precondition or postcondition. NEW: Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' element SHOULD include an XML element with the name of a failed precondition or postcondition. Section 16., para. 1: OLD: As introduced in section Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes. NEW: As introduced in Section 8.7, extra information on error conditions can be included in the body of many status responses. This section makes requirements on the use of the error body mechanism and introduces a number of precondition and postcondition codes. Section 16., para. 3: OLD: Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or the resource as a whole. In all other error responses, the XML element MUST be returned as the child of a top- level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements. NEW: Each precondition and postcondition has a unique XML element associated with it. In a 207 Multi-Status response, the XML element MUST appear inside an 'error' element in the appropriate 'propstat or 'response' element depending on whether the condition applies to one or more properties or to the resource as a whole. In all other error responses, the XML element MUST be returned as the child of a top- level 'error' element in the response body, unless otherwise negotiated by the request, along with an appropriate response status. The most common response status codes are 403 (Forbidden) if the request should not be repeated because it will always fail, and 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements. Section 16., para. 4: OLD: This mechanism does not take the place of using a correct numeric error code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric error. However, it does remove the need to define new numeric error codes. The machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally any group defining a new error code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. NEW: This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric status code. However, it does remove the need to define new numeric status codes. The machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions, so naturally any group defining a new condition code can use their own namespace. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. Section 16., para. 5: OLD: A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom error code and other supporting text, because even when clients do not automatically recognize error codes they can be quite useful in interoperability testing and debugging. NEW: A server supporting this specification SHOULD use the XML error whenever a precondition or postcondition defined in this document is violated. For error conditions not specified in this document, the server MAY simply choose an appropriate numeric status and leave the response body blank. However, a server MAY instead use a custom condition code and other supporting text, because even when clients do not automatically recognize status codes they can be quite useful in interoperability testing and debugging. Section 16., para. 6: OLD: Example - Response with precondition code" >>Response NEW: Example - Response with precondition code >>Response Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Sun Mar 12 13:29:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIVKH-0006cB-Ir for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 13:29:57 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIVKF-0005lk-5O for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 13:29:57 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIVIe-0007pK-UF for w3c-dist-auth-dist@listhub.w3.org; Sun, 12 Mar 2006 18:28:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIVIV-0007nS-AZ for w3c-dist-auth@listhub.w3.org; Sun, 12 Mar 2006 18:28:07 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FIVIQ-0000Gz-GJ for w3c-dist-auth@w3.org; Sun, 12 Mar 2006 18:28:06 +0000 Received: (qmail invoked by alias); 12 Mar 2006 18:28:01 -0000 Received: from p508FA36A.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.106] by mail.gmx.net (mp014) with SMTP; 12 Mar 2006 19:28:01 +0100 X-Authenticated: #1915285 Message-ID: <441467DD.9030409@gmx.de> Date: Sun, 12 Mar 2006 19:26:37 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FIVIQ-0000Gz-GJ 7a9d983dfaeada223a4018d78bcc9640 X-Original-To: w3c-dist-auth@w3.org Subject: Issue 202, Lock-Null resources X-Archived-At: http://www.w3.org/mid/441467DD.9030409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12193 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 12 Mar 2006 18:28:16 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Following up on issue 202 ()... I think the current wording in Section 7.3 is extremely confusing, because it describes to different models, of which one is deprecated. Furthermore, it uses way too many words to describe an extremely simple thing (an empty resource that is locked), and gives both models the same amount of room. A very simple change to address this issue is to get rid of most of the text, and move the description of the deprecated model into an appendix (and no, an appendix can be normative if it isn't stated otherwise). Proposed text below and in . Also note that in the text to be deleted, the following paragraph...: The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. ..doesn't make any sense at all. Why "shortly"? What difference does that make? Section 7.3., para. 4: OLD: The original WebDAV model for locking unmapped URLs created "lock- null resources". This model was over-complicated and some interoperability and implementation problems were discovered. The new WebDAV model for locking unmapped URLs creates "locked empty resources". Servers MUST implement either lock-null resources or locked empty resources, but servers SHOULD implement locked empty resources. This section discusses the original model briefly and the new model more completely, because clients MUST be able to handle either model. In the original "lock-null resource" model, which is no longer recommended for implementation: o A lock-null resource sometimes appeared as "Not Found". The server responds with a 404 or 405 to any method except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. o A lock-null resource does however show up as a member of its parent collection. o The server removes the lock-null resource entirely (its URI becomes unmapped) if its lock goes away before it is converted to a regular resource. Recall that locks go away not only when they expire or are unlcoked, but are also removed if a resource is renamed or moved, or if any parent collection is renamed or moved. o The server converts the lock-null resource into a regular resource if a PUT request to the URL is successful. o The server converts the lock-null resource into a collection if a MKCOL request to the URL is successful (though interoperability experience showed that not all servers followed this requirement). o Property values were defined for DAV:lockdiscovery and DAV: supportedlock properties but not necessarily for other properties like DAV:getcontenttype. In the "locked empty resource" model, which is now the recommended implementation, a resource created with a LOCK is empty but otherwise behaves in every way as a normal resource. It behaves the same way as a resource created by a PUT request with an empty body (and where a Content-Type and Content-Language was not specified), followed by a LOCK request to the same resource. Following from this model, a locked empty resource: o Can be read, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource. o Appears as a member of its parent collection. o SHOULD NOT disappear when its lock goes away (clients must therefore be responsible for cleaning up their own mess, as with any other operation or any non-empty resource) o MAY NOT have values for properties like DAV:getcontentlanguage which haven't been specified yet by the client. o Can be updated (have content added) with a PUT request. o MUST NOT be converted into a collection. The server MUST fail a MKCOL request (as it would with a MKCOL request to any existing non-collection resource). o MUST have defined values for DAV:lockdiscovery and DAV: supportedlock properties. o The response MUST indicate that a resource was created, by use of the "201 Created" response code (a LOCK request to an existing resource instead will result in 200 OK). The body must still include the DAV:lockdiscovery property, as with a LOCK request to an existing resource. The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. Clients can easily interoperate both with servers that support the old model "lock-null resources" and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET. NEW: Alternatively and for backwards compatibility to [RFC2518], servers MAY implement Lock-Null Resources (LNRs) instead (see definition in Appendix D). Clients can easily interoperate both with servers that support the old model LNRs and the recommended model of "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET, and by not relying on specific properties of LNRs. NEW: Appendix D. Lock-Null Resources This specification deprecates the "Lock-Null Resources" (LNRs) defined in Section 7.4 of [RFC2518], and replaces them with empty locked regular resources (see Section 7.3). However, it's still legal for servers to implement the deprecated model. A LNR differs from an empty locked resource in the following aspects: o It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. o Most of its live properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. It MUST have defined values for lockdiscovery and supportedlock properties. o Until a method such as PUT or MKCOL is successfully executed on the lock-null resource the resource MUST stay in the lock-null state. However, once a PUT or MKCOL is successfully executed on a lock-null resource the resource ceases to be in the lock-null state. (Note that an LNR thus can be used to create a collection, which is not possible with the simplified empty locked resource model anymore.) o If it is unlocked, for any reason, without a PUT, MKCOL, or similar method having been successfully executed upon it then the resource MUST return to the null state. (Note that with an empty locked resource, an empty regular resource would remain in place.) Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Sun Mar 12 19:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIaUh-0006nY-SP for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 19:01:03 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIaUg-0007xa-4P for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 19:01:03 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIaT2-0004WZ-1v for w3c-dist-auth-dist@listhub.w3.org; Sun, 12 Mar 2006 23:59:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIaSs-0004Ul-5x; Sun, 12 Mar 2006 23:59:10 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1FIaSk-0002xF-Sp; Sun, 12 Mar 2006 23:59:09 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2CNx0H6016535; Sun, 12 Mar 2006 18:59:00 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2CNx0Ob147366; Sun, 12 Mar 2006 18:59:00 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2CNx0cb021420; Sun, 12 Mar 2006 18:59:00 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2CNx0JE021410; Sun, 12 Mar 2006 18:59:00 -0500 In-Reply-To: <441467DD.9030409@gmx.de> To: Julian Reschke Cc: WebDAV , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 12 Mar 2006 18:59:01 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/12/2006 18:58:59, Serialize complete at 03/12/2006 18:58:59 Content-Type: multipart/alternative; boundary="=_alternative 0083BC6B8525712F_=" Received-SPF: none (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1FIaSk-0002xF-Sp ebbafe448824ba15afeb214dc3253137 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Issue 202, Lock-Null resources X-Archived-At: http://www.w3.org/mid/OF47E985FF.6C29AEBA-ON8525712F.00837612-8525712F.0083BD20@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12194 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 12 Mar 2006 23:59:20 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 This is a multipart message in MIME format. --=_alternative 0083BC6B8525712F_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian's comments, and support his proposed changes. Cheers, Geoff Julian wrote on 03/12/2006 01:26:37 PM: > > Following up on issue 202 > ()... > > I think the current wording in Section 7.3 is extremely confusing, > because it describes to different models, of which one is deprecated. > Furthermore, it uses way too many words to describe an extremely simple > thing (an empty resource that is locked), and gives both models the same > amount of room. > > A very simple change to address this issue is to get rid of most of the > text, and move the description of the deprecated model into an appendix > (and no, an appendix can be normative if it isn't stated otherwise). > > Proposed text below and in > latest.html#rfc.issue.bz202>. > Also note that in the text to be deleted, the following paragraph...: > > The client is expected to update the locked empty resource shortly > after locking it, using PUT and possibly PROPPATCH. > > ..doesn't make any sense at all. Why "shortly"? What difference does > that make? > > > Section 7.3., para. 4: > OLD: > > The original WebDAV model for locking unmapped URLs created "lock- > null resources". This model was over-complicated and some > interoperability and implementation problems were discovered. The > new WebDAV model for locking unmapped URLs creates "locked empty > resources". Servers MUST implement either lock-null resources or > locked empty resources, but servers SHOULD implement locked empty > resources. This section discusses the original model briefly and the > new model more completely, because clients MUST be able to handle > either model. > > In the original "lock-null resource" model, which is no longer > recommended for implementation: > > o A lock-null resource sometimes appeared as "Not Found". The > server responds with a 404 or 405 to any method except for PUT, > MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. > > o A lock-null resource does however show up as a member of its > parent collection. > > o The server removes the lock-null resource entirely (its URI > becomes unmapped) if its lock goes away before it is converted to > a regular resource. Recall that locks go away not only when they > expire or are unlcoked, but are also removed if a resource is > renamed or moved, or if any parent collection is renamed or moved. > > o The server converts the lock-null resource into a regular resource > if a PUT request to the URL is successful. > > o The server converts the lock-null resource into a collection if a > MKCOL request to the URL is successful (though interoperability > experience showed that not all servers followed this requirement). > > o Property values were defined for DAV:lockdiscovery and DAV: > supportedlock properties but not necessarily for other properties > like DAV:getcontenttype. > > In the "locked empty resource" model, which is now the recommended > implementation, a resource created with a LOCK is empty but otherwise > behaves in every way as a normal resource. It behaves the same way > as a resource created by a PUT request with an empty body (and where > a Content-Type and Content-Language was not specified), followed by a > LOCK request to the same resource. Following from this model, a > locked empty resource: > > o Can be read, deleted, moved, copied, and in all ways behave as a > regular resource, not a lock-null resource. > > o Appears as a member of its parent collection. > > o SHOULD NOT disappear when its lock goes away (clients must > therefore be responsible for cleaning up their own mess, as with > any other operation or any non-empty resource) > > o MAY NOT have values for properties like DAV:getcontentlanguage > which haven't been specified yet by the client. > > o Can be updated (have content added) with a PUT request. > > o MUST NOT be converted into a collection. The server MUST fail a > MKCOL request (as it would with a MKCOL request to any existing > non-collection resource). > > o MUST have defined values for DAV:lockdiscovery and DAV: > supportedlock properties. > > o The response MUST indicate that a resource was created, by use of > the "201 Created" response code (a LOCK request to an existing > resource instead will result in 200 OK). The body must still > include the DAV:lockdiscovery property, as with a LOCK request to > an existing resource. > > The client is expected to update the locked empty resource shortly > after locking it, using PUT and possibly PROPPATCH. > > Clients can easily interoperate both with servers that support the > old model "lock-null resources" and the recommended model of "locked > empty resources" by only attempting PUT after a LOCK to an unmapped > URL, not MKCOL or GET. > > NEW: > > Alternatively and for backwards compatibility to [RFC2518], servers > MAY implement Lock-Null Resources (LNRs) instead (see definition in > Appendix D). Clients can easily interoperate both with servers that > support the old model LNRs and the recommended model of "locked empty > resources" by only attempting PUT after a LOCK to an unmapped URL, > not MKCOL or GET, and by not relying on specific properties of LNRs. > > > NEW: > > Appendix D. Lock-Null Resources > > This specification deprecates the "Lock-Null Resources" (LNRs) > defined in Section 7.4 of [RFC2518], and replaces them with empty > locked regular resources (see Section 7.3). However, it's still > legal for servers to implement the deprecated model. > > A LNR differs from an empty locked resource in the following aspects: > > o It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) > to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and > UNLOCK. > > o Most of its live properties, such as all the get* properties, will > have no value as a lock-null resource does not support the GET > method. It MUST have defined values for lockdiscovery and > supportedlock properties. > > o Until a method such as PUT or MKCOL is successfully executed on > the lock-null resource the resource MUST stay in the lock-null > state. However, once a PUT or MKCOL is successfully executed on a > lock-null resource the resource ceases to be in the lock-null > state. (Note that an LNR thus can be used to create a collection, > which is not possible with the simplified empty locked resource > model anymore.) > > o If it is unlocked, for any reason, without a PUT, MKCOL, or > similar method having been successfully executed upon it then the > resource MUST return to the null state. (Note that with an empty > locked resource, an empty regular resource would remain in place.) > > > Best regards, Julian > > --=_alternative 0083BC6B8525712F_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian's comments, and support his proposed changes.

Cheers,
Geoff

Julian wrote on 03/12/2006 01:26:37 PM:
>
> Following up on issue 202
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202>)...
>
> I think the current wording in Section 7.3 is extremely confusing,
> because it describes to different models, of which one is deprecated.
> Furthermore, it uses way too many words to describe an extremely simple
> thing (an empty resource that is locked), and gives both models the same
> amount of room.
>
> A very simple change to address this issue is to get rid of most of the
> text, and move the description of the deprecated model into an appendix
> (and no, an appendix can be normative if it isn't stated otherwise).
>
> Proposed text below and in
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.issue.bz202>.
> Also note that in the text to be deleted, the following paragraph...:
>
>      The client is expected to update the locked empty resource shortly
>      after locking it, using PUT and possibly PROPPATCH.
>
> ..doesn't make any sense at all. Why "shortly"? What difference does
> that make?
>
>
> Section 7.3., para. 4:
> OLD:
>
>      The original WebDAV model for locking unmapped URLs created "lock-
>      null resources".  This model was over-complicated and some
>      interoperability and implementation problems were discovered.  The
>      new WebDAV model for locking unmapped URLs creates "locked empty
>      resources".  Servers MUST implement either lock-null resources or
>      locked empty resources, but servers SHOULD implement locked empty
>      resources.  This section discusses the original model briefly and the
>      new model more completely, because clients MUST be able to handle
>      either model.
>
>      In the original "lock-null resource" model, which is no longer
>      recommended for implementation:
>
>      o  A lock-null resource sometimes appeared as "Not Found".  The
>         server responds with a 404 or 405 to any method except for PUT,
>         MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
>
>      o  A lock-null resource does however show up as a member of its
>         parent collection.
>
>      o  The server removes the lock-null resource entirely (its URI
>         becomes unmapped) if its lock goes away before it is converted to
>         a regular resource.  Recall that locks go away not only when they
>         expire or are unlcoked, but are also removed if a resource is
>         renamed or moved, or if any parent collection is renamed or moved.
>
>      o  The server converts the lock-null resource into a regular resource
>         if a PUT request to the URL is successful.
>
>      o  The server converts the lock-null resource into a collection if a
>         MKCOL request to the URL is successful (though interoperability
>         experience showed that not all servers followed this requirement).
>
>      o  Property values were defined for DAV:lockdiscovery and DAV:
>         supportedlock properties but not necessarily for other properties
>         like DAV:getcontenttype.
>
>      In the "locked empty resource" model, which is now the recommended
>      implementation, a resource created with a LOCK is empty but otherwise
>      behaves in every way as a normal resource.  It behaves the same way
>      as a resource created by a PUT request with an empty body (and where
>      a Content-Type and Content-Language was not specified), followed by a
>      LOCK request to the same resource.  Following from this model, a
>      locked empty resource:
>
>      o  Can be read, deleted, moved, copied, and in all ways behave as a
>         regular resource, not a lock-null resource.
>
>      o  Appears as a member of its parent collection.
>
>      o  SHOULD NOT disappear when its lock goes away (clients must
>         therefore be responsible for cleaning up their own mess, as with
>         any other operation or any non-empty resource)
>
>      o  MAY NOT have values for properties like DAV:getcontentlanguage
>         which haven't been specified yet by the client.
>
>      o  Can be updated (have content added) with a PUT request.
>
>      o  MUST NOT be converted into a collection.  The server MUST fail a
>         MKCOL request (as it would with a MKCOL request to any existing
>         non-collection resource).
>
>      o  MUST have defined values for DAV:lockdiscovery and DAV:
>         supportedlock properties.
>
>      o  The response MUST indicate that a resource was created, by use of
>         the "201 Created" response code (a LOCK request to an existing
>         resource instead will result in 200 OK).  The body must still
>         include the DAV:lockdiscovery property, as with a LOCK request to
>         an existing resource.
>
>      The client is expected to update the locked empty resource shortly
>      after locking it, using PUT and possibly PROPPATCH.
>
>      Clients can easily interoperate both with servers that support the
>      old model "lock-null resources" and the recommended model of "locked
>      empty resources" by only attempting PUT after a LOCK to an unmapped
>      URL, not MKCOL or GET.
>
> NEW:
>
>      Alternatively and for backwards compatibility to [RFC2518], servers
>      MAY implement Lock-Null Resources (LNRs) instead (see definition in
>      Appendix D).  Clients can easily interoperate both with servers that
>      support the old model LNRs and the recommended model of "locked empty
>      resources" by only attempting PUT after a LOCK to an unmapped URL,
>      not MKCOL or GET, and by not relying on specific properties of LNRs.
>
>
> NEW:
>
>   Appendix D.  Lock-Null Resources
>
>      This specification deprecates the "Lock-Null Resources" (LNRs)
>      defined in Section 7.4 of [RFC2518], and replaces them with empty
>      locked regular resources (see Section 7.3).  However, it's still
>      legal for servers to implement the deprecated model.
>
>      A LNR differs from an empty locked resource in the following aspects:
>
>      o  It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed)
>         to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and
>         UNLOCK.
>
>      o  Most of its live properties, such as all the get* properties, will
>         have no value as a lock-null resource does not support the GET
>         method.  It MUST have defined values for lockdiscovery and
>         supportedlock properties.
>
>      o  Until a method such as PUT or MKCOL is successfully executed on
>         the lock-null resource the resource MUST stay in the lock-null
>         state.  However, once a PUT or MKCOL is successfully executed on a
>         lock-null resource the resource ceases to be in the lock-null
>         state.  (Note that an LNR thus can be used to create a collection,
>         which is not possible with the simplified empty locked resource
>         model anymore.)
>
>      o  If it is unlocked, for any reason, without a PUT, MKCOL, or
>         similar method having been successfully executed upon it then the
>         resource MUST return to the null state.  (Note that with an empty
>         locked resource, an empty regular resource would remain in place.)
>
>
> Best regards, Julian
>
>
--=_alternative 0083BC6B8525712F_=-- From w3c-dist-auth-request@listhub.w3.org Sun Mar 12 19:34:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIb18-000677-OB for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 19:34:34 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIb16-0000NE-O0 for webdav-archive@lists.ietf.org; Sun, 12 Mar 2006 19:34:34 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIb0Z-0007ni-RY for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 00:33:59 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FIb0R-0007mz-6N for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 00:33:52 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.50) id 1FIb0I-0002q3-9K for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 00:33:50 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2D0Xbpx004517 for ; Sun, 12 Mar 2006 19:33:37 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2D0Xbvh043918 for ; Sun, 12 Mar 2006 19:33:37 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2D0XbJi017402 for ; Sun, 12 Mar 2006 19:33:37 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2D0Xbxb017399 for ; Sun, 12 Mar 2006 19:33:37 -0500 In-Reply-To: <441415B1.7070703@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 12 Mar 2006 19:33:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/12/2006 19:33:36, Serialize complete at 03/12/2006 19:33:36 Content-Type: multipart/alternative; boundary="=_alternative 000311DC85257130_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1FIb0I-0002q3-9K 2a58fbafcf30c00d688ae1efb38d643b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Issue 181, DAV:error X-Archived-At: http://www.w3.org/mid/OF24D20364.86151F4D-ON85257130.00027FCB-85257130.0003128D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12195 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 00:33:59 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: d115f8e98afb84ba4860c5c6ee611921 This is a multipart message in MIME format. --=_alternative 000311DC85257130_= Content-Type: text/plain; charset="US-ASCII" I strongly agree with all of Julian's points below. It was my understanding that the consensus was to adopt the condition code approach taken by all of the other specs, and so these are remnants of the alternative "error code" approach that was rejected by the working group. Cheers, Geoff Julian wrote on 03/12/2006 07:36:01 AM: > > Following up on issue 181 > (), which is > about preconditions/postconditions and the DAV:error element, mainly in > Section 16. > > IMHO, the spec as it is today is really in a bad shape, both from an > editorial point of view, and regarding correctness/preciseness. > > The main issues are: > > 1) General confusion about whether we're talking about condition codes > or errors. This is a left-over from early drafts where the RFC3253 was > borrowed without actually using it's semantics. As a guideline, every > time the spec says "error code" it's likely to be incorrect, because it > either should say "status code" (this is the numerical status code > defined in RFC2616, and "status" != "error") or "condition code" (that's > what we use for pre/postconditions). > > 2) Spec organization: there's no structure within Section 16, which > makes it extremely hard to read, and impossible to directly reference > pre/postcondition names. Right now, they don't appear in the TOC nor in > an index (because we don't have one; another issue). See for instance > ). > > 3) Mostly, the individual condition descriptions do not define a > precondition or a postcondition, but instead talk about error > marshalling. This is inconsistent with the usage in all other specs. > > 4) Condition descriptions are given with an HTTP status code labeled > "Used with". Again, this is misleading (a precondition/postcondition is > independant of a specific status, and in general the status may vary for > the same condition). Also, the same information is already provided in > the method definitions; yet another useless repetition of information > (with the risk t be inconsistent). > > 5) Providing DTD fragments for error conditions that are EMPTY is just > distracting; please restrict them to the cases where they actually are > needed. > > Some of these issues have been discussed before on teleconferences, see > BugZilla issues 220 > (), 221 > (), 222 > () and 223 > (), but it > doesn't seem I've been able to convince the participants of the calls. > So to those who agree, PLEASE SPEAK UP. > > Also see > latest.html#rfc.section.16> > for a proposal how all problems with this section could be resolved. > > Below is a set of proposed changes that attempts to address the main > problems with terminology. > > > > Section 8.7., para. 1: > OLD: > > HTTP and WebDAV did not use the bodies of most error responses for > machine-parsable information until DeltaV introduced a mechanism to > include more specific information in the body of an error response > (section 1.6 of [RFC3253]). The error body mechanism is appropriate > to use with any error response that may take a body but does not > already have a body defined. The mechanism is particularly > appropriate when a status code can mean many things (for example, 400 > Bad Request can mean required headers are missing, headers are > incorrectly formatted, or much more). This error body mechanism is > covered in Section 16 > > NEW: > > HTTP and WebDAV did not use the bodies of most error responses for > machine-parsable information until DeltaV introduced a mechanism to > include more specific information in the body of an error response > (Section 1.6 of [RFC3253]). The error body mechanism is appropriate > to use with any error response that may take a body but does not > already have a body defined. The mechanism is particularly > appropriate when a status code can mean many things (for example, 400 > Bad Request can mean required headers are missing, headers are > incorrectly formatted, or much more). This error body mechanism is > covered in Section 16. > > > Section 9.1.1., para. 2: > OLD: > > 403 Forbidden - A server MAY reject PROPFIND requests on collections > with depth header of "Infinity", in which case it SHOULD use this > error with the precondition code 'propfind-finite-depth' inside the > error body. > > NEW: > > 403 Forbidden (with the condition code 'propfind-finite-depth' > defined in Section 16) - A server MAY reject PROPFIND requests on > collections with depth header of "Infinity". > > Section 9.2., para. 10: > OLD: > > 403 (Forbidden): The client has attempted to set a read-only > property, such as DAV:getetag. If returning this error, the server > SHOULD use the precondition code 'cannot-modify-protected-property' > inside the response body. > > NEW: > > 403 (Forbidden) (with the condition code 'cannot-modify-protected- > property' defined in Section 16) - The client has attempted to set a > protected property, such as DAV:getetag. > > > Section 14.5., para. 2: > OLD: > > Purpose: Error responses, particularly 403 Forbidden and 409 > Conflict, sometimes need more information to indicate what went > wrong. When an error response contains a body in WebDAV, the body > is in XML with the root element 'error'. The 'error' element > SHOULD include an XML element with the code of a failed > precondition or postcondition. > > NEW: > > Purpose: Error responses, particularly 403 Forbidden and 409 > Conflict, sometimes need more information to indicate what went > wrong. When an error response contains a body in WebDAV, the body > is in XML with the root element 'error'. The 'error' element > SHOULD include an XML element with the name of a failed > precondition or postcondition. > > > Section 16., para. 1: > OLD: > > As introduced in section Section 8.7, extra information on error > conditions can be included in the body of many status responses. > This section makes requirements on the use of the error body > mechanism and introduces a number of precondition and postcondition > codes. > > NEW: > > As introduced in Section 8.7, extra information on error conditions > can be included in the body of many status responses. This section > makes requirements on the use of the error body mechanism and > introduces a number of precondition and postcondition codes. > > > Section 16., para. 3: > OLD: > > Each precondition and postcondition has a unique XML element > associated with it. In a 207 Multi-Status response, the XML element > MUST appear inside an 'error' element in the appropriate 'propstat or > 'response' element depending on whether the condition applies to one > or more properties or the resource as a whole. In all other error > responses, the XML element MUST be returned as the child of a top- > level 'error' element in the response body, unless otherwise > negotiated by the request, along with an appropriate response status. > The most common response status codes are 403 (Forbidden) if the > request should not be repeated because it will always fail, and 409 > (Conflict) if it is expected that the user might be able to resolve > the conflict and resubmit the request. The 'error' element MAY > contain child elements with specific error information and MAY be > extended with any custom child elements. > > NEW: > > Each precondition and postcondition has a unique XML element > associated with it. In a 207 Multi-Status response, the XML element > MUST appear inside an 'error' element in the appropriate 'propstat or > 'response' element depending on whether the condition applies to one > or more properties or to the resource as a whole. In all other error > responses, the XML element MUST be returned as the child of a top- > level 'error' element in the response body, unless otherwise > negotiated by the request, along with an appropriate response status. > The most common response status codes are 403 (Forbidden) if the > request should not be repeated because it will always fail, and 409 > (Conflict) if it is expected that the user might be able to resolve > the conflict and resubmit the request. The 'error' element MAY > contain child elements with specific error information and MAY be > extended with any custom child elements. > > > Section 16., para. 4: > OLD: > > This mechanism does not take the place of using a correct numeric > error code as defined here or in HTTP, because the client MUST always > be able to take a reasonable course of action based only on the > numeric error. However, it does remove the need to define new > numeric error codes. The machine-readable codes used for this > purpose are XML elements classified as preconditions and > postconditions, so naturally any group defining a new error code can > use their own namespace. As always, the "DAV:" namespace is reserved > for use by IETF-chartered WebDAV working groups. > > NEW: > > This mechanism does not take the place of using a correct numeric > status code as defined here or in HTTP, because the client MUST > always be able to take a reasonable course of action based only on > the numeric status code. However, it does remove the need to define > new numeric status codes. The machine-readable codes used for this > purpose are XML elements classified as preconditions and > postconditions, so naturally any group defining a new condition code > can use their own namespace. As always, the "DAV:" namespace is > reserved for use by IETF-chartered WebDAV working groups. > > > Section 16., para. 5: > OLD: > > A server supporting this specification SHOULD use the XML error > whenever a precondition or postcondition defined in this document is > violated. For error conditions not specified in this document, the > server MAY simply choose an appropriate numeric status and leave the > response body blank. However, a server MAY instead use a custom > error code and other supporting text, because even when clients do > not automatically recognize error codes they can be quite useful in > interoperability testing and debugging. > > NEW: > > A server supporting this specification SHOULD use the XML error > whenever a precondition or postcondition defined in this document is > violated. For error conditions not specified in this document, the > server MAY simply choose an appropriate numeric status and leave the > response body blank. However, a server MAY instead use a custom > condition code and other supporting text, because even when clients > do not automatically recognize status codes they can be quite useful > in interoperability testing and debugging. > > > Section 16., para. 6: > OLD: > > Example - Response with precondition code" > >>Response > > NEW: > > Example - Response with precondition code > >>Response > > > > > Best regards, Julian > --=_alternative 000311DC85257130_= Content-Type: text/html; charset="US-ASCII"
I strongly agree with all of Julian's points below.

It was my understanding that the consensus was to adopt the condition
code approach taken by all of the other specs, and so these are
remnants of the alternative "error code" approach that was rejected by
the working group.

Cheers,
Geoff

Julian wrote on 03/12/2006 07:36:01 AM:
>
> Following up on issue 181
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181>), which is
> about preconditions/postconditions and the DAV:error element, mainly in
> Section 16.
>
> IMHO, the spec as it is today is really in a bad shape, both from an
> editorial point of view, and regarding correctness/preciseness.
>
> The main issues are:
>
> 1) General confusion about whether we're talking about condition codes
> or errors. This is a left-over from early drafts where the RFC3253 was
> borrowed without actually using it's semantics. As a guideline, every
> time the spec says "error code" it's likely to be incorrect, because it
> either should say "status code" (this is the numerical status code
> defined in RFC2616, and "status" != "error") or "condition code" (that's
> what we use for pre/postconditions).
>
> 2) Spec organization: there's no structure within Section 16, which
> makes it extremely hard to read, and impossible to directly reference
> pre/postcondition names. Right now, they don't appear in the TOC nor in
> an index (because we don't have one; another issue). See for instance
> <http://tools.ietf.org/html/draft-ietf-webdav-rfc2518bis-14.txt#page-107>).
>
> 3) Mostly, the individual condition descriptions do not define a
> precondition or a postcondition, but instead talk about error
> marshalling. This is  inconsistent with the usage in all other specs.
>
> 4) Condition descriptions are given with an HTTP status code labeled
> "Used with". Again, this is misleading (a precondition/postcondition is
> independant of a specific status, and in general the status may vary for
> the same condition). Also, the same information is already provided in
> the method definitions; yet another useless repetition of information
> (with the risk t be inconsistent).
>
> 5) Providing DTD fragments for error conditions that are EMPTY is just
> distracting; please restrict them to the cases where they actually are
> needed.
>
> Some of these issues have been discussed before on teleconferences, see
> BugZilla issues 220
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=220>), 221
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=221>), 222
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=222>) and 223
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=223>), but it
> doesn't seem I've been able to convince the participants of the calls.
> So to those who agree, PLEASE SPEAK UP.
>
> Also see
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.section.16>
> for a proposal how all problems with this section could be resolved.
>
> Below is a set of proposed changes that attempts to address the main
> problems with terminology.
>
>
>
> Section 8.7., para. 1:
> OLD:
>
>      HTTP and WebDAV did not use the bodies of most error responses for
>      machine-parsable information until DeltaV introduced a mechanism to
>      include more specific information in the body of an error response
>      (section 1.6 of [RFC3253]).  The error body mechanism is appropriate
>      to use with any error response that may take a body but does not
>      already have a body defined.  The mechanism is particularly
>      appropriate when a status code can mean many things (for example, 400
>      Bad Request can mean required headers are missing, headers are
>      incorrectly formatted, or much more).  This error body mechanism is
>      covered in Section 16
>
> NEW:
>
>      HTTP and WebDAV did not use the bodies of most error responses for
>      machine-parsable information until DeltaV introduced a mechanism to
>      include more specific information in the body of an error response
>      (Section 1.6 of [RFC3253]).  The error body mechanism is appropriate
>      to use with any error response that may take a body but does not
>      already have a body defined.  The mechanism is particularly
>      appropriate when a status code can mean many things (for example, 400
>      Bad Request can mean required headers are missing, headers are
>      incorrectly formatted, or much more).  This error body mechanism is
>      covered in Section 16.
>
>
> Section 9.1.1., para. 2:
> OLD:
>
>      403 Forbidden - A server MAY reject PROPFIND requests on collections
>      with depth header of "Infinity", in which case it SHOULD use this
>      error with the precondition code 'propfind-finite-depth' inside the
>      error body.
>
> NEW:
>
>      403 Forbidden (with the condition code 'propfind-finite-depth'
>      defined in Section 16) - A server MAY reject PROPFIND requests on
>      collections with depth header of "Infinity".
>
> Section 9.2., para. 10:
> OLD:
>
>      403 (Forbidden): The client has attempted to set a read-only
>      property, such as DAV:getetag.  If returning this error, the server
>      SHOULD use the precondition code 'cannot-modify-protected-property'
>      inside the response body.
>
> NEW:
>
>      403 (Forbidden) (with the condition code 'cannot-modify-protected-
>      property' defined in Section 16) - The client has attempted to set a
>      protected property, such as DAV:getetag.
>
>
> Section 14.5., para. 2:
> OLD:
>
>      Purpose:   Error responses, particularly 403 Forbidden and 409
>         Conflict, sometimes need more information to indicate what went
>         wrong.  When an error response contains a body in WebDAV, the body
>         is in XML with the root element 'error'.  The 'error' element
>         SHOULD include an XML element with the code of a failed
>         precondition or postcondition.
>
> NEW:
>
>      Purpose:   Error responses, particularly 403 Forbidden and 409
>         Conflict, sometimes need more information to indicate what went
>         wrong.  When an error response contains a body in WebDAV, the body
>         is in XML with the root element 'error'.  The 'error' element
>         SHOULD include an XML element with the name of a failed
>         precondition or postcondition.
>
>
> Section 16., para. 1:
> OLD:
>
>      As introduced in section Section 8.7, extra information on error
>      conditions can be included in the body of many status responses.
>      This section makes requirements on the use of the error body
>      mechanism and introduces a number of precondition and postcondition
>      codes.
>
> NEW:
>
>      As introduced in Section 8.7, extra information on error conditions
>      can be included in the body of many status responses.  This section
>      makes requirements on the use of the error body mechanism and
>      introduces a number of precondition and postcondition codes.
>
>
> Section 16., para. 3:
> OLD:
>
>      Each precondition and postcondition has a unique XML element
>      associated with it.  In a 207 Multi-Status response, the XML element
>      MUST appear inside an 'error' element in the appropriate 'propstat or
>      'response' element depending on whether the condition applies to one
>      or more properties or the resource as a whole.  In all other error
>      responses, the XML element MUST be returned as the child of a top-
>      level 'error' element in the response body, unless otherwise
>      negotiated by the request, along with an appropriate response status.
>      The most common response status codes are 403 (Forbidden) if the
>      request should not be repeated because it will always fail, and 409
>      (Conflict) if it is expected that the user might be able to resolve
>      the conflict and resubmit the request.  The 'error' element MAY
>      contain child elements with specific error information and MAY be
>      extended with any custom child elements.
>
> NEW:
>
>      Each precondition and postcondition has a unique XML element
>      associated with it.  In a 207 Multi-Status response, the XML element
>      MUST appear inside an 'error' element in the appropriate 'propstat or
>      'response' element depending on whether the condition applies to one
>      or more properties or to the resource as a whole.  In all other error
>      responses, the XML element MUST be returned as the child of a top-
>      level 'error' element in the response body, unless otherwise
>      negotiated by the request, along with an appropriate response status.
>      The most common response status codes are 403 (Forbidden) if the
>      request should not be repeated because it will always fail, and 409
>      (Conflict) if it is expected that the user might be able to resolve
>      the conflict and resubmit the request.  The 'error' element MAY
>      contain child elements with specific error information and MAY be
>      extended with any custom child elements.
>
>
> Section 16., para. 4:
> OLD:
>
>      This mechanism does not take the place of using a correct numeric
>      error code as defined here or in HTTP, because the client MUST always
>      be able to take a reasonable course of action based only on the
>      numeric error.  However, it does remove the need to define new
>      numeric error codes.  The machine-readable codes used for this
>      purpose are XML elements classified as preconditions and
>      postconditions, so naturally any group defining a new error code can
>      use their own namespace.  As always, the "DAV:" namespace is reserved
>      for use by IETF-chartered WebDAV working groups.
>
> NEW:
>
>      This mechanism does not take the place of using a correct numeric
>      status code as defined here or in HTTP, because the client MUST
>      always be able to take a reasonable course of action based only on
>      the numeric status code.  However, it does remove the need to define
>      new numeric status codes.  The machine-readable codes used for this
>      purpose are XML elements classified as preconditions and
>      postconditions, so naturally any group defining a new condition code
>      can use their own namespace.  As always, the "DAV:" namespace is
>      reserved for use by IETF-chartered WebDAV working groups.
>
>
> Section 16., para. 5:
> OLD:
>
>      A server supporting this specification SHOULD use the XML error
>      whenever a precondition or postcondition defined in this document is
>      violated.  For error conditions not specified in this document, the
>      server MAY simply choose an appropriate numeric status and leave the
>      response body blank.  However, a server MAY instead use a custom
>      error code and other supporting text, because even when clients do
>      not automatically recognize error codes they can be quite useful in
>      interoperability testing and debugging.
>
> NEW:
>
>      A server supporting this specification SHOULD use the XML error
>      whenever a precondition or postcondition defined in this document is
>      violated.  For error conditions not specified in this document, the
>      server MAY simply choose an appropriate numeric status and leave the
>      response body blank.  However, a server MAY instead use a custom
>      condition code and other supporting text, because even when clients
>      do not automatically recognize status codes they can be quite useful
>      in interoperability testing and debugging.
>
>
> Section 16., para. 6:
> OLD:
>
>      Example - Response with precondition code"
>      >>Response
>
> NEW:
>
>      Example - Response with precondition code
>      >>Response
>
>
>
>
> Best regards, Julian
>
--=_alternative 000311DC85257130_=-- From LNPNIGMHCFDVKD@clos.net Sun Mar 12 23:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIepb-0005RD-Rz for webdav-archive@ietf.org; Sun, 12 Mar 2006 23:38:55 -0500 Received: from [12.178.143.34] (helo=12-178-143-34.mo.dialup.ips) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIepS-0007Q2-TO for webdav-archive@ietf.org; Sun, 12 Mar 2006 23:38:55 -0500 Received: from .anu..au ([1] helo=anu..au) by smtp3..co with esmtp id 1A5Ys6-722176-76 Message-ID: Sender: freeradius-devel-LNPNIGMHCFDVKD@clos.net X-Mailman-Version: 2.0.1 Date: Mon, 13 Mar 2006 07:29:33 +0300 From: "Graham Allred" To: webdav-archive@ietf.org Subject: Termination Alert of your Easyspeedy account X-Spam-Score: 2.8 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a -Sensattional revolution in meedicine! -Enlarge your p`enis up to 10 cm or up to 4 inches! -It's herbal solution what hasn't side effect, but has 100% guaranteeed results! -Don`'t loose your chance and but know wihtout doubts,, you will be impressed with results!!! Clisk h`ere: http://ultimatefatblaster.info From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 06:33:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlIo-0000Bp-RE for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 06:33:30 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIlIn-0002uS-He for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 06:33:30 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIlHD-0003du-SY for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 11:31:51 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIlH4-0003au-EN for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 11:31:42 +0000 Received: from smtp1.x-tention.at ([193.228.97.20]) by maggie.w3.org with esmtp (Exim 4.50) id 1FIlGp-0003hZ-1O for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 11:31:41 +0000 Received: by smtp1.x-tention.at (Postfix, from userid 100) id 25BDB288FE8; Mon, 13 Mar 2006 12:31:26 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by smtp1.x-tention.at (Postfix) with ESMTP id D15EB204406 for ; Mon, 13 Mar 2006 12:31:25 +0100 (CET) Received: from smtp1.x-tention.at ([127.0.0.1]) by localhost (smtp1.x-tention.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09170-01 for ; Mon, 13 Mar 2006 12:31:24 +0100 (CET) Received: from xtdcmx01.ks.local (xtdcmx01.ks.local [10.3.4.12]) by smtp1.x-tention.at (Postfix) with ESMTP id E114026BE1E for ; Mon, 13 Mar 2006 12:31:23 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64691.A84EF941" Date: Mon, 13 Mar 2006 12:31:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: folder view in frames Thread-Index: AcZGkagra+/nCGaDTFWRy1eXClEsnQ== From: "Praehauser Julia" To: X-Virus-Scanned: by amavisd-new at x-tention.at Received-SPF: none (maggie.w3.org: domain of Julia.Praehauser@x-tention.at does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1FIlGp-0003hZ-1O 371d4ca54fe7ebb13265821e938336da X-Original-To: w3c-dist-auth@w3.org Subject: folder view in frames X-Archived-At: http://www.w3.org/mid/E1653397FC1DC040848C18F5D165693C10D874@xtdcmx01.ks.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12196 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 11:31:51 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C64691.A84EF941 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I have a html-page with 2 frames, the one frame is empty and the other one has an onload-function in the body which opens the folder view of a webdav directory. The problem is, when I doubleclick one folder that the frames are missing and it is no Internet Explorer Window any more (more like a Windows Explorer Window). I have the frames only to be able to close this window by javascript. =20 Can anybody help me?? ------_=_NextPart_001_01C64691.A84EF941 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have a html-page with 2 frames, the one = frame is empty and the other one has an onload-function in the body which opens = the folder view of a webdav directory. The problem is, when I doubleclick = one folder that the frames are missing and it is no Internet Explorer Window = any more (more like a Windows Explorer Window). I have the frames only to be = able to close this window by javascript.

 

Can anybody help = me??

------_=_NextPart_001_01C64691.A84EF941-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 12:56:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrH6-0007aO-JS for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 12:56:08 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrH5-00070W-O1 for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 12:56:08 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIrFp-00017H-2B for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 17:54:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIrFg-00016A-9T; Mon, 13 Mar 2006 17:54:40 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FIrFZ-0002wB-9R; Mon, 13 Mar 2006 17:54:39 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Mar 2006 09:54:30 -0800 From: "John Barone" To: "'Geoffrey M Clemm'" Cc: "'Julian Reschke'" , "'Kevin Wiggen'" , , Date: Mon, 13 Mar 2006 09:54:33 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C64684.220A0FF0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZDvSl0BZCjbRGTRNSRwEtgD4TAOQDBkxmQ In-Reply-To: Message-ID: X-OriginalArrivalTime: 13 Mar 2006 17:54:30.0321 (UTC) FILETIME=[2D8BCA10:01C646C7] Received-SPF: none (maggie.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FIrFZ-0002wB-9R f9173a47199aa2f1a743e1157d4e1bb2 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS0041184zr4T900000c79@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12197 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 17:54:49 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C64684.220A0FF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You state that the SHOULD language surrounding the "best-effort" behavior of MOVE allows us to implement the operation as "all-or-nothing" and still be compliant with the spec.; fair enough. However, I'd think that the SHOULD language in a spec. should lean in the direction of the desired/expected behavior. From Xythos' perspective, "best-effort" is not the desired behavior, but then again, we're just one voice. If the belief is that "best-effort" is the consensus for the desired behavior when MOVEing a collection, then so be it. However, if in future revisions the language changes to a MUST, then Xythos would have to argue vigorously against such a change. > You are confusing two issues: how to marshall an atomic move request, and whether > that marshalling is packaged up with other features. We can easily unpackage > the REBIND request into a separately supportable feature, if that is what > is desired. I don't know that I was confusing these 2 issues at all, since I don't recall you stating or implying that REBIND (or some similar method) could be unpackaged and included in this spec., until now. If we were to add such a method to the 2518-bis spec., then I'd suggest method names of MOVE-ALL, MOVE-ATOMIC, or MOVE-COMPLETE, rather than REBIND, which just doesn't have the same meaning when taken out of the context of the binding spec. Regards, -John _____ From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] Sent: Thursday, March 09, 2006 1:05 PM To: John Barone Cc: 'Julian Reschke'; 'Kevin Wiggen'; w3c-dist-auth@w3.org; w3c-dist-auth-request@w3.org Subject: RE: Comments on the "new" 2518 John wrote on 03/09/2006 11:34:40 AM: > So, Xythos' opinion is actually that MOVE should be atomic. That's what our > customers tell us they expect, that's what we want to provide for them. I think there are two reasonable desires being expressed here: (1) Your customers want "move" (the logical operation they invoke from your client) to be atomic. Fair enough. You should do what you can to satisfy that desire. (2) Your customers want "MOVE" (the WebDAV method) to be implemented atomically (and not "best effort") by your repository. Fair enough. You are of course free to make MOVE be atomic in your repository (that is certainly what we do). 2518 says that it "SHOULD" be best effort, but given a "SHOULD" from 2518, and a "want" from my customers, I'll go with the "want" from my customers every time (:-). But note that neither of these desires imply that we need to change the definition of MOVE from "SHOULD be best effort" (as defined in 2518) to "SHOULD be atomic". There is no point in doing that because it would just be misleading ... a large number (probably, majority) of WebDAV servers do not make MOVE atomic (unsurprising, since 2518 states that MOVE SHOULD be "best effort", which means non-atomic). Changing the definition in 2518bis would just mislead clients into incorrectly expecting a MOVE to be implemented atomically on the server. Any attempt to make this change is pointless because: - existing servers won't magically change their behavior on MOVE just because the language in the new spec has changed - most of the servers that support best-effort MOVE do so because they cannot implement atomic MOVE. Given the choice of changing their implementation so that it fails all MOVE calls from a client (because it cannot guarantee they are atomic), or continuing to act in a 2518 compliant manner and implements a best-effort MOVE, I have no doubt as to which option they will pick. So what is the only interoperable recourse? Have your server implement atomic MOVE, and define an extension to the protocol that allows a client to say "I insist on an atomic MOVE". There are two possibilities: add a new header to MOVE (that says "I want this to be atomic"), or add a new method whose semantics are "atomic MOVE". The difference between these two is that with a new header, an old server may just ignore the header it doesn't recognize, and do the non-atomic MOVE anyway, whereas with a new method, you are guaranteed that an old server will just fail the operation. When designing the Bind protocol, we concluded that the new method is preferable since the client can simulate the "fall-back to non-atomic" behavior by just issuing a MOVE after a failed REBIND, but cannot simulate the "fail if not supported" with just the header. > And > honestly, I can think of a real good reason why I'd want to start off with a > whole collection, and end up with 2 incomplete collections, that have to be > cleaned up. This not only causes problems for the user who performed the > operation, but also, potentially, any users that had/have read access to the > collection(s) (source and/or target). The repositories that implement a best-effort move argue that this is what their users want. Trying to convince them that their users are wrong or that they do not understand what their users want is usually not a very productive use of any of our time (:-). > I was trying to strike a middle ground, since what we're proposing is a > change to the spec. The bottom line, is that we'd much prefer the spec. > changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then > provide some mechanism (maybe Header) to indicate otherwise. Yes, our > proposed "compromise" would require clients to change, so in that sense it's > not ideal from our perspective. That's not a middle ground ... that is misleading clients into coding against an incorrect assumption ... changing the spec has no effect on all the existing servers that do a best effort MOVE, and all the server implementors who believe that their customers prefer a best effort MOVE and therefore would not agree to the spec change in any case. > We could change our client technology to > make use of the proposed header, but other ubiquitous clients (i.e. Web > Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise, > and would result in a less than ideal solution for our customers. If you think that users of those clients would prefer that your server perform an atomic move (and fail a MOVE if it cannot be guaranteed to be atomic), your server is free to do so. > I don't > see the suggestion of implementing REBIND as a workable solution, since that > entails implementing/supporting an entirely different spec. for both server > and client, introducing a whole host of additional requirements and > functionality. You are confusing two issues: how to marshall an atomic move request, and whether that marshalling is packaged up with other features. We can easily unpackage the REBIND request into a separately supportable feature, if that is what is desired. As indicated above, you cannot get some functionality from existing servers by declaring in some future spec that what they are currently doing violates a new "SHOULD". That is what would be unworkable. Whereas you can implement atomic MOVE on your server, and also upgrade your clients and servers to support an explicit REBIND. > While Xythos can certainly choose to implement the Bind > spec. on its server, there's nothing to say that clients (particularly the > most ubiquitous ones our customers are using) would follow suite; in fact, > I'd venture to say they wouldn't, at least not in the foreseeable future. I don't see how that is relevant to this discussion. The only reason you are implementing REBIND on your server is to be friendly to those clients that explicitly want a REBIND. For all existing clients, you just implement MOVE atomically, since you believe that is what your users want. > Besides, what we're talking about is the basic WebDAV spec. (2518, > 2518-bis), which has established client and server applications supporting > it. I don't see suggesting the use of REBIND (which means implementing the > Bind spec.) as particularly germane to this discussion. The issue at hand > is the behavior and functionality provided by the MOVE method. And that behavior is etched in the stone of many tens (hundreds?) of thousands of existing servers. That just isn't something that is up for debate. So the only relevant discussion for this topic is on how to marshall the new atomic behavior. Cheers, Geoff ------=_NextPart_000_0000_01C64684.220A0FF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
You=20 state that the SHOULD language surrounding the "best-effort" = behavior=20 of MOVE allows us to implement the operation as = "all-or-nothing" and still=20 be compliant with the spec.; fair enough.  However, I'd think that=20 the SHOULD language in a spec. should lean in the = direction of=20 the desired/expected behavior.   From Xythos' perspective,=20 "best-effort" is not the desired behavior, but then again, we're just = one=20 voice.  If the belief is that "best-effort" is the consensus for = the=20 desired behavior when MOVEing a collection, then so be it.  = However, if in=20 future revisions the language changes to a MUST, then Xythos would have = to argue=20 vigorously against such a change.
 
 
> You are confusing two issues: = how to=20 marshall an atomic move request, and whether
> = that marshalling=20 is packaged up with other features.  We can easily=20 unpackage
> the REBIND request into a = separately=20 supportable feature, if that is what
> is = desired.
 
I don't know that I was confusing these 2 = issues at=20 all, since I don't recall you stating or implying that REBIND (or = some=20 similar method) could be unpackaged and included in this spec., = until=20 now. 
If we=20 were to add such a method to the 2518-bis spec., then I'd suggest method = names=20 of MOVE-ALL, MOVE-ATOMIC, or MOVE-COMPLETE, rather than REBIND, which = just=20 doesn't have the same meaning when taken out of the context of the = binding=20 spec.
 
 
Regards,
 
-John
 

From: Geoffrey M Clemm=20 [mailto:geoffrey.clemm@us.ibm.com]
Sent: Thursday, March 09, = 2006=20 1:05 PM
To: John Barone
Cc: 'Julian Reschke'; 'Kevin = Wiggen'; w3c-dist-auth@w3.org; = w3c-dist-auth-request@w3.org
Subject:=20 RE: Comments on the "new" 2518


John = wrote on=20 03/09/2006 11:34:40 AM:
> So, Xythos' opinion is actually that = MOVE should=20 be atomic.  That's what our
> customers tell us they expect, = that's=20 what we want to provide for them.

I think=20 there are two reasonable desires being expressed here: =

(1) Your customers want "move" (the logical operation they = invoke=20 from your client)
to be atomic. =  Fair=20 enough.  You should do what you can to satisfy that = desire.=20

(2) Your customers want "MOVE" (the WebDAV = method) to=20 be implemented atomically
(and not = "best=20 effort") by your repository.  Fair enough.  You are of=20 course
free to make MOVE be atomic in = your=20 repository (that is certainly what we do).
2518=20 says that it "SHOULD" be best effort, but given a "SHOULD" from=20 2518,
and a "want" from my customers, = I'll go=20 with the "want" from my customers
every time=20 (:-).

But note that neither of = these=20 desires imply that we need to change the
definition of MOVE from "SHOULD be best effort" (as defined = in 2518)=20 to
"SHOULD be atomic".  There is = no point=20 in doing that because it would just
be=20 misleading ... a large number (probably, majority) of WebDAV servers=20 do
not make MOVE atomic = (unsurprising, since=20 2518 states that MOVE
SHOULD be "best = effort",=20 which means non-atomic).  Changing the definition =
in 2518bis would just mislead clients into incorrectly = expecting a=20 MOVE
to be implemented atomically on = the=20 server.  Any attempt to make this
change=20 is pointless because:
- existing = servers won't=20 magically change their behavior on MOVE just
  because the language in the new spec has = changed=20
- most of the servers that support best-effort = MOVE do so=20 because they
  cannot implement = atomic=20 MOVE.  Given the choice of changing their = implementation=20
  so that it fails all MOVE calls from a = client=20 (because it cannot guarantee
  = they are=20 atomic), or continuing to act in a 2518 compliant manner and =
  implements a best-effort MOVE, I have =   no=20 doubt as to which option they will pick.

So=20 what is the only interoperable recourse?  Have your server=20 implement
atomic MOVE, and define an = extension=20 to the protocol that allows a
client = to say "I=20 insist on an atomic MOVE".  There are two = possibilities:=20
add a new header to MOVE (that says "I want this = to be=20 atomic"), or add
a new method whose = semantics=20 are "atomic MOVE".  The difference between
these two is that with a new header, an old server may just = ignore=20 the
header it doesn't recognize, and = do the=20 non-atomic MOVE anyway, whereas
with = a new=20 method, you are guaranteed that an old server will just fail =
the operation.  When designing the Bind = protocol, we=20 concluded that the
new method is = preferable=20 since the client can simulate the "fall-back
to=20 non-atomic" behavior by just issuing a MOVE after a failed = REBIND,=20
but cannot simulate the "fail if not supported" = with just=20 the header.

> And
> = honestly, I=20 can think of a real good reason why I'd want to start off with a
> = whole=20 collection, and end up with 2 incomplete collections, that have to = be
>=20 cleaned up.  This not only causes problems for the user who = performed=20 the
> operation, but also, potentially, any users that had/have = read=20 access to the
> collection(s) (source and/or target). =  =20

The repositories that implement a best-effort = move=20 argue that this
is what their users = want.=20  Trying to convince them that their users are wrong =
or that they do not understand what their users want is = usually not a=20 very
productive use of any of our = time=20 (:-).

> I was trying to strike a middle ground, since what = we're=20 proposing is a
> change to the spec.  The bottom line, is = that we'd=20 much prefer the spec.
> changed to say that MOVE SHOULD be atomic, = meaning=20 all-or-nothing, and then
> provide some mechanism (maybe Header) = to=20 indicate otherwise.  Yes, our
> proposed "compromise" would = require=20 clients to change, so in that sense it's
> not ideal from our=20 perspective.

That's not a middle = ground ...=20 that is misleading clients into coding against
an incorrect assumption ... changing the spec has no effect = on all=20 the existing
servers that do a best = effort=20 MOVE, and all the server implementors who believe
that their customers prefer a best effort MOVE and = therefore would=20 not agree to
the spec change in any=20 case.

> We could change our = client=20 technology to
> make use of the proposed header, but other = ubiquitous=20 clients (i.e. Web
> Folders, MS Dav Client, Mac Dav Client) would = not=20 necessarily do likewise,
> and would result in a less than ideal = solution=20 for our customers.

If you think = that users=20 of those clients would prefer that your server
perform an atomic move (and fail a MOVE if it cannot be = guaranteed to=20 be
atomic), your server is free to do = so.=20

>  I don't
> see = the=20 suggestion of implementing REBIND as a workable solution, since = that
>=20 entails implementing/supporting an entirely different spec. for both=20 server
> and client, introducing a whole host of additional = requirements=20 and
> functionality.

You = are=20 confusing two issues: how to marshall an atomic move request, and=20 whether
that marshalling is packaged = up with=20 other features.  We can easily unpackage
the REBIND request into a separately supportable feature, = if that is=20 what
is desired.  As indicated = above, you=20 cannot get some functionality from existing
servers by declaring in some future spec that what they are = currently=20 doing
violates a new "SHOULD". =  That is=20 what would be unworkable.  Whereas you can
implement atomic MOVE on your server, and also upgrade your = clients=20
and servers to support an explicit=20 REBIND.

>  While Xythos = can=20 certainly choose to implement the Bind
> spec. on its server, = there's=20 nothing to say that clients (particularly the
> most ubiquitous = ones our=20 customers are using) would follow suite; in fact,
> I'd venture to = say=20 they wouldn't, at least not in the foreseeable future. =

I don't see how that is relevant to this = discussion.=20
The only reason you are implementing REBIND on = your server=20 is to be friendly
to those clients = that=20 explicitly want a REBIND.  For all
existing clients, you just implement MOVE atomically, since = you=20 believe that is
what your users=20 want.

> Besides, what we're = talking=20 about is the basic WebDAV spec. (2518,
> 2518-bis), which has = established=20 client and server applications supporting
> it.  I don't see=20 suggesting the use of REBIND (which means implementing the
> Bind = spec.)=20 as particularly germane to this discussion.  The issue at = hand
> is=20 the behavior and functionality provided by the MOVE method.=20

And that behavior is etched in the stone of = many tens=20 (hundreds?) of thousands
of existing = servers.=20  That just isn't something that is up for debate.  So the=20 only
relevant discussion for this = topic is on=20 how to marshall the new atomic behavior.

Cheers, =
Geoff
------=_NextPart_000_0000_01C64684.220A0FF0-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 13:24:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrix-0003ns-33 for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 13:24:55 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIriv-00084F-9M for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 13:24:55 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIriV-0001Zf-KI for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 18:24:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIriL-0001Y8-9R; Mon, 13 Mar 2006 18:24:17 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by maggie.w3.org with esmtp (Exim 4.50) id 1FIriA-0000le-R7; Mon, 13 Mar 2006 18:24:15 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Mar 2006 10:24:05 -0800 From: "John Barone" To: "'Geoffrey M Clemm'" , "'Julian Reschke'" Cc: "'WebDAV'" , Date: Mon, 13 Mar 2006 10:24:09 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C64688.43D384F0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZGMTrFy7ot2l/xQY+Vfr7D17PrGwAmgaug In-Reply-To: Message-ID: X-OriginalArrivalTime: 13 Mar 2006 18:24:05.0059 (UTC) FILETIME=[4F5F5130:01C646CB] Received-SPF: none (maggie.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FIriA-0000le-R7 3903c5b80cfde999b62ba61e0d3ce753 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Issue 202, Lock-Null resources X-Archived-At: http://www.w3.org/mid/NSNOVPS00411SGfM7Qu00000c82@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12198 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 18:24:27 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C64688.43D384F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit +1 -John _____ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Sunday, March 12, 2006 3:59 PM To: Julian Reschke Cc: WebDAV; w3c-dist-auth-request@w3.org Subject: Re: Issue 202, Lock-Null resources I agree with Julian's comments, and support his proposed changes. Cheers, Geoff Julian wrote on 03/12/2006 01:26:37 PM: > > Following up on issue 202 > ()... > > I think the current wording in Section 7.3 is extremely confusing, > because it describes to different models, of which one is deprecated. > Furthermore, it uses way too many words to describe an extremely simple > thing (an empty resource that is locked), and gives both models the same > amount of room. > > A very simple change to address this issue is to get rid of most of the > text, and move the description of the deprecated model into an appendix > (and no, an appendix can be normative if it isn't stated otherwise). > > Proposed text below and in > latest.html#rfc.issue.bz202>. > Also note that in the text to be deleted, the following paragraph...: > > The client is expected to update the locked empty resource shortly > after locking it, using PUT and possibly PROPPATCH. > > ..doesn't make any sense at all. Why "shortly"? What difference does > that make? > > > Section 7.3., para. 4: > OLD: > > The original WebDAV model for locking unmapped URLs created "lock- > null resources". This model was over-complicated and some > interoperability and implementation problems were discovered. The > new WebDAV model for locking unmapped URLs creates "locked empty > resources". Servers MUST implement either lock-null resources or > locked empty resources, but servers SHOULD implement locked empty > resources. This section discusses the original model briefly and the > new model more completely, because clients MUST be able to handle > either model. > > In the original "lock-null resource" model, which is no longer > recommended for implementation: > > o A lock-null resource sometimes appeared as "Not Found". The > server responds with a 404 or 405 to any method except for PUT, > MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK. > > o A lock-null resource does however show up as a member of its > parent collection. > > o The server removes the lock-null resource entirely (its URI > becomes unmapped) if its lock goes away before it is converted to > a regular resource. Recall that locks go away not only when they > expire or are unlcoked, but are also removed if a resource is > renamed or moved, or if any parent collection is renamed or moved. > > o The server converts the lock-null resource into a regular resource > if a PUT request to the URL is successful. > > o The server converts the lock-null resource into a collection if a > MKCOL request to the URL is successful (though interoperability > experience showed that not all servers followed this requirement). > > o Property values were defined for DAV:lockdiscovery and DAV: > supportedlock properties but not necessarily for other properties > like DAV:getcontenttype. > > In the "locked empty resource" model, which is now the recommended > implementation, a resource created with a LOCK is empty but otherwise > behaves in every way as a normal resource. It behaves the same way > as a resource created by a PUT request with an empty body (and where > a Content-Type and Content-Language was not specified), followed by a > LOCK request to the same resource. Following from this model, a > locked empty resource: > > o Can be read, deleted, moved, copied, and in all ways behave as a > regular resource, not a lock-null resource. > > o Appears as a member of its parent collection. > > o SHOULD NOT disappear when its lock goes away (clients must > therefore be responsible for cleaning up their own mess, as with > any other operation or any non-empty resource) > > o MAY NOT have values for properties like DAV:getcontentlanguage > which haven't been specified yet by the client. > > o Can be updated (have content added) with a PUT request. > > o MUST NOT be converted into a collection. The server MUST fail a > MKCOL request (as it would with a MKCOL request to any existing > non-collection resource). > > o MUST have defined values for DAV:lockdiscovery and DAV: > supportedlock properties. > > o The response MUST indicate that a resource was created, by use of > the "201 Created" response code (a LOCK request to an existing > resource instead will result in 200 OK). The body must still > include the DAV:lockdiscovery property, as with a LOCK request to > an existing resource. > > The client is expected to update the locked empty resource shortly > after locking it, using PUT and possibly PROPPATCH. > > Clients can easily interoperate both with servers that support the > old model "lock-null resources" and the recommended model of "locked > empty resources" by only attempting PUT after a LOCK to an unmapped > URL, not MKCOL or GET. > > NEW: > > Alternatively and for backwards compatibility to [RFC2518], servers > MAY implement Lock-Null Resources (LNRs) instead (see definition in > Appendix D). Clients can easily interoperate both with servers that > support the old model LNRs and the recommended model of "locked empty > resources" by only attempting PUT after a LOCK to an unmapped URL, > not MKCOL or GET, and by not relying on specific properties of LNRs. > > > NEW: > > Appendix D. Lock-Null Resources > > This specification deprecates the "Lock-Null Resources" (LNRs) > defined in Section 7.4 of [RFC2518], and replaces them with empty > locked regular resources (see Section 7.3). However, it's still > legal for servers to implement the deprecated model. > > A LNR differs from an empty locked resource in the following aspects: > > o It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) > to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and > UNLOCK. > > o Most of its live properties, such as all the get* properties, will > have no value as a lock-null resource does not support the GET > method. It MUST have defined values for lockdiscovery and > supportedlock properties. > > o Until a method such as PUT or MKCOL is successfully executed on > the lock-null resource the resource MUST stay in the lock-null > state. However, once a PUT or MKCOL is successfully executed on a > lock-null resource the resource ceases to be in the lock-null > state. (Note that an LNR thus can be used to create a collection, > which is not possible with the simplified empty locked resource > model anymore.) > > o If it is unlocked, for any reason, without a PUT, MKCOL, or > similar method having been successfully executed upon it then the > resource MUST return to the null state. (Note that with an empty > locked resource, an empty regular resource would remain in place.) > > > Best regards, Julian > > ------=_NextPart_000_000B_01C64688.43D384F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
+1
 
-John

From: w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M=20 Clemm
Sent: Sunday, March 12, 2006 3:59 PM
To: = Julian=20 Reschke
Cc: WebDAV; = w3c-dist-auth-request@w3.org
Subject:=20 Re: Issue 202, Lock-Null resources


I agree with Julian's comments, and = support his=20 proposed changes.

Cheers,=20
Geoff

Julian wrote on=20 03/12/2006 01:26:37 PM:
>
> Following up on issue 202 =
>=20 (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D202>)...=
>=20
> I think the current wording in Section 7.3 is extremely = confusing,=20
> because it describes to different models, of which one is = deprecated.=20
> Furthermore, it uses way too many words to describe an = extremely simple=20
> thing (an empty resource that is locked), and gives both models = the=20 same
> amount of room.
>
> A very simple change to = address=20 this issue is to get rid of most of the
> text, and move the = description=20 of the deprecated model into an appendix
> (and no, an appendix = can be=20 normative if it isn't stated otherwise).
>
> Proposed text = below=20 and in
>=20 <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
= >=20 latest.html#rfc.issue.bz202>.
> Also note that in the text to = be=20 deleted, the following paragraph...:
>
>     =  The=20 client is expected to update the locked empty resource shortly
> =  =20    after locking it, using PUT and possibly PROPPATCH.
> =
> ..doesn't make any sense at all. Why "shortly"? What difference = does=20
> that make?
>
>
> Section 7.3., para. = 4:
>=20 OLD:
>
>      The original WebDAV model for = locking=20 unmapped URLs created "lock-
>      null = resources".=20  This model was over-complicated and some
>    =20  interoperability and implementation problems were discovered.=20  The
>      new WebDAV model for locking = unmapped URLs=20 creates "locked empty
>      resources". =  Servers MUST=20 implement either lock-null resources or
>     =  locked empty=20 resources, but servers SHOULD implement locked empty
>   =  =20  resources.  This section discusses the original model briefly = and=20 the
>      new model more completely, because = clients MUST=20 be able to handle
>      either model.
> =
>=20      In the original "lock-null resource" model, which is = no=20 longer
>      recommended for = implementation:
>=20
>      o  A lock-null resource sometimes = appeared as=20 "Not Found".  The
>         server = responds with=20 a 404 or 405 to any method except for PUT,
>       =  =20 MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.
>
>     =  o=20  A lock-null resource does however show up as a member of = its
>=20         parent collection.
>
>   =  =20  o  The server removes the lock-null resource entirely (its=20 URI
>         becomes unmapped) if its lock = goes away=20 before it is converted to
>         a regular=20 resource.  Recall that locks go away not only when they
> =  =20       expire or are unlcoked, but are also removed if a = resource=20 is
>         renamed or moved, or if any = parent=20 collection is renamed or moved.
>
>      o =  The=20 server converts the lock-null resource into a regular resource
> =  =20       if a PUT request to the URL is successful.
> =
>=20      o  The server converts the lock-null resource = into a=20 collection if a
>         MKCOL request to the = URL is=20 successful (though interoperability
>        =20 experience showed that not all servers followed this = requirement).
>=20
>      o  Property values were defined for=20 DAV:lockdiscovery and DAV:
>         = supportedlock=20 properties but not necessarily for other properties
>   =    =20   like DAV:getcontenttype.
>
>      In = the=20 "locked empty resource" model, which is now the recommended
> =  =20    implementation, a resource created with a LOCK is empty but = otherwise
>      behaves in every way as a normal = resource.=20  It behaves the same way
>      as a resource = created=20 by a PUT request with an empty body (and where
>     =  a=20 Content-Type and Content-Language was not specified), followed by = a
>=20      LOCK request to the same resource.  Following = from this=20 model, a
>      locked empty resource:
> =
>=20      o  Can be read, deleted, moved, copied, and in = all ways=20 behave as a
>         regular resource, not a=20 lock-null resource.
>
>      o  Appears = as a=20 member of its parent collection.
>
>      o=20  SHOULD NOT disappear when its lock goes away (clients must
> =  =20       therefore be responsible for cleaning up their own = mess, as=20 with
>         any other operation or any = non-empty=20 resource)
>
>      o  MAY NOT have = values for=20 properties like DAV:getcontentlanguage
>       =   which=20 haven't been specified yet by the client.
>
>     =  o=20  Can be updated (have content added) with a PUT request.
> =
>=20      o  MUST NOT be converted into a collection. =  The=20 server MUST fail a
>         MKCOL request (as = it=20 would with a MKCOL request to any existing
>       =  =20 non-collection resource).
>
>      o =  MUST have=20 defined values for DAV:lockdiscovery and DAV:
>     =  =20   supportedlock properties.
>
>      o=20  The response MUST indicate that a resource was created, by use = of
>=20         the "201 Created" response code (a LOCK = request to=20 an existing
>         resource instead will = result in=20 200 OK).  The body must still
>         = include=20 the DAV:lockdiscovery property, as with a LOCK request to
>   =  =20     an existing resource.
>
>     =  The=20 client is expected to update the locked empty resource shortly
> =  =20    after locking it, using PUT and possibly PROPPATCH.
> =
>      Clients can easily interoperate both with = servers=20 that support the
>      old model "lock-null = resources" and=20 the recommended model of "locked
>      empty = resources" by=20 only attempting PUT after a LOCK to an unmapped
>     =  URL,=20 not MKCOL or GET.
>
> NEW:
>
>    =20  Alternatively and for backwards compatibility to [RFC2518],=20 servers
>      MAY implement Lock-Null Resources = (LNRs)=20 instead (see definition in
>      Appendix D).=20  Clients can easily interoperate both with servers that
> =  =20    support the old model LNRs and the recommended model of = "locked=20 empty
>      resources" by only attempting PUT = after a LOCK=20 to an unmapped URL,
>      not MKCOL or GET, and by = not=20 relying on specific properties of LNRs.
>
>
> = NEW:
>=20
>   Appendix D.  Lock-Null Resources
>
> =  =20    This specification deprecates the "Lock-Null Resources"=20 (LNRs)
>      defined in Section 7.4 of [RFC2518], = and=20 replaces them with empty
>      locked regular = resources=20 (see Section 7.3).  However, it's still
>     =  legal=20 for servers to implement the deprecated model.
>
>   =  =20  A LNR differs from an empty locked resource in the following=20 aspects:
>
>      o  It MUST respond = with a 404=20 (Not Found) or 405 (Method Not Allowed)
>       =   to=20 any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and
> =  =20       UNLOCK.
>
>      o =  Most=20 of its live properties, such as all the get* properties, will
> =  =20       have no value as a lock-null resource does not = support the=20 GET
>         method.  It MUST have = defined=20 values for lockdiscovery and
>         = supportedlock=20 properties.
>
>      o  Until a method = such as=20 PUT or MKCOL is successfully executed on
>       =   the=20 lock-null resource the resource MUST stay in the lock-null
> =    =20     state.  However, once a PUT or MKCOL is successfully = executed=20 on a
>         lock-null resource the resource = ceases=20 to be in the lock-null
>         state. =  (Note=20 that an LNR thus can be used to create a collection,
>   =  =20     which is not possible with the simplified empty locked=20 resource
>         model anymore.)
> =
>=20      o  If it is unlocked, for any reason, without a = PUT,=20 MKCOL, or
>         similar method having been = successfully executed upon it then the
>       =  =20 resource MUST return to the null state.  (Note that with an = empty
>=20         locked resource, an empty regular resource = would=20 remain in place.)
>
>
> Best regards, Julian
> =
>
------=_NextPart_000_000B_01C64688.43D384F0-- From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 14:05:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsMV-0003Vg-B6 for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:05:47 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsMU-000172-1E for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:05:47 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIsLi-0002ul-9a for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 19:04:58 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FIsLZ-0002tO-Of for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 19:04:49 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.50) id 1FIsLW-0001Ru-1c for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 19:04:48 +0000 Received: (qmail invoked by alias); 13 Mar 2006 19:04:41 -0000 Received: from p508FA9BF.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.191] by mail.gmx.net (mp010) with SMTP; 13 Mar 2006 20:04:41 +0100 X-Authenticated: #1915285 Message-ID: <4415C202.4010704@gmx.de> Date: Mon, 13 Mar 2006 20:03:30 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Geoffrey M Clemm' , 'Kevin Wiggen' , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FIsLW-0001Ru-1c d32bc6cc5a0aa841d62271417d11abb1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/4415C202.4010704@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12199 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 19:04:58 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a John Barone wrote: > You state that the SHOULD language surrounding the "best-effort" > behavior of MOVE allows us to implement the operation as > "all-or-nothing" and still be compliant with the spec.; fair enough. > However, I'd think that the SHOULD language in a spec. should lean in > the direction of the desired/expected behavior. From Xythos' > perspective, "best-effort" is not the desired behavior, but then again, > we're just one voice. If the belief is that "best-effort" is the > consensus for the desired behavior when MOVEing a collection, then so be > it. However, if in future revisions the language changes to a MUST, > then Xythos would have to argue vigorously against such a change. > ... Hi, I'd like to emphasize that - as far as I can tell - nobody is suggesting any change like that. The RFC2518 language IMHO accurately reflects the fact that an implementation of MOVE varies a lot based on the underlying technology, and that there simply *are* cases where it can't be done atomically. Require it to be atomically, and those implementations that can't do it will either ignore the requirement, or stop supporting MOVE. I don't think this is what anybody wants. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 14:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsbO-0004s2-Ju for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:21:10 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsbM-0001b3-Bk for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:21:10 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIsb1-0008TC-6t for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 19:20:47 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FIsat-0008SI-9K for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 19:20:39 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.50) id 1FIsaq-0004D7-0Q for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 19:20:38 +0000 Received: (qmail invoked by alias); 13 Mar 2006 19:13:52 -0000 Received: from p508FA9BF.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.191] by mail.gmx.net (mp019) with SMTP; 13 Mar 2006 20:13:52 +0100 X-Authenticated: #1915285 Message-ID: <4415C42D.9010009@gmx.de> Date: Mon, 13 Mar 2006 20:12:45 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Praehauser Julia CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FIsaq-0004D7-0Q 63d656db9f258e8e64c31bb26cb616aa X-Original-To: w3c-dist-auth@w3.org Subject: Re: folder view in frames X-Archived-At: http://www.w3.org/mid/4415C42D.9010009@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12200 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 19:20:47 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Praehauser Julia wrote: > Hello, > > > > I have a html-page with 2 frames, the one frame is empty and the other > one has an onload-function in the body which opens the folder view of a > webdav directory. The problem is, when I doubleclick one folder that the > frames are missing and it is no Internet Explorer Window any more (more > like a Windows Explorer Window). I have the frames only to be able to > close this window by javascript. > > > > Can anybody help me?? Hi, I fear that to answer this question, one needs to understand the details about how Windows Explorer / Webfolder and Internet Explorer interact. I certainly don't. Maybe asking somewhere where lots of IE experts are around would make more sense. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 14:30:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIskX-00034R-Vr for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:30:37 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIskX-0001mV-L0 for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:30:37 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIskA-00023p-LV for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 19:30:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FIsk6-0001vD-So; Mon, 13 Mar 2006 19:30:10 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FIsk3-0001ci-9F; Mon, 13 Mar 2006 19:30:10 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Mar 2006 11:30:00 -0800 From: "John Barone" To: "'Julian Reschke'" Cc: "'Geoffrey M Clemm'" , "'Kevin Wiggen'" , , Date: Mon, 13 Mar 2006 11:30:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZG0P0YQli4/5VAS3a8/m3WtEwE8wAALzgg In-Reply-To: <4415C202.4010704@gmx.de> Message-ID: X-OriginalArrivalTime: 13 Mar 2006 19:30:00.0752 (UTC) FILETIME=[85262B00:01C646D4] Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FIsk3-0001ci-9F 0bd49227d59650da8256bf4ab91ac092 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS00411GXSXCWV00000c91@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12201 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 19:30:14 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Perhaps I'm beating a dead horse on this point, but I'll throw in one final $.02, before I let it go... > Require it to be atomically, and those implementations that can't do it > will either ignore the requirement, or stop supporting MOVE. I don't > think this is what anybody wants. We're not proposing *requiring* the all or nothing behavior, and never have. We're just trying to make the point that in a spec., one would think that SHOULD language leans in the direction of the desired behavior. In other words, you're recommending what the behavior should be. In the case of moving a collection, Xythos doesn't agree that the behavior SHOULD be "best-effort", but rather "all-or" nothing. If the consensus is that "best-effort" is indeed the desired behavior, then fine, we're in the minority. If however, the SHOULD language is there because (as you put it Julian, and I think Geoff alluded to) "The RFC2518 language IMHO accurately reflects the fact that an implementation of MOVE varies a lot based on the underlying technology, and that there simply *are* cases where it can't be done atomically." (i.e. a lot of servers *can't* implement it that way, for whatever reason), then perhaps we should look more closely at why the language is the way it is. Do we sacrifice desired behavior for feasibility in implementation? You could also argue the point that strictly from a compliance perspective "SHOULD be all-or-nothing" wouldn't change the compliance of existing servers; although it would certainly change the "intended" behavior. ... like I said, my final $.02 on that particular point, and now I'll let it go. However, I would like to continue pursuing adding the ability for a client to request an all-or-nothing MOVE operation. It would be nice to add a METHOD: MOVE-ALL (or MOVE-ATOMIC, or MOVE-COMPLETE) ... which MAY be implemented by a server, and if implemented MUST result in an all-or-nothing MOVE. Regards, -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, March 13, 2006 11:04 AM To: John Barone Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org; w3c-dist-auth-request@w3.org Subject: Re: Comments on the "new" 2518 John Barone wrote: > You state that the SHOULD language surrounding the "best-effort" > behavior of MOVE allows us to implement the operation as > "all-or-nothing" and still be compliant with the spec.; fair enough. > However, I'd think that the SHOULD language in a spec. should lean in > the direction of the desired/expected behavior. From Xythos' > perspective, "best-effort" is not the desired behavior, but then > again, we're just one voice. If the belief is that "best-effort" is > the consensus for the desired behavior when MOVEing a collection, then > so be it. However, if in future revisions the language changes to a > MUST, then Xythos would have to argue vigorously against such a change. > ... Hi, I'd like to emphasize that - as far as I can tell - nobody is suggesting any change like that. The RFC2518 language IMHO accurately reflects the fact that an implementation of MOVE varies a lot based on the underlying technology, and that there simply *are* cases where it can't be done atomically. Require it to be atomically, and those implementations that can't do it will either ignore the requirement, or stop supporting MOVE. I don't think this is what anybody wants. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 14:38:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIssG-0007l4-5S for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:38:36 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIssE-0001t7-UG for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:38:36 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIsrr-0004Rr-4a for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 19:38:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIsrk-0004Qj-Ha for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 19:38:04 +0000 Received: from pv105234.reshsg.uci.edu ([128.195.105.234]) by maggie.w3.org with smtp (Exim 4.50) id 1FIsrh-0000GW-Ma for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 19:38:03 +0000 Received: (qmail 10667 invoked by uid 501); 13 Mar 2006 19:37:59 -0000 Message-ID: <20060313193759.10666.qmail@pv105234.reshsg.uci.edu> References: In-Reply-To: From: Joe Feise To: "Praehauser Julia" Cc: w3c-dist-auth@w3.org Date: Mon, 13 Mar 2006 11:37:59 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of jfeise@pv105234.reshsg.uci.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FIsrh-0000GW-Ma 5225f9aee00737a595274a6518eb5209 X-Original-To: w3c-dist-auth@w3.org Subject: Re: folder view in frames X-Archived-At: http://www.w3.org/mid/20060313193759.10666.qmail@pv105234.reshsg.uci.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12202 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 19:38:11 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Praehauser Julia writes: > Hello, > > > > I have a html-page with 2 frames, the one frame is empty and the other > one has an onload-function in the body which opens the folder view of a > webdav directory. The problem is, when I doubleclick one folder that the > frames are missing and it is no Internet Explorer Window any more (more > like a Windows Explorer Window). I have the frames only to be able to > close this window by javascript. > > > > Can anybody help me?? > Hmm, as Julian mentioned, this is probably a side-effect of how IE/Explorer handle WebDAV displays. Microsoft provides a Shell extension to display WebDAV folders, e.g., when using the Network Neighborhood to browse to a WebDAV folder. My assumption is that this gets triggered when you double-click a WebDAV folder in IE. You would probably need to do some registry magic to avoid this (and that would have other side-effects.) Cheers, -Joe From w3c-dist-auth-request@listhub.w3.org Mon Mar 13 14:43:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsxB-0003Ex-9L for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:43:41 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsxA-00020N-0G for webdav-archive@lists.ietf.org; Mon, 13 Mar 2006 14:43:41 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FIswu-0005P2-8y for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Mar 2006 19:43:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FIswp-0005OD-F3 for w3c-dist-auth@listhub.w3.org; Mon, 13 Mar 2006 19:43:19 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1FIswm-0001Ja-2a for w3c-dist-auth@w3.org; Mon, 13 Mar 2006 19:43:18 +0000 Received: (qmail invoked by alias); 13 Mar 2006 19:43:15 -0000 Received: from p508FA9BF.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.191] by mail.gmx.net (mp032) with SMTP; 13 Mar 2006 20:43:15 +0100 X-Authenticated: #1915285 Message-ID: <4415CB0D.8000104@gmx.de> Date: Mon, 13 Mar 2006 20:42:05 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Geoffrey M Clemm' , 'Kevin Wiggen' , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FIswm-0001Ja-2a 74ae40ce35633c945d31b27cada15b47 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/4415CB0D.8000104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12203 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 13 Mar 2006 19:43:24 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 John Barone wrote: > Perhaps I'm beating a dead horse on this point, but I'll throw in one final > $.02, before I let it go... > >> Require it to be atomically, and those implementations that can't do it >> will either ignore the requirement, or stop supporting MOVE. I don't >> think this is what anybody wants. > > We're not proposing *requiring* the all or nothing behavior, and never have. > We're just trying to make the point that in a spec., one would think that > SHOULD language leans in the direction of the desired behavior. In other > words, you're recommending what the behavior should be. In the case of > moving a collection, Xythos doesn't agree that the behavior SHOULD be > "best-effort", but rather "all-or" nothing. If the consensus is that > "best-effort" is indeed the desired behavior, then fine, we're in the > minority. No, I think that's a misunderstanding about what "SHOULD" (as defined in RFC2119) means. When the spec says "SHOULD", that indicates that clients can in general rely on that. If what you're after is text that tells server implementors that an atomic MOVE in general is more useful than a best-effort move, I do agree that this wouldn't hurt. However may impression is that a server implementor who *can* do it atomically will do it anyway, so I'm not sure whether it really helps. > If however, the SHOULD language is there because (as you put it Julian, and > I think Geoff alluded to) "The RFC2518 language IMHO accurately reflects the > fact that an implementation of MOVE varies a lot based on the underlying > technology, and that there simply *are* cases where it can't be done > atomically." (i.e. a lot of servers *can't* implement it that way, for > whatever reason), then perhaps we should look more closely at why the > language is the way it is. Do we sacrifice desired behavior for feasibility > in implementation? You could also argue the point that strictly from a > compliance perspective "SHOULD be all-or-nothing" wouldn't change the > compliance of existing servers; although it would certainly change the > "intended" behavior. > > > ... like I said, my final $.02 on that particular point, and now I'll let it > go. However, I would like to continue pursuing adding the ability for a > client to request an all-or-nothing MOVE operation. It would be nice to add > a METHOD: > > MOVE-ALL (or MOVE-ATOMIC, or MOVE-COMPLETE) > > ... which MAY be implemented by a server, and if implemented MUST result in > an all-or-nothing MOVE. Again, what's wrong with REBIND? You can implement REBIND without implementing anything else in the BIND spec. For that matter, you'd probably want to implement UNBIND as well (as DELETE shares the non-atomic properties with MOVE). Best regards, Julian From angraa@fbu-ho.org.uk Tue Mar 14 10:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBXe-0005Fr-Vj for webdav-archive@ietf.org; Tue, 14 Mar 2006 10:34:34 -0500 Received: from [62.211.217.216] (helo=fbu-ho.org.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJBXb-0004jv-Aq for webdav-archive@ietf.org; Tue, 14 Mar 2006 10:34:34 -0500 Message-ID: <000001c6477c$c5bb96c0$c4baa8c0@pts16> Reply-To: "Angra Niemann" From: "Angra Niemann" To: webdav-archive@ietf.org Subject: Re: PharakXmacy news Date: Tue, 14 Mar 2006 10:34:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64752.DCE58EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.7 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64752.DCE58EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 d C x i s a z I s i t s $9 v 9 (1 yt 0 x p i i u l e l e s d ) h V i a j I n i w u b m $1 w 05 (3 Zq 0 n p q i v l c l x s v ) c V w i a a h g u r h a $6 d 9 (1 w4 0 n p l i k l g l d s t ) =20 Many othe Eh r, V 20 isit our si f9 te and S VA ave o up ver 5 aq 0% ------=_NextPart_000_0001_01C64752.DCE58EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
d C x i s a z I s i t s $9 v 9 (1 yt 0  x p i i u l e l e s d )
h V i a j I n i w u b m $1 w 05 (3 Zq 0  n p q i v l c l x s v )
c V w i a a h g u r h a $6 d 9 (1 w4 0  n p l i k l g l d s t )
 
Many othe Eh r, V 20 isit our si f9 te and S VA ave o up ver 5 aq 0%
------=_NextPart_000_0001_01C64752.DCE58EC0-- From w3c-dist-auth-request@listhub.w3.org Tue Mar 14 12:24:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDFj-0001G3-JG for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 12:24:11 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDFh-0008Al-VU for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 12:24:11 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJDEd-0000Is-VC for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Mar 2006 17:23:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJDEW-0000HL-PI for w3c-dist-auth@listhub.w3.org; Tue, 14 Mar 2006 17:22:56 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.50) id 1FJDEN-00049n-Jr for w3c-dist-auth@w3.org; Tue, 14 Mar 2006 17:22:56 +0000 Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 5E6CC273D8 for ; Tue, 14 Mar 2006 18:22:44 +0100 (CET) Message-ID: <4416FBE5.90201@greenbytes.de> Date: Tue, 14 Mar 2006 18:22:45 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJDEN-00049n-Jr 52296c5a6afb0ebb23e7287b92681562 X-Original-To: w3c-dist-auth@w3.org Subject: feedback on rfc2518bis-14 X-Archived-At: http://www.w3.org/mid/4416FBE5.90201@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12204 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Mar 2006 17:23:03 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e Section 1, para. 2: > ... Also, the ability to link pages of any media type to related pages. Maybe it's only me, but i have no idea what exactly this sentence is refering to. Section 1, para. 5: > Namespace Operations: The ability to instruct the server to copy and > move Web resources, operations which change the URL. I think the wording could be more accurate here, maybe something like: '... operations which change the mapping from URLs to resources.' Section 3, para. 5: > Internal Member (of a Collection) - Informally, a child resource of a > collection. Formally, a resource referenced by a path segment > contained in the collection. As explained later in section 5, a collection contains mappings from path segments to resources and not the path segments themselves. Section 5.1, para. 4: > Although implicit in [RFC2616] and [RFC3986], any resource, including > collection resources, MAY be identified by more than one URI. For > example, a resource could be identified by multiple HTTP URLs. > So any resource may be identified by multiple URIs, although it's implicit in [RFC2616] and [RFC3986]? The intended meaning of this sentence is probably that this is _mentioned_ although it's implicit. Section 5: Here a collection is defined to contain mappings from path segments to resources, but later on, the containment relation is used with respect to resources, too. Section 5 should explain what this means (something like 'as a shortcut, a resource B will be said to be contained in the collection resource A if there is a path segment mapping which maps to B and wich is contained in A ). Without additional text, it would be formally incorrect to say that a collection contains its internal members. Section 5.2, para. 3: > For all WebDAV compliant resources A and B, identified by URLs "U" and > "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST be a > collection that contains a mapping from "SEGMENT" to B. So, if > resource B with URL "http://example.com/bar/blah" is WebDAV compliant > and if resource A with URL "http://example.com/bar/" is WebDAV > compliant, then resource A must be a collection and must contain at > least one mapping from "blah" to B. I think the collection must contain exactly one mapping from "blah" to B, not at least one. Section 5.3, para. 5: > If a WebDAV compliant resource has no WebDAV compliant children in > the HTTP URL namespace hierarchy then the WebDAV compliant resource > is not required to be a collection. > After the technical term 'internal member' has been invented, I think it should be used consistently instead of 'child'. Section 6: There are two reasons why I am a little unhappy with this section: It contains way to much redundance, and the abstract entity 'lock' together with its applicable operations (for example: adding a resource to a lock, adding an URI to a lock ...) is completely undefined. I will address this in a separate mail. Section 6.1.2: > A resource becomes directly locked when a LOCK request to the URL > of that resource creates a new lock. Should be: '... a LOCK request to an URL ...' Section 6.1.4: > * If an internal member resource is added to the collection, and > if the new member resource does not already have a conflicting > lock, then the resource MUST become indirectly locked by L. > > * If an internal member resource stops being a member of the > collection, then the resource MUST no longer be indirectly > locked by L. > Should be: 'member resource' instead of 'internal member resource' in both places. Section 7, para. 2: > An exclusive write lock will prevent parallel changes to a resource The word 'parallel' should be dropped. Section 7.1: > Only dead properties and live properties defined to respect locks are > guaranteed not to change while write locked. > So there are live properties which are lockable and may change their values while they are locked, and there are live properties which respect locks and must not change their values while they are locked? Is this really intended or is this section historical and should be dropped? Section 7.3: This section is generally quite verbose on lock-null resources. Since these are deprecated, text addressing them should be moved to an appendix. Section 7.3 para. 3: > A successful lock request to an unmapped URL MUST result in the > creation of an locked resource with empty content. Better: '... creation of a locked non-collection resource with empty content'. Section 7.3 para. 5: > expire or are unlcoked, but are also removed if a resource is > renamed or moved, or if any parent collection is renamed or moved. > better: 'expire or are unlocked, but are also removed if a resource is moved, or if any parent collection is moved'. Section 7.3 para. 6: > In the "locked empty resource" model, which is now the recommended > implementation, a resource created with a LOCK is empty but otherwise > behaves in every way as a normal resource. It behaves the same way > as a resource created by a PUT request with an empty body (and where > a Content-Type and Content-Language was not specified), followed by a > LOCK request to the same resource. Following from this model, a > locked empty resource: > > o Can be read, deleted, moved, copied, and in all ways behave as a > regular resource, not a lock-null resource. > > o Appears as a member of its parent collection. > > o SHOULD NOT disappear when its lock goes away (clients must > therefore be responsible for cleaning up their own mess, as with > any other operation or any non-empty resource) > > o MAY NOT have values for properties like DAV:getcontentlanguage > which haven't been specified yet by the client. > > o Can be updated (have content added) with a PUT request. > > o MUST NOT be converted into a collection. The server MUST fail a > MKCOL request (as it would with a MKCOL request to any existing > non-collection resource). > > o MUST have defined values for DAV:lockdiscovery and DAV: > supportedlock properties. > > o The response MUST indicate that a resource was created, by use of > the "201 Created" response code (a LOCK request to an existing > resource instead will result in 200 OK). The body must still > include the DAV:lockdiscovery property, as with a LOCK request to > an existing resource. IMHO, this can be dropped completely, since it is not the case that 'a resource is empty but otherwise behaves in every way as a normal resource'. Rather an empty resource _is_ a completely normal resource. No need to say anything about it. Section 7.3 para. 7: > The client is expected to update the locked empty resource shortly > after locking it, using PUT and possibly PROPPATCH. What am I missing here? Why is the client expected to do this? Section 7.4 para. 1: > There are two kinds of collection write locks. A "Depth 0" write > lock on a collection protects the collection metadata plus the > internal member URLs of that collection, while not protecting the > content or metadata of child resources. The term 'metadata' has not been defined anywhere in this specification. Furthermore, I'd prefer using the term 'internal member' instead of 'child resource'. > A "Depth: infinity" write > lock on a collection provides the same protection on that collection > and also protects every descendent resource as if that resource were > itself write locked. > I'd prefer 'member' instead of descendent'. Furthermore, the wording 'as if' seems unappropriate, since the members _are_ indeed write locked. Section 7.4 para. 2: > Expressed otherwise, a write lock protects any request that would > create a new resource in a write locked collection, any request that > would remove an internal member URL of a write locked collection, and > any request that would change the binding name of a member URL. > The term 'binding name' is undefined in this specification. Section 7.4 para. 3: In the list of specific actions a locked collection is protected from, replace 'member' with 'internal member' everywhere (or simply drop the list, since it does not contain anything new). > In addition, a depth-infinity lock affects all write operations to > all descendents of the locked collection. With a depth-infinity > lock, the root of the lock is directly locked, and all its > descendants are indirectly locked. > Replace 'descendents' with 'members' (I will not continue to repeat this comment everytime, it turns out that it applies at a lot of places). Furthermore, not the root of the lock is locked directly, but the resource which the root is mapped to. Section 7.5 para.1: > If a user agent is not required to have knowledge about a lock when > requesting an operation on a locked resource, the following scenario > might occur. For reasons of clarity, I prefer: 'A user agent is required to have knowledge about a lock when requesting an operation on a locked resource to prevent the following scenario:' Section 7.7 > A client MUST NOT submit the same write lock request twice. Why not? The client will get an error response on the second request, but that is perfectly ok. > If an error is received in response to a refresh LOCK request the > client MUST NOT assume that the lock was refreshed. > Yes. I think this is quite clear. If the method failed, the client must not assume that it succeeded. :) IMHO, Sections 7.6 and 7.7 can be dropped without causing any harm. Section 9.2.1: There are two paragraphs on the 403 return code. Section 9.3: > During MKCOL processing, a server MUST > make the Request-URI a member of its parent collection Should be: 'internal member URI' instead of 'member'. > The precise > behavior of a MKCOL request when the body is present is undefined, > but limited to creating collections, members of a collection, bodies > of members and properties on the collections or members. Not sure if 'members' or 'internal members' are intended to be addressed here. Section 9.6. > MUST destroy locks rooted on the deleted resource A look root is an URI, not a resource. Section 9.6.1: > If an error occurs deleting an internal resource ... Use the defined term 'member resource' instead of 'internal resource'. Section 9.7.1: > appropriately scoped parent What does 'appropiately scoped ' mean here. Since there is the defined term 'namespace consistency', it should be used here. section 9.9.3: > If a resource exists at the destination and the Overwrite header is > "T" then prior to performing the move the server MUST perform a > DELETE with "Depth: infinity" on the destination resource. If the > Overwrite header is set to "F" then the operation will fail. > Though it is defined later, mentioning the default here might be clearer. Section 9.10: > Any resource which supports the LOCK method MUST, at minimum, support > the XML request and response formats defined herein. > Seems pretty obvious. Better drop it. Section 9.10.1 > The resource identified in > the Request-URI becomes the root of the lock. No, the Request-URI itself becomes the lock root. Section 9.10.3: > If the Depth header is set to infinity then the resource specified in > the Request-URI along with all its internal members, all the way down > the hierarchy, are to be locked. Better use 'members' instead of 'internal members' here. Section 9.10.4: > Later on, the lock > may go away but the empty resource remains. Empty resources MUST > then appear in PROPFIND responses including that URL in the response > scope. A server MUST respond successfully to a GET request to an > empty resource, either by using a 204 No Content response, or by > using 200 OK with a Content-Length header indicating zero length IMHO, this is at best misleading, since the reader might think that there is something special about empty resources. Drop it. Section 10.1: Maybe this is the right place to finally come up with a definition of the widely used term 'DAV-compliant'. > All DAV > compliant resources MUST return the DAV header with compliance-class > "1" on all OPTIONS responses. shouldn't it be: 'compliance-class "1" at least'? Section 10.2: > to the > resource and its immediate children, ("Depth: 1"), or the resource > and all its progeny ("Depth: infinity") should be: 'to the resource and its internal members ("Depth: 1"), or the resource and all its members ("Depth: infinity")'. > The Depth header only specifies the behavior of the method with > regards to internal children. If a resource does not have internal > children then the Depth header MUST be ignored. > replace 'internal children' with 'internal members'. Section 10.3 > If the source server cannot > attempt a copy to the remote server, it MUST fail the request. Yes. What else should the server do? :) Section 10.4.1: > On the other hand, the request can succeed only > if one of the described state lists succeeds. This should probably be: ' ...can succeed if only one...' Section 13.2: The header should be ' Handling redirected member resources'. Section 15: Live properties are lockable by default. The only live properties defined in this spec that are not lockable are 'lockdiscovery' and 'supportedlock'. Since even a locked live property may change its value, locking a live property can only mean that it becomes protected against PROPPATCH. Since 'lockdiscovery' and 'supportedlock' are protected properties anyway, it does not make much sense to define them not lockable. Section 16: The term 'error code' should be replaced by 'status code' throughout this section. The list of postconditions and preconditions is not very readable due to missing document structure. Furthermore, i do not really understand why a certain pre- or postcondition should be bound to a certain status code. Section 20.7: > This risk only applies to host address based UUID versions. Section > 4 of [RFC4122] describes several other mechanisms for generating > UUIDs that do involve the host address and therefore do not suffer > from this risk. > should be: '... UUIDs that do not involve the host address...' Section A.2: > The philosophy of "Be flexible in > what you accept and strict in what you send" still applies, but it > must not be applied inappropriately. I am not sure whether it's wise to announce this philosophy and give good examples for it being a bad philosophy in the same paragraph. IMHO, it _is_ a bad philosophy. Regards, Manfred P.S: Since I never ever posted on the WebDav mailing list, I probably should introduce myself a little bit: Being a coworker of Julian and Stefan, I have been implementing backend components for SAP Netweaver during the last years, in particular components related to content management and versioning. From w3c-dist-auth-request@listhub.w3.org Tue Mar 14 13:32:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEKA-0008Lt-5G for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 13:32:50 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJEK9-0001ac-QP for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 13:32:50 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJEJA-0007oF-NL for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Mar 2006 18:31:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FJEIz-0007mb-Cm; Tue, 14 Mar 2006 18:31:37 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FJEIr-0003zL-9C; Tue, 14 Mar 2006 18:31:36 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Mar 2006 10:31:16 -0800 From: "John Barone" To: "'Julian Reschke'" Cc: "'Geoffrey M Clemm'" , "'Kevin Wiggen'" , , Date: Tue, 14 Mar 2006 10:31:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZG1mDxcuOesIpgRJCZGGvZvUIGQwAvM3Tg In-Reply-To: <4415CB0D.8000104@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 14 Mar 2006 18:31:16.0154 (UTC) FILETIME=[7ABCF1A0:01C64795] Received-SPF: none (aji.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=0.4 X-W3C-Scan-Sig: aji.w3.org 1FJEIr-0003zL-9C 9495532ef63f8fcffa43399a78bf7d07 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS00411XzDScGK00000d36@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12205 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Mar 2006 18:31:48 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 > Again, what's wrong with REBIND? You can implement REBIND without implementing > anything else in the BIND spec. For that matter, you'd probably want to implement > UNBIND as well (as DELETE shares the non-atomic properties with MOVE). I don't understand what's proposed here. Are you proposing that we leave the 2518-bis spec. silent on this matter, and simply implement pieces of the binding spec. to provide this capability? If so, that doesn't make any sense to me, since what we're really talking about is a different spec. with different requirements. The way I see it, that has no bearing on this spec. or this discussion. If instead you're proposing that we add a method REBIND to this spec., with an appropriate definition; my concern is that REBIND has a specific meaning that's fleshed out by the context provided in the binding spec., but that meaning doesn't translate to the 2518-bis spec., where we're talking about MOVEs, COPYs, and DELETEs, not BINDs, UNBINDs, and REBINDs. -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, March 13, 2006 11:42 AM To: John Barone Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org; w3c-dist-auth-request@w3.org Subject: Re: Comments on the "new" 2518 John Barone wrote: > Perhaps I'm beating a dead horse on this point, but I'll throw in one > final $.02, before I let it go... > >> Require it to be atomically, and those implementations that can't do >> it will either ignore the requirement, or stop supporting MOVE. I >> don't think this is what anybody wants. > > We're not proposing *requiring* the all or nothing behavior, and never have. > We're just trying to make the point that in a spec., one would think > that SHOULD language leans in the direction of the desired behavior. > In other words, you're recommending what the behavior should be. In > the case of moving a collection, Xythos doesn't agree that the > behavior SHOULD be "best-effort", but rather "all-or" nothing. If the > consensus is that "best-effort" is indeed the desired behavior, then > fine, we're in the minority. No, I think that's a misunderstanding about what "SHOULD" (as defined in RFC2119) means. When the spec says "SHOULD", that indicates that clients can in general rely on that. If what you're after is text that tells server implementors that an atomic MOVE in general is more useful than a best-effort move, I do agree that this wouldn't hurt. However may impression is that a server implementor who *can* do it atomically will do it anyway, so I'm not sure whether it really helps. > If however, the SHOULD language is there because (as you put it > Julian, and I think Geoff alluded to) "The RFC2518 language IMHO > accurately reflects the fact that an implementation of MOVE varies a > lot based on the underlying technology, and that there simply *are* > cases where it can't be done atomically." (i.e. a lot of servers > *can't* implement it that way, for whatever reason), then perhaps we > should look more closely at why the language is the way it is. Do we > sacrifice desired behavior for feasibility in implementation? You > could also argue the point that strictly from a compliance perspective > "SHOULD be all-or-nothing" wouldn't change the compliance of existing > servers; although it would certainly change the "intended" behavior. > > > ... like I said, my final $.02 on that particular point, and now I'll > let it go. However, I would like to continue pursuing adding the > ability for a client to request an all-or-nothing MOVE operation. It > would be nice to add a METHOD: > > MOVE-ALL (or MOVE-ATOMIC, or MOVE-COMPLETE) > > ... which MAY be implemented by a server, and if implemented MUST > result in an all-or-nothing MOVE. Again, what's wrong with REBIND? You can implement REBIND without implementing anything else in the BIND spec. For that matter, you'd probably want to implement UNBIND as well (as DELETE shares the non-atomic properties with MOVE). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Tue Mar 14 14:10:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEuU-00085R-Uk for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 14:10:22 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJEuT-0002Xq-M6 for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 14:10:22 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJEu4-00019J-Ld for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Mar 2006 19:09:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJEtw-000163-4s for w3c-dist-auth@listhub.w3.org; Tue, 14 Mar 2006 19:09:48 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FJEtm-0001y8-MB for w3c-dist-auth@w3.org; Tue, 14 Mar 2006 19:09:47 +0000 Received: (qmail invoked by alias); 14 Mar 2006 18:42:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 14 Mar 2006 19:42:57 +0100 X-Authenticated: #1915285 Message-ID: <44170E5E.5080904@gmx.de> Date: Tue, 14 Mar 2006 19:41:34 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Geoffrey M Clemm' , 'Kevin Wiggen' , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJEtm-0001y8-MB ffcdc79a789896f089417d3e4e268c5e X-Original-To: w3c-dist-auth@w3.org Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/44170E5E.5080904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12206 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Mar 2006 19:09:56 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 John Barone wrote: >> Again, what's wrong with REBIND? You can implement REBIND without > implementing >> anything else in the BIND spec. For that matter, you'd probably want to > implement >> UNBIND as well (as DELETE shares the non-atomic properties with MOVE). > > I don't understand what's proposed here. > > Are you proposing that we leave the 2518-bis spec. silent on this matter, > and simply implement pieces of the binding spec. to provide this capability? Exactly. > If so, that doesn't make any sense to me, since what we're really talking > about is a different spec. with different requirements. The way I see it, > that has no bearing on this spec. or this discussion. Well, both specs are discussed here, and both are supposed to be submitted to the IESG at roughly the same time. > If instead you're proposing that we add a method REBIND to this spec., with > an appropriate definition; my concern is that REBIND has a specific meaning > that's fleshed out by the context provided in the binding spec., but that > meaning doesn't translate to the 2518-bis spec., where we're talking about > MOVEs, COPYs, and DELETEs, not BINDs, UNBINDs, and REBINDs. That seems to be a very theoretical argument, unless you can show exactly how REBIND isn't what you need... Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Tue Mar 14 14:11:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEvq-0000u8-M7 for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 14:11:46 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJEvq-0002av-AF for webdav-archive@lists.ietf.org; Tue, 14 Mar 2006 14:11:46 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJEvc-0001mO-29 for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Mar 2006 19:11:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJEvY-0001lk-SK; Tue, 14 Mar 2006 19:11:28 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.50) id 1FJEvO-0003l2-1a; Tue, 14 Mar 2006 19:11:28 +0000 Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id E44561EB39; Tue, 14 Mar 2006 20:11:14 +0100 (CET) Message-ID: <44171568.80203@greenbytes.de> Date: Tue, 14 Mar 2006 20:11:36 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Julian Reschke' , 'Geoffrey M Clemm' , 'Kevin Wiggen' , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: lisa.w3.org 1FJEvO-0003l2-1a 6957091ac34e11935ce69a0289b9011e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/44171568.80203@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12207 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 14 Mar 2006 19:11:32 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac John,

as far as I can see, you are proposing to extend WebDAV by a method that has the semantics of an atomic MOVE. Since the BIND spec is a WebDAV extension and the REBIND method has exactly the desired semantics, I do not see your point. Why is it important if your extension is defined by the same spec?

Regards,
Manfred

John Barone wrote: 
Again, what's wrong with REBIND? You can implement REBIND without
    
implementing 
  
anything else in the BIND spec. For that matter, you'd probably want to
    
implement 
  
UNBIND as well (as DELETE shares the non-atomic properties with MOVE).
    

I don't understand what's proposed here.

Are you proposing that we leave the 2518-bis spec. silent on this matter,
and simply implement pieces of the binding spec. to provide this capability?
If so, that doesn't make any sense to me, since what we're really talking
about is a different spec. with different requirements.  The way I see it,
that has no bearing on this spec. or this discussion.

If instead you're proposing that we add a method REBIND to this spec., with
an appropriate definition; my concern is that REBIND has a specific meaning
that's fleshed out by the context provided in the binding spec., but that
meaning doesn't translate to the 2518-bis spec., where we're talking about
MOVEs, COPYs, and DELETEs, not BINDs, UNBINDs, and REBINDs.  


-John 



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, March 13, 2006 11:42 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
w3c-dist-auth-request@w3.org
Subject: Re: Comments on the "new" 2518

John Barone wrote:
  
Perhaps I'm beating a dead horse on this point, but I'll throw in one 
final $.02, before I let it go...

    
Require it to be atomically, and those implementations that can't do 
it will either ignore the requirement, or stop supporting MOVE. I 
don't think this is what anybody wants.
      
We're not proposing *requiring* the all or nothing behavior, and never
    
have.
  
We're just trying to make the point that in a spec., one would think 
that SHOULD language leans in the direction of the desired behavior.  
In other words, you're recommending what the behavior should be.  In 
the case of moving a collection, Xythos doesn't agree that the 
behavior SHOULD be "best-effort", but rather "all-or" nothing.  If the 
consensus is that "best-effort" is indeed the desired behavior, then 
fine, we're in the minority.
    

No, I think that's a misunderstanding about what "SHOULD" (as defined in
RFC2119) means. When the spec says "SHOULD", that indicates that clients can
in general rely on that.

If what you're after is text that tells server implementors that an atomic
MOVE in general is more useful than a best-effort move, I do agree that this
wouldn't hurt. However may impression is that a server implementor who *can*
do it atomically will do it anyway, so I'm not sure whether it really helps.

  
If however, the SHOULD language is there because (as you put it 
Julian, and I think Geoff alluded to) "The RFC2518 language IMHO 
accurately reflects the fact that an implementation of MOVE varies a 
lot based on the underlying technology, and that there simply *are* 
cases where it can't be done atomically." (i.e. a lot of servers 
*can't* implement it that way, for whatever reason), then perhaps we 
should look more closely at why the language is the way it is.  Do we 
sacrifice desired behavior for feasibility in implementation?  You 
could also argue the point that strictly from a compliance perspective 
"SHOULD be all-or-nothing" wouldn't change the compliance of existing 
servers; although it would certainly change the "intended" behavior.


... like I said, my final $.02 on that particular point, and now I'll 
let it go.  However, I would like to continue pursuing adding the 
ability for a client to request an all-or-nothing MOVE operation.  It 
would be nice to add a METHOD:

MOVE-ALL (or MOVE-ATOMIC, or MOVE-COMPLETE)

... which MAY be implemented by a server, and if implemented MUST 
result in an all-or-nothing MOVE.
    

Again, what's wrong with REBIND? You can implement REBIND without
implementing anything else in the BIND spec. For that matter, you'd probably
want to implement UNBIND as well (as DELETE shares the non-atomic properties
with MOVE).

Best regards, Julian

From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 04:31:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSLU-00013W-W6 for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 04:31:08 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSLT-0002M9-Nn for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 04:31:08 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJSJl-0008F0-2A for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 09:29:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJSJc-0008Dd-Qf for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 09:29:12 +0000 Received: from hoboe1bl1.telenet-ops.be ([195.130.137.72]) by maggie.w3.org with esmtp (Exim 4.50) id 1FJSJV-00086i-Ay for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 09:29:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by hoboe1bl1.telenet-ops.be (Postfix) with SMTP id BEFCFD41D1; Wed, 15 Mar 2006 10:29:02 +0100 (CET) Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75]) by hoboe1bl1.telenet-ops.be (Postfix) with ESMTP id 92926D4233; Wed, 15 Mar 2006 10:29:02 +0100 (CET) Message-ID: <4417DEAB.9070703@re.be> Date: Wed, 15 Mar 2006 10:30:19 +0100 From: =?ISO-8859-1?Q?Werner_Donn=E9?= Reply-To: werner.donne@re.be Organization: Re BVBA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: none (maggie.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJSJV-00086i-Ay 54058b02d0432fc73d411611c17d76e1 X-Original-To: w3c-dist-auth@w3.org Subject: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/4417DEAB.9070703@re.be Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12208 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 09:29:21 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, The UPDATE method can be used to set the checked-in version of a version controlled resource to a version which has descendants. At that point a check-out may fork, resulting in the checked-in version to have more than one descendant. This way a tree can be built. If one wants to grow the different branches of such a tree, the UPDATE method should be used to set the checked-in version of the version controlled resource appropriately. This, however, changes global state, which could lead to races. The complete operation the client would do is the following sequence: - Retrieve the current checked-in version of the version controlled resou= rce. - Set it to the most recent version in a "branch". - Perform a check-out or anything else that can be done on a version controlled resource. - Set the checked-in version back to what it was. For this to work in a multi-user environment, either the sequence should be executed atomically and in isolation, or methods such as check-out should be allowed to operate on versions as well. Regards, Werner. --=20 Werner Donn=E9 -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 07:50:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJVSA-0007iV-Cg for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 07:50:14 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJVS9-00082i-WA for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 07:50:14 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJVRD-0006ln-Mb for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 12:49:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJVR4-0006kd-GI for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 12:49:06 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJVQw-0007Xs-SK for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 12:49:06 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2FCmsIf000329 for ; Wed, 15 Mar 2006 07:48:54 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2FCmsoH090336 for ; Wed, 15 Mar 2006 07:48:54 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2FCmsqL028147 for ; Wed, 15 Mar 2006 07:48:54 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2FCmsxe028129; Wed, 15 Mar 2006 07:48:54 -0500 In-Reply-To: <4417DEAB.9070703@re.be> To: werner.donne@re.be Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 15 Mar 2006 07:48:52 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/15/2006 07:48:53, Serialize complete at 03/15/2006 07:48:53 Content-Type: multipart/alternative; boundary="=_alternative 0046637C85257132_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1FJVQw-0007Xs-SK 758291324886a3fa3bb88bb3d794051b X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/OF52FDD997.15C2E5E7-ON85257132.00440DAE-85257132.00466415@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12209 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 12:49:15 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede This is a multipart message in MIME format. --=_alternative 0046637C85257132_= Content-Type: text/plain; charset="US-ASCII" I believe you are confusing the "checkout-in-place" feature and the "working-resource" feature. In the "checkout-in-place" feature, you make your changes directly on the VCR. If two clients want to be working in parallel, they would have separate workspaces, and each client would have its own VCR, so the VCR is not shared global state, but rather is private state for the client that owns that workspace. In the "working-resource" feature, you do apply the CHECKOUT directly to a version (see section 9.3), so again, there is no mutable global state for which there would be contention. The only time in which there is shared mutable state is when two clients are sharing the same workspace. In this case, the primary problem you face is the standard "lost update" problem while you are authoring the content, and the solution is the standard WebDAV solution: use the LOCK method. Cheers, Geoff Werner wrote on 03/15/2006 04:30:19 AM: > > The UPDATE method can be used to set the checked-in version of a > version controlled resource to a version which has descendants. > At that point a check-out may fork, resulting in the checked-in > version to have more than one descendant. > > This way a tree can be built. If one wants to grow the different > branches of such a tree, the UPDATE method should be used to set > the checked-in version of the version controlled resource > appropriately. This, however, changes global state, which could > lead to races. > > The complete operation the client would do is the following sequence: > - Retrieve the current checked-in version of the version controlled resource. > - Set it to the most recent version in a "branch". > - Perform a check-out or anything else that can be done on a version > controlled resource. > - Set the checked-in version back to what it was. > > For this to work in a multi-user environment, either the sequence > should be executed atomically and in isolation, or methods such as > check-out should be allowed to operate on versions as well. --=_alternative 0046637C85257132_= Content-Type: text/html; charset="US-ASCII"
I believe you are confusing the "checkout-in-place" feature and
the "working-resource" feature.  

In the "checkout-in-place" feature, you make your changes
directly on the VCR.  If two clients want to be working
in parallel, they would have separate workspaces, and each
client would have its own VCR, so the VCR is not shared global
state, but rather is private state for the client that owns
that workspace.

In the "working-resource" feature, you do apply the
CHECKOUT directly to a version (see section 9.3), so again,
there is no mutable global state for which there would
be contention.

The only time in which there is shared mutable state is when
two clients are sharing the same workspace.  In this case,
the primary problem you face is the standard "lost update" problem
while you are authoring the content, and the solution is the
standard WebDAV solution: use the LOCK method.

Cheers,
Geoff

Werner wrote on 03/15/2006 04:30:19 AM:
>
> The UPDATE method can be used to set the checked-in version of a
> version controlled resource to a version which has descendants.
> At that point a check-out may fork, resulting in the checked-in
> version to have more than one descendant.
>
> This way a tree can be built. If one wants to grow the different
> branches of such a tree, the UPDATE method should be used to set
> the checked-in version of the version controlled resource
> appropriately. This, however, changes global state, which could
> lead to races.
>
> The complete operation the client would do is the following sequence:
> - Retrieve the current checked-in version of the version controlled resource.
> - Set it to the most recent version in a "branch".
> - Perform a check-out or anything else that can be done on a version
>   controlled resource.
> - Set the checked-in version back to what it was.
>
> For this to work in a multi-user environment, either the sequence
> should be executed atomically and in isolation, or methods such as
> check-out should be allowed to operate on versions as well.
 --=_alternative 0046637C85257132_=-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 08:31:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJW5w-0002c0-NH for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 08:31:20 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJW5s-00013M-AA for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 08:31:18 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJW5O-0001PU-FM for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 13:30:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJW5G-0001OJ-8q for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 13:30:38 +0000 Received: from adicia.telenet-ops.be ([195.130.132.56]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJW58-0000D9-O9 for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 13:30:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 85ADB7014F; Wed, 15 Mar 2006 14:30:29 +0100 (CET) Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75]) by adicia.telenet-ops.be (Postfix) with ESMTP id E9C9F7005C; Wed, 15 Mar 2006 14:30:28 +0100 (CET) Message-ID: <44181742.6080601@re.be> Date: Wed, 15 Mar 2006 14:31:46 +0100 From: =?ISO-8859-1?Q?Werner_Donn=E9?= Reply-To: werner.donne@re.be Organization: Re BVBA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: none (lisa.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJW58-0000D9-O9 ebb7a0e3bd9d6138a9d4c3b003c1f259 X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/44181742.6080601@re.be Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12210 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 13:30:46 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Geoff, I'm not referring to working resources and I know that normally workspaces should be used to work in parallel. However, the workspaces feature is optional and the checkout-in-place feature doesn't depend on it. The checkout-in-place feature provides forking and therefore the model should be consistent in the absence of the workspaces feature. According to me forking and workspaces are unrelated. The forking functionality stands on its own. When a fork is allowed for some version, it may have more than one successor. The only way to address a particular successor, for a check-out operation for example, is by setting the checked-in version of the VCR to it. This is a global state change. Regards, Werner. Geoffrey M Clemm wrote: >=20 > I believe you are confusing the "checkout-in-place" feature and > the "working-resource" feature. =20 >=20 > In the "checkout-in-place" feature, you make your changes > directly on the VCR. If two clients want to be working > in parallel, they would have separate workspaces, and each > client would have its own VCR, so the VCR is not shared global > state, but rather is private state for the client that owns > that workspace. >=20 > In the "working-resource" feature, you do apply the > CHECKOUT directly to a version (see section 9.3), so again, > there is no mutable global state for which there would > be contention. >=20 > The only time in which there is shared mutable state is when > two clients are sharing the same workspace. In this case, > the primary problem you face is the standard "lost update" problem > while you are authoring the content, and the solution is the > standard WebDAV solution: use the LOCK method. >=20 > Cheers, > Geoff >=20 > Werner wrote on 03/15/2006 04:30:19 AM: >> >> The UPDATE method can be used to set the checked-in version of a >> version controlled resource to a version which has descendants. >> At that point a check-out may fork, resulting in the checked-in >> version to have more than one descendant. >> >> This way a tree can be built. If one wants to grow the different >> branches of such a tree, the UPDATE method should be used to set >> the checked-in version of the version controlled resource >> appropriately. This, however, changes global state, which could >> lead to races. >> >> The complete operation the client would do is the following sequence: >> - Retrieve the current checked-in version of the version controlled > resource. >> - Set it to the most recent version in a "branch". >> - Perform a check-out or anything else that can be done on a version >> controlled resource. >> - Set the checked-in version back to what it was. >> >> For this to work in a multi-user environment, either the sequence >> should be executed atomically and in isolation, or methods such as >> check-out should be allowed to operate on versions as well. --=20 Werner Donn=E9 -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 09:48:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXIE-0007bg-9l for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 09:48:06 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXID-0003JI-3A for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 09:48:06 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJXGI-0007uU-4u for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 14:46:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJXG8-0007o4-Dq for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 14:45:57 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1FJXFz-0005YE-PM for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 14:45:55 +0000 Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 1B79B2EA0D for ; Wed, 15 Mar 2006 15:45:47 +0100 (CET) Message-ID: <4418289B.2000805@greenbytes.de> Date: Wed, 15 Mar 2006 15:45:47 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJXFz-0005YE-PM 282213ae2e7a258dffad39f350e74931 X-Original-To: w3c-dist-auth@w3.org Subject: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/4418289B.2000805@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12211 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 14:46:06 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, from Section 9.8.2 of rfc2518-bis-14: > After a successful COPY invocation, all dead properties on the source > resource MUST be duplicated on the destination resource, along with > all properties as appropriate and from Section 9.9.1 of rfc2518-bis-14: > Dead properties MUST be moved along with the resource Apart from my opinion that 'along with all properties as appropriate' has neither normative nor explanatory character and should be omitted, this changes the COPY/MOVE semantics of RFC2518 in a way that is rather inconsistent with the fact that not even a resource which supports PROPPATCH is required to set dead properties. Furthermore, such a change would force existing implementations that support DAV namespace operations but not DAV property operations to break the specification. Regards, Manfred From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 10:41:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJY7y-0003Ek-2Q for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 10:41:34 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJY7x-0005OU-Qq for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 10:41:34 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJY6a-0005S8-Fl for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 15:40:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJY6S-0004zq-2G for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 15:40:00 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1FJY6J-0001By-EH for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 15:39:59 +0000 Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id A861349078 for ; Wed, 15 Mar 2006 16:39:50 +0100 (CET) Message-ID: <44183547.2070100@greenbytes.de> Date: Wed, 15 Mar 2006 16:39:51 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJY6J-0001By-EH daf95d42d01a566bd204a04083136e5f X-Original-To: w3c-dist-auth@w3.org Subject: rfc2518bis-14: the term 'DAV-compliance' X-Archived-At: http://www.w3.org/mid/44183547.2070100@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12212 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 15:40:08 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, the more I think about it, the more headaches I get from the term 'DAV-compliance' as it is used in RFC2518bis. First of all, it is never defined in the specification, though it appears to be a widely used technical term. Since it is not defined explicitly, one has to extract its meaning from the usage in the text. A DAV-compliant resource has to support all methods defined in the spec with the exception of LOCK and UNLOCK. Consequently, if an implementation decides to support a proper subset of the set of these methods, it will be not DAV-compliant. But of course, one wants such an implementation to fulfil general requirements on DAV resources, for example those defined in section 5.2 on collection resources. But section 5.2 in turn applies explicitly to DAV-compliant resources, using wordings like 'For all WebDAV compliant resources A and B, identified by URLs "U" and "V" respectively...'. IMHO, the term 'DAV-compliance' should refer to implemetations that are aware of the specification and fulfil some general requirenments. It does not make sense to require a DAV-compliant resource to support any given set of methods (there are still the compliance classes to express different levels of support). Consequently, i would drop all the requirements matching the 'All DAV-compliant resources MUST support the XYZ method' pattern from the method definitions in section 9 and define a DAV-compliant resource to be a resource fulfilling the MUST requirements in the spec. Regards, Manfred From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 10:43:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJY9W-0003d3-Sh for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 10:43:10 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJY9U-0005Pp-TF for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 10:43:10 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJY8M-0005et-Fi for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 15:41:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJY8I-0005eD-T6 for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 15:41:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FJY7w-0001ZM-Ry for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 15:41:54 +0000 Received: (qmail invoked by alias); 15 Mar 2006 15:34:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 15 Mar 2006 16:34:51 +0100 X-Authenticated: #1915285 Message-ID: <441833CA.60609@gmx.de> Date: Wed, 15 Mar 2006 16:33:30 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJY7w-0001ZM-Ry dbcf0b07b27c5c34d957c3af960a3626 X-Original-To: w3c-dist-auth@w3.org Subject: rfc2518bis-14 WGLC comments (part 1) X-Archived-At: http://www.w3.org/mid/441833CA.60609@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12213 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 15:41:58 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: b67ab81b2db0d00304056d0360a5a39a Below is a summary of problems I found with draft 14. Note that I've marked up everything in , which may be more readable. Also note that this document contains more changes based on issues that have been discussed before on this list; the fact that I may not be repeating them below doesn't indicate that they shouldn't be fixed before IESG submission as well. Also note that the term "Section" should be uppercased everywhere when used to refer to a specific section; otherwise the RFC Editor will have to do that; and we want to save his/her time, right? [Page 8] Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages. -> what is the last sentence about? Namespace Operations: The ability to instruct the server to copy and move Web resources, operations which change the URL. -> Sentence structure? This standard does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253]. -> This document isn't a standard. Just say "this document". The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general and write locks (Section 7) specifically. These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the new HTTP headers (Section 10) used with WebDAV methods. -> No mention of Section 8? [Page 11] Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements in Section 5. -> "...defined in Section 5". [Page 18] An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. -> "...internal member URL". The root, or top-level collection of the namespace under consideration is exempt from the previous rule. The top-level -> ^^^^^^^^^^^^^, (insert comma) Although implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs. -> Why "Although"? I think this needs to be rephrased. For all WebDAV compliant resources A and B, identified by URLs "U" and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain at least one mapping from "blah" to B. -> Insert paragraph suggested by Geoff Clemm below: 'Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e. either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent, A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.' [Page 19] A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link", thus the URL "/col/link" would indeed be mapped. Similarly, a dynamically- generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/". -> Please re-insert subsection title in front of this para so that it's easier to see where normative text ends and examples start. [Page 21] This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here. -> "...LOCK and UNLOCK method handling..." [Page 22] However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can use the lock. -> Avoid a potential misunderstanding: each principal will need its own shared lock, they will *not* share the same lock. For instance. "However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case, allowing multiple principals to receive a lock." [Page 23] The creator of a lock has special privileges to use the locked resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission). For multi- user shared lock cases, each authenticated principal MUST obtain its own shared lock. -> Misleading. Lock creator checks only apply (as a MUST level requirement) to lock token submission in the If header; removing the lock using UNLOCK is a separate thing. Furthermore, making a special statement about shared locks IMHO is confusing here. [Page 24] Servers MAY make lock tokens publicly readable (e.g. in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock tokens created by another client instance. -> s/tokens/token/ [Page 25] A client MUST NOT assume that just because the time-out has expired the lock has immediately been cleaned up. -> s/cleaned up/removed/ [Page 27] An exclusive write lock will prevent parallel changes to a resource by any principal other than the lock creator and in any case where the lock token is not submitted (e.g. by a client process other than the one holding the lock). -> remove "parallel"; it may lead people to believe that this has something to do with timing -> furthermore, this paragraph just states things repeated in aubsequent paragraphs, so it's best just to remove it While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked. -> The whole paragraph doesn't seem to make sense anymore, because it seems to say the same thing as the previous section, but uses different terminology. [Page 29] WebDAV provides the ability to lock an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost- update problem on the creation of a new resource (another way is to use If-None-Match header specified in HTTP 1.1). It has the side benefit of locking the new resource immediately for use of the creator. -> s/HTTP 1.1/Section 14.26 of [RFC2616]/ -> Regarding the remainder of Section 7.3, please see and . [Page 31] There are two kinds of collection write locks. A "Depth 0" write lock on a collection protects the collection metadata plus the internal member URLs of that collection, while not protecting the content or metadata of child resources. A "Depth: infinity" write lock on a collection provides the same protection on that collection and also protects every descendent resource as if that resource were itself write locked. -> Again repeats stuff from previous sections, but in this case fails to say that collection content is lockable as well (if present). Why not just refer to "collection state"???? Expressed otherwise, a write lock protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the binding name of a member URL. -> "binding name"? [Page 32] In order to prevent these collisions a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted in the if header, one for the source and the other for the destination. -> s/if/If/ [Page 34] 7.7. Refreshing Write Locks -> IMHO, the whole subsection is both unneeded (there simply isn't anything particular about refreshing *write* locks) and misleading. Please remove it. A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. -> Repeating a LOCK request with an existing lock token in the If header is going to fail for an exclusive lock anway. However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set. -> Just point to the paragraph in the LOCK definition here. At a minimum, fix above sentence to say "request" instead of "method". [Page 38] Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended. -> s/they// HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see section 14.18, [RFC2616]). -> Not true, for instance for 100 Continue. [Page 39] Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed. -> Language: "body or contents"? HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16 -> s/Section 16/Section 16./ [Page 41] A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for depth infinity requests MAY be disabled, due to the performance and security concerns associated with this behavior. Since clients weren't required to include the Depth header in [RFC2518], servers SHOULD treat such a request as if a "Depth: infinity" header was included. -> IMHO doesn't make sense. If servers SHOULD accept requests without depth header, there's no point in having a MUST-level requirement for clients to send it. Please keep changes compared to RFC2518 at a minimum. o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by server), -> That implies that ordering could be relevant somehow, which it isn't. [Page 42] If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a 'multistatus' XML element, with a 'response' XML element which contains a 404 (Not Found) status value. -> Is there a case where the response isn't a multistatus element??? Consequently, the 'multistatus' XML element for a collection resource with member URLs MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URLs are returned as a flat list whose order of entries is not significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses. -> In this paragraph, please remove "with member URLs" and "with internal member URLs". The semantics of PROPFIND is indepedant of whether the collection has members or not. 403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body. -> s/on collections// (it's irrelevant whether it's a collection or not) [Page 43] 9.1.2. Status codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. -> Replace by: 9.1.2. Status Codes for use in 'propstat' Element In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. (see ). [Page 45] 9.1.4. Example - Retrieving Named and Dead Properties -> Remove whole subsection and replace with correct one (see ): 9.1.4 Example - Retrieving (almost) all properties plus selected live properties >>Request PROPFIND /mycol/changes HTTP/1.1 Host: www.example.com Depth: 0 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx In this example, PROPFIND is executed on the resource http://www.example.com/mycol/changes. The client requests the values of all properties defined in this specification, plus the two live properties DAV:checked-in and DAV:checked-out defined in [RFC3253]. [Page 49] The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The -> Strike the 2nd "on this resource". [Page 50] 9.2. PROPPATCH Method The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Clients SHOULD NOT alter the same property more than once in a single PROPPATCH request. -> Huh? Why not? -> Also I note that we never normatively define the response body for PROPPATCH, will make proposal in a separate mail. 9.2.1. Status Codes for use in 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. -> Replace by (see : 9.2.1. Status Codes for use in 'propstat' Element In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. 403 (Forbidden): The client has attempted to set a read-only property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body. -> Replace by: "403 (Forbidden) (with the condition code 'cannot-modify-protected-property' defined in Section 16) - The client has attempted to set a protected property, such as DAV:getetag." [Page 52] The MKCOL method is used to create a new collection. All WebDAV compliant resources MUST support the MKCOL method. -> Nit: So does an unmapped URI (the thing you address the MKCOL to) identify a WebDAV compliant resource? Otherwise this requirement isn't really helpful... [Page 53] 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. -> Language? I think it can indicate lots of other things. [Page 54] Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection. -> Nit: the fact that it's undefined in RF2616 really wouldn't stop us to define it, I think. A server processing a successful DELETE request: MUST destroy locks rooted on the deleted resource MUST remove the mapping from the Request-URI to any resource. -> Nit: list style? [Page 56] A PUT request is the only way a client has to indicate to the server what Content-Type a resource should have, and whether it should change if the resource is overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a reasonable and legal Content-Type. -> (1) So then why do we also say that DAV:getcontenttype will be writeable unless "prefers to assign content types on its own"? (2) Please rephrase or remove "reasonable and legal". "reasonable" doesn't have any place in normative text, and "legal" doesn't make sense either. [Page 58] After a successful COPY invocation, all dead properties on the source resource MUST be duplicated on the destination resource, along with all properties as appropriate. Live properties described in this -> MUST seems to be too strong, as the ability to PROPPATCH dead properties is only a SHOULD-level requirement. A COPY operation creates a new resource, much like a PUT operation does. Live properties which are related to resource creation (such as DAV:creationdate) should have their values set accordingly. -> "A COPY operation applied to an unmapped URL creates a new resource..." [Page 62] >>Response HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/R2/ HTTP/1.1 423 Locked -> d:error missing in example The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step -> Replace "atomically" by "in a single operation" (to prevent confusion about the best-effort semantics). [Page 63] MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties which are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE. -> well, unless it needs to be modified. See Section 8.8. Dead properties MUST be moved along with the resource. -> Again, hard to defend because there's only a SHOULD level req to support them in PROPPATCH. [Page 65] 412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the state of the destination URL is already mapped to a resource. -> s/the state of// [Page 66] >>Response HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/C2/ HTTP/1.1 423 Locked -> d:error missing [Page 67] A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. Lock method requests -> No, the URL is the root. to create a new lock MUST have a XML request body. The server MUST preserve the information provided by the client in the 'owner' field in the request body when the lock information is requested. The LOCK -> "when the lock information is requested"??? 9.10.2. Refreshing Locks -> Issue: Lock refresh now is incompatible with RFC2518, causing required changes both in servers and clients for little gain; I don't think anybody wants to implement this. See . [Page 68] If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. -> No, it doesn't represent the resources. If represents the lock. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. -> The preceding sentence seems to be misplaced; probably it needs to be moved at the end of the paragraph. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked. A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length -> This repeats stuff from Section 7, but in an inconsistent way. According to this version, LNRs are not compliant; and it also applies to any kind of lock while Section 7 specifically talks about write locks. [Page 75] In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. -> Preceding sentence just duplicates text from above. From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 11:42:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZ4t-0008Co-2Q for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 11:42:27 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZ2e-0007CE-Iu for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 11:40:10 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJZ1q-0008C0-W1 for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 16:39:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJZ1g-00086X-UG for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 16:39:09 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1FJZ1V-0004oB-Du for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 16:39:08 +0000 Received: (qmail invoked by alias); 15 Mar 2006 16:38:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 15 Mar 2006 17:38:55 +0100 X-Authenticated: #1915285 Message-ID: <441842CB.6010205@gmx.de> Date: Wed, 15 Mar 2006 17:37:31 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: WebDAV References: <441833CA.60609@gmx.de> In-Reply-To: <441833CA.60609@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJZ1V-0004oB-Du 0354345a5584dea78584534690e8dc2b X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14 WGLC comments (part 2) X-Archived-At: http://www.w3.org/mid/441842CB.6010205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12214 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 16:39:18 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8 [Page 76] All DAV headers follow the same basic formatting rules as HTTP headers. This includes rules like line continuation and how to combine (or separate) multiple instances of the same header using commas. WebDAV adds two new conditional headers to the set defined in HTTP: the If and Overwrite headers. -> Insert paragraph break after "...commas." The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616])... -> Remove the last part, but add it to the BNF with a precise reference to the Section in RFC2616. A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification. -> Organization: I think it would be better if this section would just define the syntax, and delegate statements about syntax to Section 18. [Page 78] Please note, however, that it is always an error to submit a value for the Depth header that is not allowed by the method's definition. Thus submitting a "Depth: 1" on a COPY, even if the resource does not have internal members, will result in a 400 (Bad Request). The method should fail not because the resource doesn't have internal members, but because of the illegal value in the header. -> Seems that we shouldn't say "MUST be ignored" after all :-) If the Destination value is an absolute URI, it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g. specific error conditions). -> s/absolute URI/absolute-URI (Section 4.3 of [RFC3986])/ o The first purpose is to make a request conditional by supplying a series of state lists. If the state lists are tested and all fail, then the request MUST fail with a 412 (Precondition Failed) status. On the other hand, the request can succeed only if one of the described state lists succeeds. The success criteria for state lists are defined in Section 10.4.4 below. -> Replace by: "o The first purpose is to make a request conditional by supplying a series of state lists. If none of the state lists match the state of the resource it applies to, the request MUST fail with a 412 (Precondition Failed) status. Otherwise, the request may succeed. The matching functions for ETags and state tokens are defined in Section 10.4.4 below." o Additionally, the mere fact that a state token appears in an If header means that is has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The meaning of submitting a state token depends on its type (for lock tokens, please refer to Section 6). -> Replace by: "o Additionally, the mere fact that a state token appears in an If header means that it has been "submitted" with the request. In general, this is used to indicate that the client has knowledge of that state token. The semantics of the "submission" of a state token depends on its type (for lock tokens, please refer to Section 6)." [Page 80] 10.4.3. List Evaluation -> s/List Evaluation/Evaluation/ 10.4.4. Matching Tokens and ETags -> s/Matching Tokens and ETags/Matching State Tokens and ETags/ Matching unmapped URLs: for both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state. -> Replace by: "Note that for the purpose of matching entity tags and state tokens, the URL being unmapped should be treated the same way as if the resource existed, but did not have the specified state." [Page 81] ( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") ) -> Indentation missing, replace by: ( is-locked-with(urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2) AND matches-etag("I am an ETag") ) OR ( matches-etag("I am another ETag") ) [Page 83] The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE. A value of "F" states that the server must not perform the COPY or MOVE operation if the state of the destination URL does map -> s/state of the// [Page 84] If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this or any conditional header. -> s/or any conditional// (doesn't belong here) [Page 86] These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level request MUST NOT be used when the server has created a new resource in response to the request. -> s/request/response/ -> Don't we usually say "3xx class" instead of "300-level"? 12.2. 414 Request-URI Too Long This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations. -> So it's the same thing as in HTTP. Why is it then mentioned here??? [Page 87] 13. Multi-Status Response -> See comments and proposed text in . Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the -> Inconsistency: if servers MUST include the location element, why can't clients rely on it being present??? element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI. -> Language: clients MAY do whatever they want. This is nothing normative. [Page 89] In this section, the final line of each section gives the element type declaration using the format defined in [REC-XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). The "Extensibility" field discusses how the element may be extended in the future (or in existing extensions to WebDAV. -> Replace last sentence by "Note that all elements can be extended according to the rules defined in Section 17.". All of the elements defined here may be extended by the addition of attributes and child elements not defined in this specification. All elements defined here are in the "DAV:" namespace. -> Remove that sentence (already defined in Section 17). -> Indentation, make it: [Page 90] Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' element SHOULD include an XML element with the code of a failed precondition or postcondition. -> Language: "...the body is in XML..." -> s/code of a failed/name of a failed/ Description: Contains at least one XML element, and MUST NOT contain text or mixed content. Any element that is a child of the 'error' element is considered to be a precondition or postcondition code. Unrecognized elements SHOULD be ignored. -> As a matter of fact, they must be ignored. Purpose: Specifies an exclusive lock -> s/lock/lock./ [Page 91] Value: Simple-ref -> Link to definition in spec??? -> Inconsistent indentation (nees to be outdented) [Page 92] Purpose: The 'lockinfo' XML element is used with a LOCK method to specify the type of lock the client wishes to have created. -> Misleading: not necessarily with a LOCK method; can appear in PROPFIND as well, for instance. Description: The href contains a HTTP URL with the address of the root of the lock. The server SHOULD include this in all DAV: lockdiscovery property values and the response to LOCK requests. -> s/the address of// [Page 93] Purpose: Provides information about the creator of a lock. -> No, we have defined the lock creator to be something else. [Page 94] Description: This XML element is a container for the information required to modify the properties on the resource. This XML element is multi-valued. -> Language: I have no idea what "multivalued" means in this context. [Page 95] Description: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. The optional precondition/ postcondition error code and 'responsedescription' text also apply to the properties named in 'prop'. -> s/error// Description: The 'href' element contains a HTTP URL pointing to a WebDAV resource when used in the 'response' container. A particular 'href' value MUST NOT appear more than once as the child of a 'response' XML element under a 'multistatus' XML element. This requirement is necessary in order to keep processing costs for a response to linear time. Essentially, this prevents having to search in order to group together all the responses by 'href'. There are, however, no requirements regarding ordering based on 'href' values. The optional precondition/postcondition error code and 'responsedescription' text can provide additional information about this resource relative to the request or result. -> s/error// [Page 96] -> Indentation. Description: The 'set' XML element MUST contain only a prop XML element. The elements contained by the prop XML element inside -> s/prop/'prop'/ Purpose: Specifies a shared lock -> /lock/lock./ [Page 97] Purpose: Holds a single HTTP status-line -> s/status-line/status-line./ Value: status-line (status-line defined in Section 6.1 of [RFC2616]) -> s/status-line defined in/defined in/ [Page 98] COPY and MOVE behavior refers to local COPY and MOVE operations. -> as opposed to? For properties defined based on HTTP GET response headers (DAV:get*), the value could include LWS as defined in [RFC2616], section 4.2. Server implementors SHOULD NOT include extra LWS in these values, however client implementors MUST be prepared to handle extra LWS. -> My understanding was that LWS is not allowed, see . Also insert: "Note that all property elements can be extended according to the rules defined in Section 17." [Page 99] Description: The DAV:creationdate property SHOULD be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created. Servers that are incapable of persistently recording the creation date SHOULD instead leave it undefined (i.e. report "Not Found") -> trailing dot missing. Description: The DAV:displayname property should be defined on all DAV compliant resources. If present, the property contains a -> Why should it be defined? If the server doesn't have a displayname, it indeed should not be defined. [Page 101] Description: The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Refer to RFC2616 for a complete definition of the semantics of an ETag, and to Section 8.6 for a discussion of ETags in WebDAV. -> s/to RFC2616/to Section 3.11 of [RFC2616]/ [Page 102] COPY/MOVE behaviour: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Note that -> I honestly don't understand that statement. Description: Note that the last-modified date on a resource SHOULD only reflect changes in the body (the GET responses) of the resource. A change in a property only SHOULD NOT cause the last- modified date to change, because clients MAY rely on the last- modified date to know when to overwrite the existing body. The DAV:getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET. -> Language: starts with a note (IMHO unneeded), but then makes a normative statement. [Page 104] >>Response HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/container/ 0 Jane Smith Infinite urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 http://www.example.com/container/ HTTP/1.1 200 OK -> Fix indentation. Protected: SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), not by PROPPATCH. -> Language confusing: why "generally"? [Page 105] COPY/MOVE behaviour: Generally a COPY/MOVE of a resource results in the same type of resource at the destination. -> That's true for the collection type, but I doubt it's true in general (where types often depend on specific locations in the server namespace). COPY/MOVE behaviour: This property value is dependent on the kind of locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at the destination. -> That's generally true for any protected property, right? [Page 107] 16. Precondition/postcondition XML elements -> See comments in and . [Page 112] With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example Appendix A A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically- declared DTD. -> Missing ")." after "Appendix A". [Page 113] E.g. a server could have a sub-repository where an advanced feature like server was supported, even if that feature was not supported on all servers. -> "like server"? A resource that is class 2 compliant must also be class 1 compliant, and a resource that is class 3 compliant must also be class 1 compliant. -> "A resource that is class 2 or class 3 compliant must also be class 1 compliant." [Page 119] External XML entities have no inherent trustworthiness and are subject to all the attacks that are endemic to any HTTP GET request. Furthermore, it is possible for an external XML entity to modify the DTD, and hence affect the final form of an XML document, in the worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in [RFC3023]. Therefore, implementers must be aware that external XML entities should be treated as untrustworthy. If a server implementor chooses not to handle external XML entities, it SHOULD respond to requests containing external entities with the precondition defined above (no- external-entities). -> "...should respond ... with precondition..."? [Page 124] 22. Acknowledgements -> I think three sections of thanks is way too much, this probably should be collapsed into a single one. [Page 137] E.2. Changes for Server Implementors -> "Changes for Server Implementations" From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 12:31:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZqK-0007pA-Po for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 12:31:28 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZqG-0000Ob-D2 for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 12:31:26 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJZpf-0008N4-KU for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 17:30:47 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FJZpV-0008An-L6; Wed, 15 Mar 2006 17:30:38 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FJZpM-0004kI-6A; Wed, 15 Mar 2006 17:30:36 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Mar 2006 09:30:21 -0800 From: "John Barone" To: "'Julian Reschke'" Cc: "'Geoffrey M Clemm'" , "'Kevin Wiggen'" , , Date: Wed, 15 Mar 2006 09:30:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <44170E5E.5080904@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZHlx5DxjWuHBePTpqgZ+kQC68TawAvmcjA Message-ID: X-OriginalArrivalTime: 15 Mar 2006 17:30:21.0951 (UTC) FILETIME=[231390F0:01C64856] Received-SPF: none (aji.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: aji.w3.org 1FJZpM-0004kI-6A 9423b14aebce138dd85077f7d95d88be X-Original-To: w3c-dist-auth@w3.org Subject: RE: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/NSNOVPS00411uVZWGqj00000dde@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12215 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 17:30:47 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Well, I still don't see mixing and matching methods from various specs. as a coherent way of addressing the notion of atomicity (all-or-nothing behavior) in this spec. 2518-bis. But, that's neither here nor there; the bottom line is that Xythos seems to be the only ones who feel that this is a useful addition to the spec., so I'll let this drop as well. -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, March 14, 2006 10:42 AM To: John Barone Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org; w3c-dist-auth-request@w3.org Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518 John Barone wrote: >> Again, what's wrong with REBIND? You can implement REBIND without > implementing >> anything else in the BIND spec. For that matter, you'd probably want >> to > implement >> UNBIND as well (as DELETE shares the non-atomic properties with MOVE). > > I don't understand what's proposed here. > > Are you proposing that we leave the 2518-bis spec. silent on this > matter, and simply implement pieces of the binding spec. to provide this capability? Exactly. > If so, that doesn't make any sense to me, since what we're really > talking about is a different spec. with different requirements. The > way I see it, that has no bearing on this spec. or this discussion. Well, both specs are discussed here, and both are supposed to be submitted to the IESG at roughly the same time. > If instead you're proposing that we add a method REBIND to this spec., > with an appropriate definition; my concern is that REBIND has a > specific meaning that's fleshed out by the context provided in the > binding spec., but that meaning doesn't translate to the 2518-bis > spec., where we're talking about MOVEs, COPYs, and DELETEs, not BINDs, UNBINDs, and REBINDs. That seems to be a very theoretical argument, unless you can show exactly how REBIND isn't what you need... Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 12:57:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJaFa-0003J8-2q for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 12:57:34 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJaFZ-0001Np-OX for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 12:57:34 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJaEr-0007pS-Cr for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 17:56:49 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FJaEh-0007oo-Sw for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 17:56:40 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by aji.w3.org with esmtp (Exim 4.50) id 1FJaEa-0000ul-46 for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 17:56:39 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Mar 2006 09:56:30 -0800 From: "John Barone" To: "'Manfred Baedke'" , Date: Wed, 15 Mar 2006 09:56:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4418289B.2000805@greenbytes.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZIP3nJKPOOHYgDTviSxPCr3kfH6wAF3oFw Message-ID: X-OriginalArrivalTime: 15 Mar 2006 17:56:30.0694 (UTC) FILETIME=[CA1EC060:01C64859] Received-SPF: none (aji.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-1.6 X-W3C-Scan-Sig: aji.w3.org 1FJaEa-0000ul-46 9d55a8a5faa167cf0a67af848c086c4c X-Original-To: w3c-dist-auth@w3.org Subject: RE: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/NSNOVPS00411QIrGC5V00000de6@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12216 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 17:56:49 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 I don't know that this changes the semantics of COPY/MOVE. From the 2518 spec.: 8.8.1 COPY for HTTP/1.1 resources ... After a successful COPY invocation, all properties on the source resource MUST be duplicated on the destination resource, subject to modifying headers and XML elements, following the definition for copying properties... 8.8.2. COPY for Properties ... Live properties SHOULD be duplicated as identically behaving live properties at the destination resource. If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource subject to the effects of the propertybehavior XML element. The propertybehavior XML element can specify that properties are copied on best effort, that all live properties must be successfully copied or the method must fail, or that a specified list of live properties must be successfully copied or the method must fail. The propertybehavior XML element is defined in section 12.12. While the language is imprecise and a bit confusing, I read this as saying that properties MUST be copied over, with an exception for live properties, which SHOULD be copied if possible. There's some further discussion of transforming live props that can't be copied in to dead properties, and well as some caveats depending on how the propertybehavior XML element is specified. In the 2518 spec. the properties language in 8.8.1 probably should have been in 8.8.2, and instead of "all properties" it probably should have refered to "dead properties", but I don't think the new language fundamentally changes the semantics of COPY/MOVE. To my reading, the change is actually that the language about the propertybehavior XML element has been removed, and the MUST language for turning a LIVE property that can't be copied into a dead property has been changed to a SHOULD NOT ("Servers SHOULD NOT convert live properties into dead properties on the destination resource..."), which seems like a prudent change to me. 8.9.1 MOVE for Properties The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2. This is also a bit unclear, and probably should have pointed to 8.8.1 as well, but basically I see this as saying that a MOVE should behave in much the same way as COPY; dead properties MUST be moved, LIVE properties SHOULD be moved (which, I'd actually argue, that for a MOVE it should be a MUST). So, what is the change in semantics that you don't agree with, and what changes in language are you proposing to correct it? Regards, -John -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Manfred Baedke Sent: Wednesday, March 15, 2006 6:46 AM To: w3c-dist-auth@w3.org Subject: rfc2518bis-14: COPY/MOVE semantics Hi, from Section 9.8.2 of rfc2518-bis-14: > After a successful COPY invocation, all dead properties on the source > resource MUST be duplicated on the destination resource, along with > all properties as appropriate and from Section 9.9.1 of rfc2518-bis-14: > Dead properties MUST be moved along with the resource Apart from my opinion that 'along with all properties as appropriate' has neither normative nor explanatory character and should be omitted, this changes the COPY/MOVE semantics of RFC2518 in a way that is rather inconsistent with the fact that not even a resource which supports PROPPATCH is required to set dead properties. Furthermore, such a change would force existing implementations that support DAV namespace operations but not DAV property operations to break the specification. Regards, Manfred From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 13:13:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJaVC-0002Lz-4O for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:13:42 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJaVA-0002Fg-3v for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:13:42 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJaUj-0003nL-Eu for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 18:13:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJaUZ-0003l0-9I for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 18:13:03 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FJaUN-0006wu-Di for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 18:13:03 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Mar 2006 10:12:45 -0800 From: "John Barone" To: "'Julian Reschke'" , "'WebDAV'" Date: Wed, 15 Mar 2006 10:12:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <441833CA.60609@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZIRyxQWddj8EKpS1mNUvxodEsbHgAFDHKQ Message-ID: X-OriginalArrivalTime: 15 Mar 2006 18:12:45.0531 (UTC) FILETIME=[0F2B12B0:01C6485C] Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJaUN-0006wu-Di fd96bd541237bcd67b753fd531c0caf2 X-Original-To: w3c-dist-auth@w3.org Subject: RE: rfc2518bis-14 WGLC comments (part 1) X-Archived-At: http://www.w3.org/mid/NSNOVPS00411uTT7u3C00000de9@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12217 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 18:13:13 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7b1e34d2462e88c1c4311f8189331c59 >> After a successful COPY invocation, all dead properties on the source >> resource MUST be duplicated on the destination resource, along with >> all properties as appropriate. Live properties described in this >> -> MUST seems to be too strong, as the ability to PROPPATCH dead >> properties is only a SHOULD-level requirement. ... why is MUST too strong here (your PROPPATCH argument notwithstanding)? I don't see this as different than what the previous 2518 spec. stated, in section 8.8.1. > Dead properties MUST be moved along with the resource. > -> Again, hard to defend because there's only a SHOULD level req to > support them in PROPPATCH. ... also don't see this as different than what's stated in 2518 -John -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Wednesday, March 15, 2006 7:34 AM To: WebDAV Subject: rfc2518bis-14 WGLC comments (part 1) Below is a summary of problems I found with draft 14. Note that I've marked up everything in , which may be more readable. Also note that this document contains more changes based on issues that have been discussed before on this list; the fact that I may not be repeating them below doesn't indicate that they shouldn't be fixed before IESG submission as well. Also note that the term "Section" should be uppercased everywhere when used to refer to a specific section; otherwise the RFC Editor will have to do that; and we want to save his/her time, right? [Page 8] Properties: The ability to create, remove, and query information about Web pages, such as their authors, creation dates, etc. Also, the ability to link pages of any media type to related pages. -> what is the last sentence about? Namespace Operations: The ability to instruct the server to copy and move Web resources, operations which change the URL. -> Sentence structure? This standard does not specify the versioning operations suggested by [RFC2291]. That work was done in a separate document, "Versioning Extensions to WebDAV" [RFC3253]. -> This document isn't a standard. Just say "this document". The sections below provide a detailed introduction to various WebDAV abstractions: resource properties (Section 4), collections of resources (Section 5), locks (Section 6) in general and write locks (Section 7) specifically. These abstractions are manipulated by the WebDAV-specific HTTP methods (Section 9) and the new HTTP headers (Section 10) used with WebDAV methods. -> No mention of Section 8? [Page 11] Collection - Informally, a resource that also acts as a container of references to child resources. Formally, a resource that contains a set of mappings between path segments and resources and meets the requirements in Section 5. -> "...defined in Section 5". [Page 18] An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. -> "...internal member URL". The root, or top-level collection of the namespace under consideration is exempt from the previous rule. The top-level -> ^^^^^^^^^^^^^, (insert comma) Although implicit in [RFC2616] and [RFC3986], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs. -> Why "Although"? I think this needs to be rephrased. For all WebDAV compliant resources A and B, identified by URLs "U" and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST be a collection that contains a mapping from "SEGMENT" to B. So, if resource B with URL "http://example.com/bar/blah" is WebDAV compliant and if resource A with URL "http://example.com/bar/" is WebDAV compliant, then resource A must be a collection and must contain at least one mapping from "blah" to B. -> Insert paragraph suggested by Geoff Clemm below: 'Although commonly a mapping consists of a single segment and a resource, in general, a mapping consists of a set of segments and a resource. This allows a server to treat a set of segments as equivalent (i.e. either all of the segments are mapped to the same resource, or none of the segments are mapped to a resource). For example, a server that performs case-folding on segments will treat the segments "ab", "Ab", "aB", and "AB" as equivalent, A client can then use any of these segments to identify the resource. Note that a PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping.' [Page 19] A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects to non-WebDAV resources. For instance, "/col/link" might not appear as a member of "/col/", although the server would respond with a 302 status to a GET request to "/col/link", thus the URL "/col/link" would indeed be mapped. Similarly, a dynamically- generated page might have a URL mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/". -> Please re-insert subsection title in front of this para so that it's easier to see where normative text ends and examples start. [Page 21] This section provides a concise model for how locking behaves. Later sections will provide more detail on some of the concepts and refer back to these model statements. Normative statements related to LOCK and UNLOCK handling can be found in the sections on those methods, whereas normative statements that cover any method are gathered here. -> "...LOCK and UNLOCK method handling..." [Page 22] However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can use the lock. -> Avoid a potential misunderstanding: each principal will need its own shared lock, they will *not* share the same lock. For instance. "However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case, allowing multiple principals to receive a lock." [Page 23] The creator of a lock has special privileges to use the locked resource. When a locked resource is modified, a server MUST check that the authenticated principal matches the lock creator (in addition to checking for valid lock token submission). For multi- user shared lock cases, each authenticated principal MUST obtain its own shared lock. -> Misleading. Lock creator checks only apply (as a MUST level requirement) to lock token submission in the If header; removing the lock using UNLOCK is a separate thing. Furthermore, making a special statement about shared locks IMHO is confusing here. [Page 24] Servers MAY make lock tokens publicly readable (e.g. in the DAV: lockdiscovery property). One use case for making lock tokens readable is so that a long-lived lock can be removed by the resource owner (the client that obtained the lock might have crashed or disconnected before cleaning up the lock). Except for the case of using UNLOCK under user guidance, a client SHOULD NOT use a lock tokens created by another client instance. -> s/tokens/token/ [Page 25] A client MUST NOT assume that just because the time-out has expired the lock has immediately been cleaned up. -> s/cleaned up/removed/ [Page 27] An exclusive write lock will prevent parallel changes to a resource by any principal other than the lock creator and in any case where the lock token is not submitted (e.g. by a client process other than the one holding the lock). -> remove "parallel"; it may lead people to believe that this has something to do with timing -> furthermore, this paragraph just states things repeated in aubsequent paragraphs, so it's best just to remove it While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked. -> The whole paragraph doesn't seem to make sense anymore, because it seems to say the same thing as the previous section, but uses different terminology. [Page 29] WebDAV provides the ability to lock an unmapped URL in order to reserve the name for use. This is a simple way to avoid the lost- update problem on the creation of a new resource (another way is to use If-None-Match header specified in HTTP 1.1). It has the side benefit of locking the new resource immediately for use of the creator. -> s/HTTP 1.1/Section 14.26 of [RFC2616]/ -> Regarding the remainder of Section 7.3, please see and . [Page 31] There are two kinds of collection write locks. A "Depth 0" write lock on a collection protects the collection metadata plus the internal member URLs of that collection, while not protecting the content or metadata of child resources. A "Depth: infinity" write lock on a collection provides the same protection on that collection and also protects every descendent resource as if that resource were itself write locked. -> Again repeats stuff from previous sections, but in this case fails to say that collection content is lockable as well (if present). Why not just refer to "collection state"???? Expressed otherwise, a write lock protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the binding name of a member URL. -> "binding name"? [Page 32] In order to prevent these collisions a lock token MUST be submitted by an authorized principal for all locked resources that a method may change or the method MUST fail. A lock token is submitted when it appears in an If header. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted in the if header, one for the source and the other for the destination. -> s/if/If/ [Page 34] 7.7. Refreshing Write Locks -> IMHO, the whole subsection is both unneeded (there simply isn't anything particular about refreshing *write* locks) and misleading. Please remove it. A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. -> Repeating a LOCK request with an existing lock token in the If header is going to fail for an exclusive lock anway. However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set. -> Just point to the paragraph in the LOCK definition here. At a minimum, fix above sentence to say "request" instead of "method". [Page 38] Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended. -> s/they// HTTP defines many headers that can be used in WebDAV requests and responses. Not all of these are appropriate in all situations and some interactions may be undefined. Note that HTTP 1.1 requires the Date header in all responses if possible (see section 14.18, [RFC2616]). -> Not true, for instance for 100 Continue. [Page 39] Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed. -> Language: "body or contents"? HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253]). The error body mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This error body mechanism is covered in Section 16 -> s/Section 16/Section 16./ [Page 41] A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for depth infinity requests MAY be disabled, due to the performance and security concerns associated with this behavior. Since clients weren't required to include the Depth header in [RFC2518], servers SHOULD treat such a request as if a "Depth: infinity" header was included. -> IMHO doesn't make sense. If servers SHOULD accept requests without depth header, there's no point in having a MUST-level requirement for clients to send it. Please keep changes compared to RFC2518 at a minimum. o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by server), -> That implies that ordering could be relevant somehow, which it isn't. [Page 42] If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a 'multistatus' XML element, with a 'response' XML element which contains a 404 (Not Found) status value. -> Is there a case where the response isn't a multistatus element??? Consequently, the 'multistatus' XML element for a collection resource with member URLs MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource with internal member URLs are returned as a flat list whose order of entries is not significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses. -> In this paragraph, please remove "with member URLs" and "with internal member URLs". The semantics of PROPFIND is indepedant of whether the collection has members or not. 403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body. -> s/on collections// (it's irrelevant whether it's a collection or not) [Page 43] 9.1.2. Status codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. -> Replace by: 9.1.2. Status Codes for use in 'propstat' Element In PROPFIND responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. (see ). [Page 45] 9.1.4. Example - Retrieving Named and Dead Properties -> Remove whole subsection and replace with correct one (see ): 9.1.4 Example - Retrieving (almost) all properties plus selected live properties >>Request PROPFIND /mycol/changes HTTP/1.1 Host: www.example.com Depth: 0 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx In this example, PROPFIND is executed on the resource http://www.example.com/mycol/changes. The client requests the values of all properties defined in this specification, plus the two live properties DAV:checked-in and DAV:checked-out defined in [RFC3253]. [Page 49] The last four properties are WebDAV-specific, defined in Section 15. Since GET is not supported on this resource, the get* properties (e.g., DAV:getcontentlength) are not defined on this resource. The -> Strike the 2nd "on this resource". [Page 50] 9.2. PROPPATCH Method The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Clients SHOULD NOT alter the same property more than once in a single PROPPATCH request. -> Huh? Why not? -> Also I note that we never normatively define the response body for PROPPATCH, will make proposal in a separate mail. 9.2.1. Status Codes for use in 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. -> Replace by (see : 9.2.1. Status Codes for use in 'propstat' Element In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the most common status codes used inside 'propstat', however clients should be prepared to handle other 2/3/4/5xx series status codes as well. 403 (Forbidden): The client has attempted to set a read-only property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body. -> Replace by: "403 (Forbidden) (with the condition code 'cannot-modify-protected-property' defined in Section 16) - The client has attempted to set a protected property, such as DAV:getetag." [Page 52] The MKCOL method is used to create a new collection. All WebDAV compliant resources MUST support the MKCOL method. -> Nit: So does an unmapped URI (the thing you address the MKCOL to) identify a WebDAV compliant resource? Otherwise this requirement isn't really helpful... [Page 53] 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. -> Language? I think it can indicate lots of other things. [Page 54] Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection. -> Nit: the fact that it's undefined in RF2616 really wouldn't stop us to define it, I think. A server processing a successful DELETE request: MUST destroy locks rooted on the deleted resource MUST remove the mapping from the Request-URI to any resource. -> Nit: list style? [Page 56] A PUT request is the only way a client has to indicate to the server what Content-Type a resource should have, and whether it should change if the resource is overwritten. Thus, a client SHOULD provide a Content-Type for a new resource if any is known. If the client does not provide a Content-Type for a new resource, the server MAY create a resource with no Content-Type assigned, or it MAY attempt to assign a reasonable and legal Content-Type. -> (1) So then why do we also say that DAV:getcontenttype will be writeable unless "prefers to assign content types on its own"? (2) Please rephrase or remove "reasonable and legal". "reasonable" doesn't have any place in normative text, and "legal" doesn't make sense either. [Page 58] After a successful COPY invocation, all dead properties on the source resource MUST be duplicated on the destination resource, along with all properties as appropriate. Live properties described in this -> MUST seems to be too strong, as the ability to PROPPATCH dead properties is only a SHOULD-level requirement. A COPY operation creates a new resource, much like a PUT operation does. Live properties which are related to resource creation (such as DAV:creationdate) should have their values set accordingly. -> "A COPY operation applied to an unmapped URL creates a new resource..." [Page 62] >>Response HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/R2/ HTTP/1.1 423 Locked -> d:error missing in example The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. The consistency maintenance step -> Replace "atomically" by "in a single operation" (to prevent confusion about the best-effort semantics). [Page 63] MOVE is frequently used by clients to rename a file without changing its parent collection, so it's not appropriate to reset all live properties which are set at resource creation. For example, the DAV: creationdate property value SHOULD remain the same after a MOVE. -> well, unless it needs to be modified. See Section 8.8. Dead properties MUST be moved along with the resource. -> Again, hard to defend because there's only a SHOULD level req to support them in PROPPATCH. [Page 65] 412 (Precondition Failed) - A condition header failed. Specific to MOVE, this could mean that the Overwrite header is "F" and the state of the destination URL is already mapped to a resource. -> s/the state of// [Page 66] >>Response HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://www.example.com/othercontainer/C2/ HTTP/1.1 423 Locked -> d:error missing [Page 67] A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. Lock method requests -> No, the URL is the root. to create a new lock MUST have a XML request body. The server MUST preserve the information provided by the client in the 'owner' field in the request body when the lock information is requested. The LOCK -> "when the lock information is requested"??? 9.10.2. Refreshing Locks -> Issue: Lock refresh now is incompatible with RFC2518, causing required changes both in servers and clients for little gain; I don't think anybody wants to implement this. See . [Page 68] If the Depth header is set to infinity then the resource specified in the Request-URI along with all its internal members, all the way down the hierarchy, are to be locked. A successful result MUST return a single lock token which represents all the resources that have been locked. -> No, it doesn't represent the resources. If represents the lock. If an UNLOCK is successfully executed on this token, all associated resources are unlocked. -> The preceding sentence seems to be misplaced; probably it needs to be moved at the end of the paragraph. Hence, partial success is not an option. Either the entire hierarchy is locked or no resources are locked. A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock may go away but the empty resource remains. Empty resources MUST then appear in PROPFIND responses including that URL in the response scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length -> This repeats stuff from Section 7, but in an inconsistent way. According to this version, LNRs are not compliant; and it also applies to any kind of lock while Section 7 specifically talks about write locks. [Page 75] In this example, the lock identified by the lock token "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://example.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. -> Preceding sentence just duplicates text from above. From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 13:32:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJan4-0003pw-Ek for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:32:10 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJan3-0002aW-6w for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:32:10 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJamb-0000BM-JI for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 18:31:41 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FJamS-0000A4-Gv for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 18:31:32 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.org with smtp (Exim 4.50) id 1FJamK-0006uH-3x for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 18:31:31 +0000 Received: (qmail invoked by alias); 15 Mar 2006 18:31:19 -0000 Received: from p508FB868.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.184.104] by mail.gmx.net (mp019) with SMTP; 15 Mar 2006 19:31:19 +0100 X-Authenticated: #1915285 Message-ID: <44185D32.90408@gmx.de> Date: Wed, 15 Mar 2006 19:30:10 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: 'Manfred Baedke' , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1FJamK-0006uH-3x ac9badd47f09d91ed826cdf060ea72c1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/44185D32.90408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12218 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 18:31:41 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 John Barone wrote: > ... > So, what is the change in semantics that you don't agree with, and what > changes in language are you proposing to correct it? > ... I'm not objecting to a change in semantics. What I see is a discrepancy between both specs' requirements on dead property support (SHOULD), and support for copying dead properties (MUST). If resource /a supports dead properties, and /b doesn't, then a COPY request from /a to /b "MUST" fail, which IMHO isn't a useful requirement. A resource should still be able to act as a destination for COPY, even if it doesn't support dead properties. So the proposed change is to relax the requirement to SHOULD. Does this make things clearer? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 13:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJayW-0000jX-Ii for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:00 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJayW-0002ji-6y for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:00 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJay9-0002sA-Mu for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 18:43:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJay5-0002p6-5U for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 18:43:33 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.50) id 1FJaxx-0004QE-8c for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 18:43:33 +0000 Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id C7C452CE08; Wed, 15 Mar 2006 19:43:19 +0100 (CET) Message-ID: <44186047.6090302@greenbytes.de> Date: Wed, 15 Mar 2006 19:43:19 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: lisa.w3.org 1FJaxx-0004QE-8c bd5a5be623bd555685b4d49a3275a4d4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/44186047.6090302@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12219 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 18:43:37 +0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 John,

after reading these sections again, I have to admit that RFC2518 apparently intended to say that dead properties MUST be preserved by COPY/MOVE unless specified otherwise by the propertybehavior element. Therefore, I will have to change my mind from objecting against a semantical change to proposing a semantical change :)
My point is that the MUST requirement simply does not match the SHOULD requirement of PROPPATCH. It would be plainly impossible to COPY a resource with dead properties to a server that does not support dead properties (for example, a simple file system based implementation). I am proposing to relax the requirement to SHOULD level.

Regards,
Manfred

John Barone wrote: 
I don't know that this changes the semantics of COPY/MOVE.  From the 2518
spec.:

8.8.1 COPY for HTTP/1.1 resources

... After a successful COPY invocation, all properties on the
   source resource MUST be duplicated on the destination resource,
   subject to modifying headers and XML elements, following the
   definition for copying properties...

8.8.2. COPY for Properties

   ... Live properties SHOULD be duplicated as identically behaving live
   properties at the destination resource.  If a property cannot be
   copied live, then its value MUST be duplicated, octet-for-octet, in
   an identically named, dead property on the destination resource
   subject to the effects of the propertybehavior XML element.

   The propertybehavior XML element can specify that properties are
   copied on best effort, that all live properties must be successfully
   copied or the method must fail, or that a specified list of live
   properties must be successfully copied or the method must fail. The
   propertybehavior XML element is defined in section 12.12.


While the language is imprecise and a bit confusing, I read this as saying
that properties MUST be copied over, with an exception for live properties,
which SHOULD be copied if possible.  There's some further discussion of
transforming live props that can't be copied in to dead properties, and well
as some caveats depending on how the propertybehavior XML element is
specified.  

In the 2518 spec. the properties language in 8.8.1 probably should have been
in 8.8.2, and instead of "all properties" it probably should have refered to
"dead properties", but I don't think the new language fundamentally changes
the semantics of COPY/MOVE.   

To my reading, the change is actually that the language about the
propertybehavior XML element has been removed, and the MUST language for
turning a LIVE property that can't be copied into a dead property has been
changed to a SHOULD NOT ("Servers SHOULD NOT convert live properties into
dead properties on the destination resource..."), which seems like a prudent
change to me.



8.9.1 MOVE for Properties

   The behavior of properties on a MOVE, including the effects of the
   propertybehavior XML element, MUST be the same as specified in
   section 8.8.2.

This is also a bit unclear, and probably should have pointed to 8.8.1 as
well, but basically I see this as saying that a MOVE should behave in much
the same way as COPY; dead properties MUST be moved, LIVE properties SHOULD
be moved (which, I'd actually argue, that for a MOVE it should be a MUST).


So, what is the change in semantics that you don't agree with, and what
changes in language are you proposing to correct it?

Regards,

-John 


 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 6:46 AM
To: w3c-dist-auth@w3.org
Subject: rfc2518bis-14: COPY/MOVE semantics


Hi,

from Section 9.8.2 of rfc2518-bis-14:
  
After a successful COPY invocation, all dead properties on the source 
resource MUST be duplicated on the destination resource, along with 
all properties as appropriate
    
and from Section 9.9.1 of rfc2518-bis-14:
  
Dead properties MUST be moved along with the resource
    
Apart from my opinion that 'along with all properties as appropriate' 
has neither normative nor explanatory character and should be omitted, this
changes the COPY/MOVE semantics of RFC2518 in a way that is rather
inconsistent with the fact that not even a resource which supports PROPPATCH
is required to set dead properties. Furthermore, such a change would force
existing implementations that support DAV namespace operations but not DAV
property operations to break the specification.

Regards,
Manfred

From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 13:44:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJayl-0000oI-Mh for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:15 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJayj-0002jw-55 for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 13:44:15 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJayX-00034V-5h for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 18:44:01 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1FJayR-0002zf-FK for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 18:43:56 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by aji.w3.org with esmtp (Exim 4.50) id 1FJayI-0000hT-Ga for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 18:43:54 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2FIhfn7007254 for ; Wed, 15 Mar 2006 13:43:41 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2FIhfoH175314 for ; Wed, 15 Mar 2006 13:43:41 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2FIhfkp017414 for ; Wed, 15 Mar 2006 13:43:41 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2FIhf2A017408; Wed, 15 Mar 2006 13:43:41 -0500 In-Reply-To: <44181742.6080601@re.be> To: werner.donne@re.be Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 15 Mar 2006 13:43:39 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/15/2006 13:43:40, Serialize complete at 03/15/2006 13:43:40 Content-Type: multipart/alternative; boundary="=_alternative 0066DE8285257132_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1FJayI-0000hT-Ga 7828b3890f7c121ba01980e88977373c X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/OF5BEABC24.CF234649-ON85257132.0056C49C-85257132.0066DEF2@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12220 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 18:44:01 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 This is a multipart message in MIME format. --=_alternative 0066DE8285257132_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable If you don't want to use either workspaces or working resources, then you would just use the base WebDAV functionality for handling multiple clients concurrently updating the same resource, i.e. locking.=20 So in your original sequence, just wrap the sequence in an LOCK/UNLOCK pair, i.e.:=20 LOCK the version-controlled resource > - Retrieve the current checked-in version. (PROPFIND) > - Set it to the most recent version in a "branch". (PROPFIND, UPDATE) > - Perform a check-out or anything else that can be done on a version > controlled resource. (CHECKOUT, GET, PUT, CHECKIN) > - Set the checked-in version back to what it was. (UPDATE) UNLOCK the version-controlled resource. Cheers, Geoff Werner wrote on 03/15/2006 08:31:46 AM: > I'm not referring to working resources and I know that normally > workspaces should be used to work in parallel. However, the > workspaces feature is optional and the checkout-in-place feature > doesn't depend on it. The checkout-in-place feature provides > forking and therefore the model should be consistent in the > absence of the workspaces feature. >=20 > According to me forking and workspaces are unrelated. The forking > functionality stands on its own. When a fork is allowed for some > version, it may have more than one successor. The only way to > address a particular successor, for a check-out operation for example, > is by setting the checked-in version of the VCR to it. This is a > global state change. > Geoffrey M Clemm wrote: > >=20 > > I believe you are confusing the "checkout-in-place" feature and > > the "working-resource" feature.=20 > >=20 > > In the "checkout-in-place" feature, you make your changes > > directly on the VCR. If two clients want to be working > > in parallel, they would have separate workspaces, and each > > client would have its own VCR, so the VCR is not shared global > > state, but rather is private state for the client that owns > > that workspace. > >=20 > > In the "working-resource" feature, you do apply the > > CHECKOUT directly to a version (see section 9.3), so again, > > there is no mutable global state for which there would > > be contention. > >=20 > > The only time in which there is shared mutable state is when > > two clients are sharing the same workspace. In this case, > > the primary problem you face is the standard "lost update" problem > > while you are authoring the content, and the solution is the > > standard WebDAV solution: use the LOCK method. > >=20 > > Cheers, > > Geoff > >=20 > > Werner wrote on 03/15/2006 04:30:19 AM: > >> > >> The UPDATE method can be used to set the checked-in version of a > >> version controlled resource to a version which has descendants. > >> At that point a check-out may fork, resulting in the checked-in > >> version to have more than one descendant. > >> > >> This way a tree can be built. If one wants to grow the different > >> branches of such a tree, the UPDATE method should be used to set > >> the checked-in version of the version controlled resource > >> appropriately. This, however, changes global state, which could > >> lead to races. > >> > >> The complete operation the client would do is the following sequence: > >> - Retrieve the current checked-in version of the version controlled > > resource. > >> - Set it to the most recent version in a "branch". > >> - Perform a check-out or anything else that can be done on a version > >> controlled resource. > >> - Set the checked-in version back to what it was. > >> > >> For this to work in a multi-user environment, either the sequence > >> should be executed atomically and in isolation, or methods such as > >> check-out should be allowed to operate on versions as well. >=20 > --=20 > Werner Donn=E9 -- Re BVBA > Engelbeekstraat 8 > B-3300 Tienen > tel: (+32) 486 425803 e-mail: werner.donne@re.be >=20 --=_alternative 0066DE8285257132_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
If you don't want to use either workspaces or working resources,
then you would just use the base WebDAV functionality for handling
multiple clients concurrently updating the same reso= urce, i.e. locking.

So in your original sequence, just wrap the sequence in an LOCK/UNLOCK
pair, i.e.:  

LOCK the version-controlled resource
> - Retrieve the current checked-in version. (PRO= PFIND)
> - Set it to the most recent version in a "= branch". (PROPFIND, UPDATE)
> - Perform a check-out or anything else that can be done on a version >   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
> - Set the checked-in version back to what it was. (UPDATE)
UNLOCK the version-controlled resource.

Cheers,
Geoff

Werner wrote on 03/15/2006 08:31:46 AM:
> I'm not referring to working resources and I know that normally
> workspaces should be used to work in parallel. However, the
> workspaces feature is optional and the checkout-in-place feature
> doesn't depend on it. The checkout-in-place feature provides
> forking and therefore the model should be consistent in the
> absence of the workspaces feature.
>
> According to me forking and workspaces are unrelated. The forking
> functionality stands on its own. When a fork is allowed for some
> version, it may have more than one successor. The only way to
> address a particular successor, for a check-out operation for example,=
> is by setting the checked-in version of the VCR to it. This is a
> global state change.

> Geoffrey M Clemm wrote:
> >
> > I believe you are confusing the "checkout-in-place" feature and
> > the "working-resource" feature.  
> >
> > In the "checkout-in-place" feature, you make your chang= es
> > directly on the VCR.  If two clients want to be working
> > in parallel, they would have separate workspaces, and each
> > client would have its own VCR, so the VCR is not shared global
> > state, but rather is private state for the client that owns
> > that workspace.
> >
> > In the "working-resource" feature, you do apply the
> > CHECKOUT directly to a version (see section 9.3), so again,
> > there is no mutable global state for which there would
> > be contention.
> >
> > The only time in which there is shared mutable state is when
> > two clients are sharing the same workspace.  In this case, > > the primary problem you face is the standard "lost update&qu= ot; problem
> > while you are authoring the content, and the solution is the
> > standard WebDAV solution: use the LOCK method.
> >
> > Cheers,
> > Geoff
> >
> > Werner wrote on 03/15/2006 04:30:19 AM:
> >>
> >> The UPDATE method can be used to set the checked-in version of a
> >> version controlled resource to a version which has descendant= s.
> >> At that point a check-out may fork, resulting in the checked-= in
> >> version to have more than one descendant.
> >>
> >> This way a tree can be built. If one wants to grow the differ= ent
> >> branches of such a tree, the UPDATE method should be used to set
> >> the checked-in version of the version controlled resource
> >> appropriately. This, however, changes global state, which could
> >> lead to races.
> >>
> >> The complete operation the client would do is the following sequence:
> >> - Retrieve the current checked-in version of the version controlled
> > resource.
> >> - Set it to the most recent version in a "branch".<= br> > >> - Perform a check-out or anything else that can be done on a version
> >>   controlled resource.
> >> - Set the checked-in version back to what it was.
> >>
> >> For this to work in a multi-user environment, either the sequence
> >> should be executed atomically and in isolation, or methods such as
> >> check-out should be allowed to operate on versions as well. >
> --
> Werner Donn=E9  --  Re BVBA
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>
--=_alternative 0066DE8285257132_=-- From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 14:16:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbUQ-0000Kd-RW for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 14:16:58 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbUQ-0004FW-GD for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 14:16:58 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJbTh-00062N-5y for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 19:16:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJbTX-000618-AS for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 19:16:03 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1FJbTT-0001lQ-3k for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 19:16:02 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k2FJFub2018637; Wed, 15 Mar 2006 11:15:56 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay7.apple.com (Apple SCV relay) with ESMTP id A3E8514D; Wed, 15 Mar 2006 11:15:56 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v807) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95CE7F44-5F60-4013-AEAA-48F12743860D@apple.com> Cc: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: Jim Luther Date: Wed, 15 Mar 2006 11:15:35 -0800 To: John Barone X-Mailer: Apple Mail (2.807) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of luther.j@apple.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1FJbTT-0001lQ-3k 71765cc93aebfb0cf6b628fc4aa2eb60 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518 X-Archived-At: http://www.w3.org/mid/95CE7F44-5F60-4013-AEAA-48F12743860D@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12221 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 19:16:13 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 John, I come from a background of working mostly with file system network protocols (AFP, SMB, NFS, etc) which are designed to be used between a file system client and a file server. I first started working with HTTP/WebDAV a few years ago, I made a lot of assumptions that HTTP/ WebDAV would work like file system protocols. I've learned that a lot of those assumptions are wrong. I think the abstract of rfc2616 makes it clear that my assumptions were wrong, "The Hypertext Transfer Protocol (HTTP) is an application- level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred." So, the Mac OS X WebDAV file system client and Apple's iDisk server are using WebDAV/HTTP as a file system protocol, and the WebDAV/HTTP protocols are generic enough for that to work. However, because MOVE and COPY are not guaranteed to be atomic (all-or-nothing behavior), because what you PUT to a server isn't guaranteed to be what exactly what you GET back, and because of other behaviors that are not guaranteed by the HTTP/WebDAV specs to work the way a specific client would *like* them to work, I've come to the conclusion that all a WebDAV file system client can do is guarantee interoperability with specific WebDAV servers -- those WebDAV servers which behave like file servers. So, I agree with you that atomic MOVE and COPY operations are needed for *our* clients, but I also understand that the WebDAV/HTTP specs aren't going to guarantee that behavior. - Jim On Mar 15, 2006, at 9:30 AM, John Barone wrote: > > Well, I still don't see mixing and matching methods from various > specs. as a > coherent way of addressing the notion of atomicity (all-or-nothing > behavior) > in this spec. 2518-bis. But, that's neither here nor there; the > bottom line > is that Xythos seems to be the only ones who feel that this is a > useful > addition to the spec., so I'll let this drop as well. > > -John > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 14, 2006 10:42 AM > To: John Barone > Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org; > w3c-dist-auth-request@w3.org > Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518 > > John Barone wrote: >>> Again, what's wrong with REBIND? You can implement REBIND without >> implementing >>> anything else in the BIND spec. For that matter, you'd probably want >>> to >> implement >>> UNBIND as well (as DELETE shares the non-atomic properties with >>> MOVE). >> >> I don't understand what's proposed here. >> >> Are you proposing that we leave the 2518-bis spec. silent on this >> matter, and simply implement pieces of the binding spec. to provide >> this > capability? > > Exactly. > >> If so, that doesn't make any sense to me, since what we're really >> talking about is a different spec. with different requirements. The >> way I see it, that has no bearing on this spec. or this discussion. > > Well, both specs are discussed here, and both are supposed to be > submitted > to the IESG at roughly the same time. > >> If instead you're proposing that we add a method REBIND to this >> spec., >> with an appropriate definition; my concern is that REBIND has a >> specific meaning that's fleshed out by the context provided in the >> binding spec., but that meaning doesn't translate to the 2518-bis >> spec., where we're talking about MOVEs, COPYs, and DELETEs, not >> BINDs, > UNBINDs, and REBINDs. > > That seems to be a very theoretical argument, unless you can show > exactly > how REBIND isn't what you need... > > Best regards, Julian > > From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 14:44:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbuc-0005JC-CY for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 14:44:02 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbub-0004jm-2a for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 14:44:02 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJbu8-0004L7-Qt for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 19:43:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJbtz-0004KR-Qg for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 19:43:23 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FJbty-000148-6y for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 19:43:23 +0000 Received: from jbaroned600 ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Mar 2006 11:43:18 -0800 From: "John Barone" To: "'Julian Reschke'" Cc: "'Manfred Baedke'" , Date: Wed, 15 Mar 2006 11:43:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <44185D32.90408@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZIXqgKYSUYLeHZTw2He/kWCos4rAACMWyA Message-ID: X-OriginalArrivalTime: 15 Mar 2006 19:43:18.0602 (UTC) FILETIME=[B587EAA0:01C64868] Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJbty-000148-6y 00c801b22b950876313c5e4f9a47c5ec X-Original-To: w3c-dist-auth@w3.org Subject: RE: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/NSNOVPS00411AtTpXNr00000df9@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12222 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 19:43:32 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I can see that... although, this gets into the whole messy discussion about what a "DAV-compliant resource" means, which Manfred brought up. I would think that if the source resource /a supports dead properties and destination /b also supports dead properties, then a MOVE or COPY from /a to /b MUST copy all the dead properties. But then that language would become very messy and confusing, trying to enumerate all the permutations of what the proper behavior should be when the source and destination do/don't support dead properties. Changing the language to SHOULD retains the intended behavior, while allowing your use-case to succeed. I don't have a problem with that change. -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, March 15, 2006 10:30 AM To: John Barone Cc: 'Manfred Baedke'; w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: COPY/MOVE semantics John Barone wrote: > ... > So, what is the change in semantics that you don't agree with, and > what changes in language are you proposing to correct it? > ... I'm not objecting to a change in semantics. What I see is a discrepancy between both specs' requirements on dead property support (SHOULD), and support for copying dead properties (MUST). If resource /a supports dead properties, and /b doesn't, then a COPY request from /a to /b "MUST" fail, which IMHO isn't a useful requirement. A resource should still be able to act as a destination for COPY, even if it doesn't support dead properties. So the proposed change is to relax the requirement to SHOULD. Does this make things clearer? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 17:50:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJep7-0005HW-Qh for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 17:50:33 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJep7-0002Xl-Gg for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 17:50:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJene-0006vl-9d for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Mar 2006 22:49:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJenU-0006ta-O9 for w3c-dist-auth@listhub.w3.org; Wed, 15 Mar 2006 22:48:52 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.50) id 1FJenR-0000rj-FK for w3c-dist-auth@w3.org; Wed, 15 Mar 2006 22:48:52 +0000 Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id F146B2E900 for ; Wed, 15 Mar 2006 23:48:47 +0100 (CET) Message-ID: <441899D1.70001@greenbytes.de> Date: Wed, 15 Mar 2006 23:48:49 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJenR-0000rj-FK d69487eea3a5665207d7714afc820a1a X-Original-To: w3c-dist-auth@w3.org Subject: rfc2518bis-14: locking terminology X-Archived-At: http://www.w3.org/mid/441899D1.70001@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12223 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 15 Mar 2006 22:49:02 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi, While the new lock model, as presented in section 6.1, seems appropriate to define the terminology needed to deal with locking, I think that the spec should try to avoid falling back to language that is not covered by section 6.1: - Section 6.9: > A resource may be made available through more than one URI. A lock > MUST cover the resource as well as the URI to which the LOCK request > was addressed. The lock MAY cover other URIs mapped to the same > resource as well. It is undefined what it means for a lock to cover an URI. As far as I can tell, this section can be dropped without doing harm. - From section 7.3: > WebDAV provides the ability to lock an unmapped URL in order to > reserve the name for use. Since it is undefined what it means to lock an URI, I would rephrase this: 'WebDAV provides the ability to create a lock by submitting a LOCK request to an unmapped URL.' - From section 7.4: > A "Depth 0" write lock on a collection protects the collection metadata... It is undefined what it means for a lock to protect anything. A lock locks resources as defined by section 6.1. That's it. > With a depth-infinity lock, the root of the lock is directly locked No, since the root of the lock is an URI. > Any indirectly locked resource moved out of a locked source collection > into a depth-infinity locked target collection remains indirectly > locked but is now within the scope of the lock on the target > collection (the target collection's lock token will thereafter be > required to make further changes). The term 'lock scope' is undefined yet. Why not simply say that the resource is locked? > If a lock request causes the URL of a resource to be added as an > internal member URL of a depth-infinity locked collection then the new > resource MUST be automatically added to the lock. This is the only > mechanism that allows a resource to be added to a write lock. Thus, > for example, if the collection /a/b/ is write locked and the resource > /c is moved to /a/b/c then resource /a/b/c will be added to the write > lock. It is undefined yet what it means for a resource to be added to a lock. I think the resource is simply locked. - From section 7.6: > A COPY method invocation MUST NOT duplicate any write locks active on > the source. Lock duplication is undefined. > A successful MOVE request on a write locked resource MUST NOT move the > write lock with the resource. Moving a lock is undefined. - From section 9.11: > For a successful response to this method, the server MUST remove the > lock from the resource identified by the Request-URI and from all > other resources included in the lock. Removing a lock from a resource (or from anything else) is undefined. The lock is deleted. That's it. Some of the undefined phrases mentioned above appear more than once in the text. In these cases, I have quoted only the first appearance. Furthermore, I think that section 7 could be made significantly clearer (and shorter) if it concentrated on the general fact that the state of a write locked resource MUST not be modified by a request that does not supply the locktoken or was not issued by the lock creator, rather than listing lots of special cases that follow directly from this rule (together with section 6.1, of course). For example, the sections 7.4 and 7.6 could be dropped completely, as far as I can see. Also, I would prefer to drop all text that might raise the idea that there is something special about empty resources. IMHO, they are not more remarkable than resources with content length 42. (Well, even less, for those who know the magic of the number 42 :)) Finally, as I already stated in a previous mail, I would prefer the text concerning lock-null resources to be moved to an appendix. Regards, Manfred From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 21:37:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJiMW-0008FR-DN for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 21:37:16 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJiMU-0000Kg-VG for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 21:37:16 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJiLV-0006gh-0T for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 02:36:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJiLM-0006fO-OR for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 02:36:04 +0000 Received: from rgminet01.oracle.com ([148.87.113.118]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJiLK-0007J9-BY for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 02:36:04 +0000 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k2G2ZtQa029227; Wed, 15 Mar 2006 19:35:55 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2G2ZsR0000312; Wed, 15 Mar 2006 19:35:54 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-65.vpn.oracle.com [141.144.96.65]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2G2Zm54032749; Wed, 15 Mar 2006 19:35:52 -0700 Message-ID: <4418CF08.7090300@oracle.com> Date: Wed, 15 Mar 2006 21:35:52 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList CC: Calsify WG , WebDAV WG , Ted Hardie References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> In-Reply-To: <440D8CFC.3040706@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (lisa.w3.org: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJiLK-0007J9-BY 74e35d66477bbb03059dbea28ca43f1a X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call X-Archived-At: http://www.w3.org/mid/4418CF08.7090300@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12224 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 02:36:13 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 I thought it would be worthwhile to update everybody on the changes we are planning to make in draft -11 based on the issues that have been brought up so far: - Added new preconditions: * CALDAV:number-of-recurrences-within-limits for PUT; * CALDAV:calendar-collection-location-ok for MOVE and COPY. - Redefined the CALDAV:no-uid-conflict precondition. - Minor editorial changes. - Update to references. - Added element CALDAV:is-not-defined. - Added new attribute "negate-condition" to the CALDAV:text-match element. The last two changes were required to be able to query the to-dos that are *not* completed and *not* cancelled. The issue is that the CALDAV:calendar-query REPORT does not provide support for a "not" operator. To be able to address the above use case without increasing the complexity of the CALDAV:calendar-query REPORT significantly we have decided to add a new condition "is-not-defined" and to add a "negate-condition" attribute to be able to negate the "text-match" condition. Here's the DTD declarations that will be added to the draft: Here's an example for the to-dos use case: REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx CANCELLED Please continue to send us feedback/questions/comments. Thanks, Bernard Bernard Desruisseaux wrote: > Quick update. We will submit the CalDAV draft for Last Call when > Internet-Draft posting will resume after the next IETF meeting. > That will give more time to people to review the draft. > > Cheers, > Bernard > > Bernard Desruisseaux wrote: > >> >> We submitted CalDAV draft -10 to the IETF yesterday. The draft has >> not been officially announced yet, but it is already available for >> you to review at the following URL: >> >> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt >> >> We would like to submit the CalDAV draft for Last Call in time for >> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do >> so, we would like to get as much feedback as possible from the >> participants of the "ietf-caldav" mailing list as well as from the >> members of the WebDAV and Calsify Working Groups. >> >> Once officially announced the draft should be available at: >> >> http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt >> >> Previous versions of the draft are available at: >> >> http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ >> >> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: >> >> mailto:ietf-caldav@osafoundation.org >> >> which is archived at: >> >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >> Reports on the 4 CalDAV Interoperability Events organized by the >> Calendaring and Scheduling Consortium (CalConnect) can be found at: >> >> http://www.calconnect.org/ioppast.html >> >> Finally, additional information on CalDAV can also be found at: >> >> http://ietf.webdav.org/caldav/ >> >> Please review draft -10 and send us feedback/questions/comments. >> >> Thanks for you help! >> >> Cheers, >> Bernard >> >> -- >> >> C.1. Changes in -10 >> >> a. Added new section about support for X- items when storing data. >> >> b. Added new precondition to allow servers to reject queries on >> unsupported X- items, and a new example. >> >> c. Added new text about always supporting X- in calendar-data. >> >> d. Created new section for PUT, COPY and MOVE preconditions. >> >> e. Report examples re-done with full listing of calendar data in >> Appendix. >> >> f. Removed description of using UID, SUMMARY etc as resource name. >> >> g. Indicate that calendar object resource may contain only >> overridden components. >> >> h. Add security consideration about not expose details in resource >> names. >> >> i. Add constraint that free-busy-query can only be run on a >> collection. >> >> j. Add preconditions for calendar-timezone property/elements in >> MKCALENDAR, PROPPATCH and calendar-query REPORT. >> >> k. Fix principal-match example. >> >> >> > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav From w3c-dist-auth-request@listhub.w3.org Wed Mar 15 23:06:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJjlE-0001ze-Gh for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 23:06:52 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJjlD-0003OQ-W3 for webdav-archive@lists.ietf.org; Wed, 15 Mar 2006 23:06:52 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJjk0-0007TV-DW for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 04:05:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJjjl-0007QT-Nn for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 04:05:22 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by maggie.w3.org with esmtp (Exim 4.50) id 1FJjje-0003OT-89 for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 04:05:21 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2G45CKV019114 for ; Wed, 15 Mar 2006 23:05:12 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2G45CoH073096 for ; Wed, 15 Mar 2006 23:05:12 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2G45CbL013225 for ; Wed, 15 Mar 2006 23:05:12 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2G45C0j013218 for ; Wed, 15 Mar 2006 23:05:12 -0500 In-Reply-To: <441899D1.70001@greenbytes.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 15 Mar 2006 23:05:13 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/15/2006 23:05:11, Serialize complete at 03/15/2006 23:05:11 Content-Type: multipart/alternative; boundary="=_alternative 0016723E85257133_=" Received-SPF: none (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1FJjje-0003OT-89 e1f864ca26d57f9b1f2d292f8c46082c X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: locking terminology X-Archived-At: http://www.w3.org/mid/OFE7BBA846.02852359-ON85257133.0016122F-85257133.001672F8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12225 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 04:05:36 +0000 X-Spam-Score: 2.1 (++) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 This is a multipart message in MIME format. --=_alternative 0016723E85257133_= Content-Type: text/plain; charset="US-ASCII" I agree with all the points Manfred makes in this email, as well as the points that he made in his earlier review message. Cheers, Geoff Manfred wrote on 03/15/2006 05:48:49 PM: > > Hi, > > While the new lock model, as presented in section 6.1, seems appropriate > to define the terminology needed to deal with locking, I think that the > spec should try to avoid falling back to language that is not covered by > section 6.1: > > - Section 6.9: > > A resource may be made available through more than one URI. A lock > > MUST cover the resource as well as the URI to which the LOCK request > > was addressed. The lock MAY cover other URIs mapped to the same > > resource as well. > It is undefined what it means for a lock to cover an URI. As far as I > can tell, this section can be dropped without doing harm. > > - From section 7.3: > > WebDAV provides the ability to lock an unmapped URL in order to > > reserve the name for use. > Since it is undefined what it means to lock an URI, I would rephrase > this: 'WebDAV provides the ability to create a lock by submitting a LOCK > request to an unmapped URL.' > > - From section 7.4: > > A "Depth 0" write lock on a collection protects the collection metadata... > It is undefined what it means for a lock to protect anything. A lock > locks resources as defined by section 6.1. That's it. > > With a depth-infinity lock, the root of the lock is directly locked > No, since the root of the lock is an URI. > > Any indirectly locked resource moved out of a locked source collection > > into a depth-infinity locked target collection remains indirectly > > locked but is now within the scope of the lock on the target > > collection (the target collection's lock token will thereafter be > > required to make further changes). > The term 'lock scope' is undefined yet. Why not simply say that the > resource is locked? > > If a lock request causes the URL of a resource to be added as an > > internal member URL of a depth-infinity locked collection then the new > > resource MUST be automatically added to the lock. This is the only > > mechanism that allows a resource to be added to a write lock. Thus, > > for example, if the collection /a/b/ is write locked and the resource > > /c is moved to /a/b/c then resource /a/b/c will be added to the write > > lock. > It is undefined yet what it means for a resource to be added to a lock. > I think the resource is simply locked. > > - From section 7.6: > > A COPY method invocation MUST NOT duplicate any write locks active on > > the source. > Lock duplication is undefined. > > A successful MOVE request on a write locked resource MUST NOT move the > > write lock with the resource. > Moving a lock is undefined. > > - From section 9.11: > > For a successful response to this method, the server MUST remove the > > lock from the resource identified by the Request-URI and from all > > other resources included in the lock. > Removing a lock from a resource (or from anything else) is undefined. > The lock is deleted. That's it. > > > Some of the undefined phrases mentioned above appear more than once in > the text. In these cases, I have quoted only the first appearance. > > Furthermore, I think that section 7 could be made significantly clearer > (and shorter) if it concentrated on the general fact that the state of a > write locked resource MUST not be modified by a request that does not > supply the locktoken or was not issued by the lock creator, rather than > listing lots of special cases that follow directly from this rule > (together with section 6.1, of course). For example, the sections 7.4 > and 7.6 could be dropped completely, as far as I can see. > > Also, I would prefer to drop all text that might raise the idea that > there is something special about empty resources. IMHO, they are not > more remarkable than resources with content length 42. (Well, even less, > for those who know the magic of the number 42 :)) > > Finally, as I already stated in a previous mail, I would prefer the text > concerning lock-null resources to be moved to an appendix. > > Regards, > Manfred > > > > > > > > > > --=_alternative 0016723E85257133_= Content-Type: text/html; charset="US-ASCII"
I agree with all the points Manfred makes in this email, as well
as the points that he made in his earlier review message.

Cheers,
Geoff

Manfred wrote on 03/15/2006 05:48:49 PM:
>
> Hi,
>
> While the new lock model, as presented in section 6.1, seems appropriate
> to define the terminology needed to deal with locking, I think that the
> spec should try to avoid falling back to language that is not covered by
> section 6.1:
>
> - Section 6.9:
> > A resource may be made available through more than one URI. A lock
> > MUST cover the resource as well as the URI to which the LOCK request
> > was addressed. The lock MAY cover other URIs mapped to the same
> > resource as well.
> It is undefined what it means for a lock to cover an URI. As far as I
> can tell, this section can be dropped without doing harm.
>
> - From section 7.3:
> > WebDAV provides the ability to lock an unmapped URL in order to
> > reserve the name for use.
> Since it is undefined what it means to lock an URI, I would rephrase
> this: 'WebDAV provides the ability to create a lock by submitting a LOCK
> request to an unmapped URL.'
>
> - From section 7.4:
> > A "Depth 0" write lock on a collection protects the collection metadata...
> It is undefined what it means for a lock to protect anything. A lock
> locks resources as defined by section 6.1. That's it.
> > With a depth-infinity lock, the root of the lock is directly locked
> No, since the root of the lock is an URI.
> > Any indirectly locked resource moved out of a locked source collection
> > into a depth-infinity locked target collection remains indirectly
> > locked but is now within the scope of the lock on the target
> > collection (the target collection's lock token will thereafter be
> > required to make further changes).
> The term 'lock scope' is undefined yet. Why not simply say that the
> resource is locked?
> > If a lock request causes the URL of a resource to be added as an
> > internal member URL of a depth-infinity locked collection then the new
> > resource MUST be automatically added to the lock. This is the only
> > mechanism that allows a resource to be added to a write lock. Thus,
> > for example, if the collection /a/b/ is write locked and the resource
> > /c is moved to /a/b/c then resource /a/b/c will be added to the write
> > lock.
> It is undefined yet what it means for a resource to be added to a lock.
> I think the resource is simply locked.
>
> - From section 7.6:
> > A COPY method invocation MUST NOT duplicate any write locks active on
> > the source.
> Lock duplication is undefined.
> > A successful MOVE request on a write locked resource MUST NOT move the
> > write lock with the resource.
> Moving a lock is undefined.
>
> - From section 9.11:
> > For a successful response to this method, the server MUST remove the
> > lock from the resource identified by the Request-URI and from all
> > other resources included in the lock.
> Removing a lock from a resource (or from anything else) is undefined.
> The lock is deleted. That's it.
>
>
> Some of the undefined phrases mentioned above appear more than once in
> the text. In these cases, I have quoted only the first appearance.
>
> Furthermore, I think that section 7 could be made significantly clearer
> (and shorter) if it concentrated on the general fact that the state of a
> write locked resource MUST not be modified by a request that does not
> supply the locktoken or was not issued by the lock creator, rather than
> listing lots of special cases that follow directly from this rule
> (together with section 6.1, of course). For example, the sections 7.4
> and 7.6 could be dropped completely, as far as I can see.
>
> Also, I would prefer to drop all text that might raise the idea that
> there is something special about empty resources. IMHO, they are not
> more remarkable than resources with content length 42. (Well, even less,
> for those who know the magic of the number 42 :))
>
> Finally, as I already stated in a previous mail, I would prefer the text
> concerning lock-null resources to be moved to an appendix.
>
> Regards,
> Manfred
>
>
>
>
>
>
>
>
>
>
--=_alternative 0016723E85257133_=-- From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 05:13:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJpUJ-0007Sx-Il for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 05:13:47 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJpUJ-0004Bg-7r for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 05:13:47 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJpSq-0007UA-EV for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 10:12:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJpSg-0007T1-CF for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 10:12:06 +0000 Received: from assei2bl6.telenet-ops.be ([195.130.133.69]) by maggie.w3.org with esmtp (Exim 4.50) id 1FJpSd-0004H5-Cs for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 10:12:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by assei2bl6.telenet-ops.be (Postfix) with SMTP id AC050F005D; Thu, 16 Mar 2006 11:12:02 +0100 (CET) Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75]) by assei2bl6.telenet-ops.be (Postfix) with ESMTP id 514ADF0088; Thu, 16 Mar 2006 11:12:02 +0100 (CET) Message-ID: <441939F6.9000003@re.be> Date: Thu, 16 Mar 2006 11:12:06 +0100 From: =?ISO-8859-1?Q?Werner_Donn=E9?= Reply-To: werner.donne@re.be Organization: Re BVBA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: none (maggie.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1FJpSd-0004H5-Cs fa955289cbab353c8497e3775e628651 X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/441939F6.9000003@re.be Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12226 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 10:12:16 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Geoff, I understand it can be done like that, but I have two remarks: 1) Such a scenario should in fact be one transaction. The proposed solution doesn't protect integrity. Currently the choice is not to expose transaction demarcation to the client. That implies the WebDAV model shouldn't expose scenarios which require transactions either. 2) The locking mechanism in a versioning system is not designed to implement transactional isolation. It is merely for long-duration reservations of versions. I agree that workspaces are the feature for working in parallel, but what is then the use of forking? Which problem does it solve? Regards, Werner. Geoffrey M Clemm wrote: >=20 > If you don't want to use either workspaces or working resources, > then you would just use the base WebDAV functionality for handling > multiple clients concurrently updating the same resource, i.e. locking. >=20 > So in your original sequence, just wrap the sequence in an LOCK/UNLOCK > pair, i.e.: =20 >=20 > LOCK the version-controlled resource >> - Retrieve the current checked-in version. (PROPFIND) >> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE) >> - Perform a check-out or anything else that can be done on a version >> controlled resource. (CHECKOUT, GET, PUT, CHECKIN) >> - Set the checked-in version back to what it was. (UPDATE) > UNLOCK the version-controlled resource. >=20 > Cheers, > Geoff >=20 > Werner wrote on 03/15/2006 08:31:46 AM: >> I'm not referring to working resources and I know that normally >> workspaces should be used to work in parallel. However, the >> workspaces feature is optional and the checkout-in-place feature >> doesn't depend on it. The checkout-in-place feature provides >> forking and therefore the model should be consistent in the >> absence of the workspaces feature. >> >> According to me forking and workspaces are unrelated. The forking >> functionality stands on its own. When a fork is allowed for some >> version, it may have more than one successor. The only way to >> address a particular successor, for a check-out operation for example, >> is by setting the checked-in version of the VCR to it. This is a >> global state change. >=20 >=20 >> Geoffrey M Clemm wrote: >> > >> > I believe you are confusing the "checkout-in-place" feature and >> > the "working-resource" feature. =20 >> > >> > In the "checkout-in-place" feature, you make your changes >> > directly on the VCR. If two clients want to be working >> > in parallel, they would have separate workspaces, and each >> > client would have its own VCR, so the VCR is not shared global >> > state, but rather is private state for the client that owns >> > that workspace. >> > >> > In the "working-resource" feature, you do apply the >> > CHECKOUT directly to a version (see section 9.3), so again, >> > there is no mutable global state for which there would >> > be contention. >> > >> > The only time in which there is shared mutable state is when >> > two clients are sharing the same workspace. In this case, >> > the primary problem you face is the standard "lost update" problem >> > while you are authoring the content, and the solution is the >> > standard WebDAV solution: use the LOCK method. >> > >> > Cheers, >> > Geoff >> > >> > Werner wrote on 03/15/2006 04:30:19 AM: >> >> >> >> The UPDATE method can be used to set the checked-in version of a >> >> version controlled resource to a version which has descendants. >> >> At that point a check-out may fork, resulting in the checked-in >> >> version to have more than one descendant. >> >> >> >> This way a tree can be built. If one wants to grow the different >> >> branches of such a tree, the UPDATE method should be used to set >> >> the checked-in version of the version controlled resource >> >> appropriately. This, however, changes global state, which could >> >> lead to races. >> >> >> >> The complete operation the client would do is the following sequenc= e: >> >> - Retrieve the current checked-in version of the version controlled >> > resource. >> >> - Set it to the most recent version in a "branch". >> >> - Perform a check-out or anything else that can be done on a versio= n >> >> controlled resource. >> >> - Set the checked-in version back to what it was. >> >> >> >> For this to work in a multi-user environment, either the sequence >> >> should be executed atomically and in isolation, or methods such as >> >> check-out should be allowed to operate on versions as well. >> >> -- >> Werner Donn=E9 -- Re BVBA >> Engelbeekstraat 8 >> B-3300 Tienen >> tel: (+32) 486 425803 e-mail: werner.donne@re.be >> --=20 Werner Donn=E9 -- Re Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 07:31:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJrdI-0006Ku-9Q for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 07:31:12 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJrdH-0007gC-If for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 07:31:12 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJrbZ-0007bN-CM for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 12:29:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJrbR-0007Zt-Li for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 12:29:17 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJrbO-0002kw-Co for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 12:29:17 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2GCTCK4014783 for ; Thu, 16 Mar 2006 07:29:12 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2GCTCnN184480 for ; Thu, 16 Mar 2006 07:29:12 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2GCTCF4029805 for ; Thu, 16 Mar 2006 07:29:12 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2GCTCnZ029801; Thu, 16 Mar 2006 07:29:12 -0500 In-Reply-To: <441939F6.9000003@re.be> To: werner.donne@re.be Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 16 Mar 2006 07:29:10 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/16/2006 07:29:11, Serialize complete at 03/16/2006 07:29:11 Content-Type: multipart/alternative; boundary="=_alternative 004495AA85257133_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1FJrbO-0002kw-Co 7a860137a3e307866a200a0c7596ecc6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/OF52BB1AE6.DF1B66E6-ON85257133.0041A963-85257133.00449620@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12227 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 12:29:25 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 This is a multipart message in MIME format. --=_alternative 004495AA85257133_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable (1) Why does this scenario have to be in one transaction? In particular, why isn't it sufficient just to wrap the sequence of operations in a LOCK/UNLOCK?=20 (2) I agree that the locking mechanism is not designed to implement transactional isolation. That is what workspaces and working resources are designed for. If (for unexplained reasons :-) you don't want to use the versioning features that were designed for transactional isolation, it should come as no surprise that you have difficulty achieving transactional isolation. Some clients don't want/need transactional isolation (they just want history to be kept, for example), which is why workspaces and working resources are optional features (we define these two different ways of achieving transactional isolation=20 because some repositories can only support one, while other repositories can only support the other, and we could find no way of unifying these two different ways under a single feature). As for the why support forking, it is an (undesireable, but inevitable) side-effect of parallel development. So we don't define it as an independent feature, but we "deal with it" for those features that support parallel development (i.e., workspaces and working resources). In particular, it is what tells you that parallel development has occurred on a particular resource, and that therefore a merge is required (the need for a merge when forking occurs is why it is "undesireable"). So creating forks in a non-parallel development context makes no sense ... you are just making trouble for yourself. Which is why forking only occurs as a side effect of parallel development, and not as a feature that you explicitly invoke. Cheers, Geoff Werner Donn=E9 wrote on 03/16/2006 05:12:06 AM: > Geoff, >=20 > I understand it can be done like that, but I have two remarks: >=20 > 1) Such a scenario should in fact be one transaction. The proposed > solution doesn't protect integrity. Currently the choice is not > to expose transaction demarcation to the client. That implies > the WebDAV model shouldn't expose scenarios which require=20 transactions > either. >=20 > 2) The locking mechanism in a versioning system is not designed to > implement transactional isolation. It is merely for long-duration > reservations of versions. >=20 > I agree that workspaces are the feature for working in parallel, but > what is then the use of forking? Which problem does it solve? >=20 > Regards, >=20 > Werner. >=20 > Geoffrey M Clemm wrote: > >=20 > > If you don't want to use either workspaces or working resources, > > then you would just use the base WebDAV functionality for handling > > multiple clients concurrently updating the same resource, i.e.=20 locking. > >=20 > > So in your original sequence, just wrap the sequence in an LOCK/UNLOCK > > pair, i.e.:=20 > >=20 > > LOCK the version-controlled resource > >> - Retrieve the current checked-in version. (PROPFIND) > >> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE) > >> - Perform a check-out or anything else that can be done on a version > >> controlled resource. (CHECKOUT, GET, PUT, CHECKIN) > >> - Set the checked-in version back to what it was. (UPDATE) > > UNLOCK the version-controlled resource. > >=20 > > Cheers, > > Geoff > >=20 > > Werner wrote on 03/15/2006 08:31:46 AM: > >> I'm not referring to working resources and I know that normally > >> workspaces should be used to work in parallel. However, the > >> workspaces feature is optional and the checkout-in-place feature > >> doesn't depend on it. The checkout-in-place feature provides > >> forking and therefore the model should be consistent in the > >> absence of the workspaces feature. > >> > >> According to me forking and workspaces are unrelated. The forking > >> functionality stands on its own. When a fork is allowed for some > >> version, it may have more than one successor. The only way to > >> address a particular successor, for a check-out operation for=20 example, > >> is by setting the checked-in version of the VCR to it. This is a > >> global state change. > >=20 > >=20 > >> Geoffrey M Clemm wrote: > >> > > >> > I believe you are confusing the "checkout-in-place" feature and > >> > the "working-resource" feature.=20 > >> > > >> > In the "checkout-in-place" feature, you make your changes > >> > directly on the VCR. If two clients want to be working > >> > in parallel, they would have separate workspaces, and each > >> > client would have its own VCR, so the VCR is not shared global > >> > state, but rather is private state for the client that owns > >> > that workspace. > >> > > >> > In the "working-resource" feature, you do apply the > >> > CHECKOUT directly to a version (see section 9.3), so again, > >> > there is no mutable global state for which there would > >> > be contention. > >> > > >> > The only time in which there is shared mutable state is when > >> > two clients are sharing the same workspace. In this case, > >> > the primary problem you face is the standard "lost update" problem > >> > while you are authoring the content, and the solution is the > >> > standard WebDAV solution: use the LOCK method. > >> > > >> > Cheers, > >> > Geoff > >> > > >> > Werner wrote on 03/15/2006 04:30:19 AM: > >> >> > >> >> The UPDATE method can be used to set the checked-in version of a > >> >> version controlled resource to a version which has descendants. > >> >> At that point a check-out may fork, resulting in the checked-in > >> >> version to have more than one descendant. > >> >> > >> >> This way a tree can be built. If one wants to grow the different > >> >> branches of such a tree, the UPDATE method should be used to set > >> >> the checked-in version of the version controlled resource > >> >> appropriately. This, however, changes global state, which could > >> >> lead to races. > >> >> > >> >> The complete operation the client would do is the following=20 sequence: > >> >> - Retrieve the current checked-in version of the version=20 controlled > >> > resource. > >> >> - Set it to the most recent version in a "branch". > >> >> - Perform a check-out or anything else that can be done on a=20 version > >> >> controlled resource. > >> >> - Set the checked-in version back to what it was. > >> >> > >> >> For this to work in a multi-user environment, either the sequence > >> >> should be executed atomically and in isolation, or methods such as > >> >> check-out should be allowed to operate on versions as well. > >> > >> -- > >> Werner Donn=E9 -- Re BVBA > >> Engelbeekstraat 8 > >> B-3300 Tienen > >> tel: (+32) 486 425803 e-mail: werner.donne@re.be > >> >=20 > --=20 > Werner Donn=E9 -- Re > Engelbeekstraat 8 > B-3300 Tienen > tel: (+32) 486 425803 e-mail: werner.donne@re.be --=_alternative 004495AA85257133_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
(1) Why does this scenario have to be in one transac= tion?  In particular,
why isn't it sufficient just to wrap the sequence of operations in
a LOCK/UNLOCK?  

(2) I agree that the locking mechanism is not design= ed to implement
transactional isolation.  That is what workspac= es and working resources
are designed for.  If (for unexplained reasons :-) you don't want to
use the versioning features that were designed for transactional
isolation, it should come as no surprise that you have difficulty
achieving transactional isolation.  Some clients don't want/need
transactional isolation (they just want history to be kept, for example),
which is why workspaces and working resources are optional features
(we define these two different ways of achieving tra= nsactional isolation
because some repositories can only support one, while other repositories
can only support the other, and we could find no way of unifying these
two different ways under a single feature).

As for the why support forking, it is an (undesireab= le, but inevitable)
side-effect of parallel development.  So we don= 't define it as an
independent feature, but we "deal with it" for those features that
support parallel development (i.e., workspaces and working resources).
In particular, it is what tells you that parallel development has
occurred on a particular resource, and that therefore a merge is
required (the need for a merge when forking occurs is why it is
"undesireable").

So creating forks in a non-parallel development cont= ext makes no sense ...
you are just making trouble for yourself.  Which is why forking only
occurs as a side effect of parallel development, and not as a feature that
you explicitly invoke.

Cheers,
Geoff



Werner Donn=E9 <werner.donne@re.be> wrote on 0= 3/16/2006 05:12:06 AM:
> Geoff,
>
> I understand it can be done like that, but I have two remarks:
>
> 1) Such a scenario should in fact be one transaction. The proposed
>    solution doesn't protect integrity. Currently the choice is not
>    to expose transaction demarcation to the client. That implies
>    the WebDAV model shouldn't expose scenarios which require transactions
>    either.
>
> 2) The locking mechanism in a versioning system is not designed to
>    implement transactional isolation. It is merely for long-= duration
>    reservations of versions.
>
> I agree that workspaces are the feature for working in parallel, but > what is then the use of forking? Which problem does it solve?
>
> Regards,
>
> Werner.
>
> Geoffrey M Clemm wrote:
> >
> > If you don't want to use either workspaces or working resources,<= br> > > then you would just use the base WebDAV functionality for handlin= g
> > multiple clients concurrently updating the same resource, i.e. locking.
> >
> > So in your original sequence, just wrap the sequence in an LOCK/U= NLOCK
> > pair, i.e.:  
> >
> > LOCK the version-controlled resource
> >> - Retrieve the current checked-in version. (PROPFIND)
> >> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE)
> >> - Perform a check-out or anything else that can be done on a version
> >>   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
> >> - Set the checked-in version back to what it was. (UPDATE)
> > UNLOCK the version-controlled resource.
> >
> > Cheers,
> > Geoff
> >
> > Werner wrote on 03/15/2006 08:31:46 AM:
> >> I'm not referring to working resources and I know that normal= ly
> >> workspaces should be used to work in parallel. However, the > >> workspaces feature is optional and the checkout-in-place feature
> >> doesn't depend on it. The checkout-in-place feature provides<= br> > >> forking and therefore the model should be consistent in the > >> absence of the workspaces feature.
> >>
> >> According to me forking and workspaces are unrelated. The forking
> >> functionality stands on its own. When a fork is allowed for some
> >> version, it may have more than one successor. The only way to
> >> address a particular successor, for a check-out operation for example,
> >> is by setting the checked-in version of the VCR to it. This is a
> >> global state change.
> >
> >
> >> Geoffrey M Clemm wrote:
> >> >
> >> > I believe you are confusing the "checkout-in-place&= quot; feature and
> >> > the "working-resource" feature.  
> >> >
> >> > In the "checkout-in-place" feature, you make your changes
> >> > directly on the VCR.  If two clients want to be working
> >> > in parallel, they would have separate workspaces, and each
> >> > client would have its own VCR, so the VCR is not shared global
> >> > state, but rather is private state for the client that owns
> >> > that workspace.
> >> >
> >> > In the "working-resource" feature, you do apply the
> >> > CHECKOUT directly to a version (see section 9.3), so again,
> >> > there is no mutable global state for which there would > >> > be contention.
> >> >
> >> > The only time in which there is shared mutable state is when
> >> > two clients are sharing the same workspace.  In this case,
> >> > the primary problem you face is the standard "lost update" problem
> >> > while you are authoring the content, and the solution is the
> >> > standard WebDAV solution: use the LOCK method.
> >> >
> >> > Cheers,
> >> > Geoff
> >> >
> >> > Werner wrote on 03/15/2006 04:30:19 AM:
> >> >>
> >> >> The UPDATE method can be used to set the checked-in version of a
> >> >> version controlled resource to a version which has descendants.
> >> >> At that point a check-out may fork, resulting in the checked-in
> >> >> version to have more than one descendant.
> >> >>
> >> >> This way a tree can be built. If one wants to grow the different
> >> >> branches of such a tree, the UPDATE method should be used to set
> >> >> the checked-in version of the version controlled resource
> >> >> appropriately. This, however, changes global state, which could
> >> >> lead to races.
> >> >>
> >> >> The complete operation the client would do is the following sequence:
> >> >> - Retrieve the current checked-in version of the version controlled
> >> > resource.
> >> >> - Set it to the most recent version in a "branc= h".
> >> >> - Perform a check-out or anything else that can be done on a version
> >> >>   controlled resource.
> >> >> - Set the checked-in version back to what it was.
> >> >>
> >> >> For this to work in a multi-user environment, either the sequence
> >> >> should be executed atomically and in isolation, or methods such as
> >> >> check-out should be allowed to operate on versions as well.
> >>
> >> --
> >> Werner Donn=E9  --  Re BVBA
> >> Engelbeekstraat 8
> >> B-3300 Tienen
> >> tel: (+32) 486 425803   e-mail: werner.donne@re.be
> >>
>
> --
> Werner Donn=E9  --  Re
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803   e-mail: werner.donne@re.be
 --=_alternative 004495AA85257133_=-- From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 08:02:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJs7j-0004a7-A1 for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 08:02:39 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJs7i-0000af-Rs for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 08:02:39 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJs7H-0000Ia-EL for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 13:02:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJs79-0000HP-Lk for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 13:02:03 +0000 Received: from assei1bl6.telenet-ops.be ([195.130.133.68]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJs70-00025O-To for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 13:02:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by assei1bl6.telenet-ops.be (Postfix) with SMTP id 6753322008A; Thu, 16 Mar 2006 14:01:53 +0100 (CET) Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75]) by assei1bl6.telenet-ops.be (Postfix) with ESMTP id D32FB2200E4; Thu, 16 Mar 2006 14:01:52 +0100 (CET) Message-ID: <441961C5.2080208@re.be> Date: Thu, 16 Mar 2006 14:01:57 +0100 From: =?ISO-8859-1?Q?Werner_Donn=E9?= Reply-To: werner.donne@re.be Organization: Re BVBA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm Cc: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: none (lisa.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJs70-00025O-To e247e3b57a07677fffc268b1c670ad0e X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/441961C5.2080208@re.be Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12228 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 13:02:11 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Geoffrey M Clemm wrote: >=20 > (1) Why does this scenario have to be in one transaction? In particula= r, > why isn't it sufficient just to wrap the sequence of operations in > a LOCK/UNLOCK? =20 Because anything in between can go wrong, leaving the system in an inconsistent state. It can't be the responsibility of the client to keep the state consistent. That is a co-operative and hence unreliable design. >=20 > (2) I agree that the locking mechanism is not designed to implement > transactional isolation. That is what workspaces and working resources > are designed for. If (for unexplained reasons :-) you don't want to > use the versioning features that were designed for transactional > isolation, it should come as no surprise that you have difficulty > achieving transactional isolation. Some clients don't want/need > transactional isolation (they just want history to be kept, for example= ), > which is why workspaces and working resources are optional features > (we define these two different ways of achieving transactional isolatio= n > because some repositories can only support one, while other repositorie= s > can only support the other, and we could find no way of unifying these > two different ways under a single feature). This is obviously not at all about what I want or don't want to use. I'm reasoning about the WebDAV model. I haven't said I was against workspaces= . >=20 > As for the why support forking, it is an (undesireable, but inevitable) > side-effect of parallel development. So we don't define it as an > independent feature, but we "deal with it" for those features that > support parallel development (i.e., workspaces and working resources). > In particular, it is what tells you that parallel development has > occurred on a particular resource, and that therefore a merge is > required (the need for a merge when forking occurs is why it is > "undesireable"). >=20 > So creating forks in a non-parallel development context makes no sense = ... > you are just making trouble for yourself. Which is why forking only > occurs as a side effect of parallel development, and not as a feature t= hat > you explicitly invoke. Which is what I reckoned and it is an encapsulation flaw. Clearly, forkin= g on its own is useless, but it is exposed through the WebDAV interface wit= h elements such as "checkin-fork", "checkout-fork", "fork-ok". There is no reason for this, nor for the UPDATE method to be allowed to change the checked-in version, which is the source of the problem. Creating a new VCR in a workspace from a given version obviously requires forking, but that is merely an internal implementation matter. >=20 > Cheers, > Geoff >=20 Regards, Werner. >=20 >=20 > Werner Donn=E9 wrote on 03/16/2006 05:12:06 AM: >> Geoff, >> >> I understand it can be done like that, but I have two remarks: >> >> 1) Such a scenario should in fact be one transaction. The proposed >> solution doesn't protect integrity. Currently the choice is not >> to expose transaction demarcation to the client. That implies >> the WebDAV model shouldn't expose scenarios which require transacti= ons >> either. >> >> 2) The locking mechanism in a versioning system is not designed to >> implement transactional isolation. It is merely for long-duration >> reservations of versions. >> >> I agree that workspaces are the feature for working in parallel, but >> what is then the use of forking? Which problem does it solve? >> >> Regards, >> >> Werner. >> >> Geoffrey M Clemm wrote: >> > >> > If you don't want to use either workspaces or working resources, >> > then you would just use the base WebDAV functionality for handling >> > multiple clients concurrently updating the same resource, i.e. locki= ng. >> > >> > So in your original sequence, just wrap the sequence in an LOCK/UNLO= CK >> > pair, i.e.: =20 >> > >> > LOCK the version-controlled resource >> >> - Retrieve the current checked-in version. (PROPFIND) >> >> - Set it to the most recent version in a "branch". (PROPFIND, UPDAT= E) >> >> - Perform a check-out or anything else that can be done on a versio= n >> >> controlled resource. (CHECKOUT, GET, PUT, CHECKIN) >> >> - Set the checked-in version back to what it was. (UPDATE) >> > UNLOCK the version-controlled resource. >> > >> > Cheers, >> > Geoff >> > >> > Werner wrote on 03/15/2006 08:31:46 AM: >> >> I'm not referring to working resources and I know that normally >> >> workspaces should be used to work in parallel. However, the >> >> workspaces feature is optional and the checkout-in-place feature >> >> doesn't depend on it. The checkout-in-place feature provides >> >> forking and therefore the model should be consistent in the >> >> absence of the workspaces feature. >> >> >> >> According to me forking and workspaces are unrelated. The forking >> >> functionality stands on its own. When a fork is allowed for some >> >> version, it may have more than one successor. The only way to >> >> address a particular successor, for a check-out operation for examp= le, >> >> is by setting the checked-in version of the VCR to it. This is a >> >> global state change. >> > >> > >> >> Geoffrey M Clemm wrote: >> >> > >> >> > I believe you are confusing the "checkout-in-place" feature and >> >> > the "working-resource" feature. =20 >> >> > >> >> > In the "checkout-in-place" feature, you make your changes >> >> > directly on the VCR. If two clients want to be working >> >> > in parallel, they would have separate workspaces, and each >> >> > client would have its own VCR, so the VCR is not shared global >> >> > state, but rather is private state for the client that owns >> >> > that workspace. >> >> > >> >> > In the "working-resource" feature, you do apply the >> >> > CHECKOUT directly to a version (see section 9.3), so again, >> >> > there is no mutable global state for which there would >> >> > be contention. >> >> > >> >> > The only time in which there is shared mutable state is when >> >> > two clients are sharing the same workspace. In this case, >> >> > the primary problem you face is the standard "lost update" proble= m >> >> > while you are authoring the content, and the solution is the >> >> > standard WebDAV solution: use the LOCK method. >> >> > >> >> > Cheers, >> >> > Geoff >> >> > >> >> > Werner wrote on 03/15/2006 04:30:19 AM: >> >> >> >> >> >> The UPDATE method can be used to set the checked-in version of a >> >> >> version controlled resource to a version which has descendants. >> >> >> At that point a check-out may fork, resulting in the checked-in >> >> >> version to have more than one descendant. >> >> >> >> >> >> This way a tree can be built. If one wants to grow the different >> >> >> branches of such a tree, the UPDATE method should be used to set >> >> >> the checked-in version of the version controlled resource >> >> >> appropriately. This, however, changes global state, which could >> >> >> lead to races. >> >> >> >> >> >> The complete operation the client would do is the following > sequence: >> >> >> - Retrieve the current checked-in version of the version control= led >> >> > resource. >> >> >> - Set it to the most recent version in a "branch". >> >> >> - Perform a check-out or anything else that can be done on a ver= sion >> >> >> controlled resource. >> >> >> - Set the checked-in version back to what it was. >> >> >> >> >> >> For this to work in a multi-user environment, either the sequenc= e >> >> >> should be executed atomically and in isolation, or methods such = as >> >> >> check-out should be allowed to operate on versions as well. >> >> >> >> -- >> >> Werner Donn=E9 -- Re BVBA >> >> Engelbeekstraat 8 >> >> B-3300 Tienen >> >> tel: (+32) 486 425803 e-mail: werner.donne@re.be >> >> >> >> -- >> Werner Donn=E9 -- Re >> Engelbeekstraat 8 >> B-3300 Tienen >> tel: (+32) 486 425803 e-mail: werner.donne@re.be --=20 Werner Donn=E9 -- Re Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 09:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtCl-0004WG-5s for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 09:11:55 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtCj-0003IR-Qv for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 09:11:55 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJtBr-0004Nv-MC for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 14:10:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJtBJ-0004M1-0o for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 14:10:25 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1FJtBC-0002bK-Ay for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 14:10:21 +0000 Received: (qmail invoked by alias); 16 Mar 2006 14:10:16 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 16 Mar 2006 15:10:16 +0100 X-Authenticated: #1915285 Message-ID: <4419717E.6030102@gmx.de> Date: Thu, 16 Mar 2006 15:09:02 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Manfred Baedke CC: John Barone , w3c-dist-auth@w3.org References: <44186047.6090302@greenbytes.de> In-Reply-To: <44186047.6090302@greenbytes.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJtBC-0002bK-Ay c7b273333c55eea67b414dac7377da71 X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: COPY/MOVE semantics X-Archived-At: http://www.w3.org/mid/4419717E.6030102@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12229 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 14:10:59 +0000 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Manfred Baedke wrote: > John, > > after reading these sections again, I have to admit that RFC2518 > apparently intended to say that dead properties MUST be preserved by > COPY/MOVE unless specified otherwise by the propertybehavior element. > Therefore, I will have to change my mind from objecting against a > semantical change to proposing a semantical change :) > My point is that the MUST requirement simply does not match the SHOULD > requirement of PROPPATCH. It would be plainly impossible to COPY a > resource with dead properties to a server that does not support dead > properties (for example, a simple file system based implementation). I > am proposing to relax the requirement to SHOULD level. > > Regards, > Manfred OK, I opened an issue for this one on BugZilla (). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 09:12:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJtDS-0004Z7-8e for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 09:12:38 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJtDR-0003Ji-MI for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 09:12:38 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJtDE-0004eh-QM for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 14:12:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJtDB-0004d2-93 for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 14:12:21 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.50) id 1FJtCw-00033O-Le for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 14:12:20 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2GEBv8g014237 for ; Thu, 16 Mar 2006 09:11:57 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2GEBvnN116712 for ; Thu, 16 Mar 2006 09:11:57 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2GEBvIW004036 for ; Thu, 16 Mar 2006 09:11:57 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2GEBvMn004031; Thu, 16 Mar 2006 09:11:57 -0500 In-Reply-To: <441961C5.2080208@re.be> To: werner.donne@re.be Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 16 Mar 2006 09:11:55 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/16/2006 09:11:56, Serialize complete at 03/16/2006 09:11:56 Content-Type: multipart/alternative; boundary="=_alternative 004DFCE785257133_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1FJtCw-00033O-Le 7e09f32d2cbcee122b4e753da505ea60 X-Original-To: w3c-dist-auth@w3.org Subject: Re: UPDATE method and forking X-Archived-At: http://www.w3.org/mid/OF6BB184EF.7222B06C-ON85257133.004833EB-85257133.004DFE55@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12230 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 14:12:24 +0000 X-Spam-Score: 2.3 (++) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 This is a multipart message in MIME format. --=_alternative 004DFCE785257133_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Werner Donn=E9 wrote on 03/16/2006 08:01:57 AM: > Geoffrey M Clemm wrote: > >=20 > > (1) Why does this scenario have to be in one transaction? In=20 particular, > > why isn't it sufficient just to wrap the sequence of operations in > > a LOCK/UNLOCK?=20 >=20 > Because anything in between can go wrong, leaving the system in an > inconsistent state. It can't be the responsibility of the client to > keep the state consistent. That is a co-operative and hence unreliable > design. The only thing that can go wrong is that the client neglects to perform an UNLOCK, which is why there are timeout and administrative override=20 mechanisms in the locking protocol. But I agree that many clients would rather not=20 deal with locks, which is why we introduced the workspace feature. So=20 lets focus on whether or not the workspace feature provides what you need. > > (2) I agree that the locking mechanism is not designed to implement > > transactional isolation. That is what workspaces and working=20 resources > > are designed for. If (for unexplained reasons :-) you don't want to > > use the versioning features that were designed for transactional > > isolation, it should come as no surprise that you have difficulty > > achieving transactional isolation. Some clients don't want/need > > transactional isolation (they just want history to be kept, for=20 example), > > which is why workspaces and working resources are optional features > > (we define these two different ways of achieving transactional=20 isolation > > because some repositories can only support one, while other=20 repositories > > can only support the other, and we could find no way of unifying these > > two different ways under a single feature). >=20 > This is obviously not at all about what I want or don't want to use. > I'm reasoning about the WebDAV model. I haven't said I was against=20 workspaces. Well, to be honest, it is not at all clear to me what you do or do not want to do (:-). The purpose of the WebDAV model is provide a uniform protocol for accessing the various authoring features provided by a wide variety of repositories. So the interesting questions are "how do I as a client use the protocol to achieve this interesting use case for a user" and "how do I as a repository use the protocol to expose this particular feature of my repository to a client". Without one of those questions in hand, one cannot have a productive discussion about the WebDAV model. > > As for the why support forking, it is an (undesireable, but=20 inevitable) > > side-effect of parallel development. So we don't define it as an > > independent feature, but we "deal with it" for those features that > > support parallel development (i.e., workspaces and working resources). > > In particular, it is what tells you that parallel development has > > occurred on a particular resource, and that therefore a merge is > > required (the need for a merge when forking occurs is why it is > > "undesireable"). > >=20 > > So creating forks in a non-parallel development context makes no sense = ... > > you are just making trouble for yourself. Which is why forking only > > occurs as a side effect of parallel development, and not as a feature=20 that > > you explicitly invoke. >=20 > Which is what I reckoned and it is an encapsulation flaw. Clearly,=20 forking > on its own is useless, but it is exposed through the WebDAV interface=20 with > elements such as "checkin-fork", "checkout-fork", "fork-ok". There is no > reason for this, nor for the UPDATE method to be allowed to change the > checked-in version, which is the source of the problem. The way WebDAV (and HTTP) achieves interoperability is by having a client use a single uniform protocol against a wide variety of servers. So the client always uses the UPDATE method to "restore" a version from history, whether it is working with a server that supports working resources,=20 supports workspaces, supports both, or supports neither. Changing the checked-in version is important when the server supports either workspaces or working resources, so you have clients uniformly use the UPDATE method. This means that a client is aware of checkin-fork, checkout-fork, and fork-ok behavior, so that in behaves properly when it is applied to a server that supports either workspaces or working resources. > Creating a new > VCR in a workspace from a given version obviously requires forking, but > that is merely an internal implementation matter. No, it's part of the explicit user model, because when you invoke the=20 MERGE method, the result of the MERGE method is affected by whether or not there = has been any branching, so the client needs to understand when a branch will=20 occur, and when it won't.=20 Cheers, Geoff =20 --=_alternative 004DFCE785257133_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Werner Donn=E9 <werner.donne@re.be> wrote on 0= 3/16/2006 08:01:57 AM:

> Geoffrey M Clemm wrote:
> >
> > (1) Why does this scenario have to be in one transaction?  In particular,
> > why isn't it sufficient just to wrap the sequence of operations in
> > a LOCK/UNLOCK?  
>
> Because anything in between can go wrong, leaving the system in an
> inconsistent state. It can't be the responsibility of the client to
> keep the state consistent. That is a co-operative and hence unreliable=
> design.

The only thing that can go wrong is that the client neglects to perform
an UNLOCK, which is why there are timeout and admini= strative override mechanisms
in the locking protocol.  But I agree that many clients would rather not
deal with locks, which is why we introduced the work= space feature.  So lets
focus on whether or not the workspace feature provid= es what you need.

> > (2) I agree that the locking mechanism is not designed to impleme= nt
> > transactional isolation.  That is what workspaces and working resources
> > are designed for.  If (for unexplained reasons :-) you don't want to
> > use the versioning features that were designed for transactional<= br> > > isolation, it should come as no surprise that you have difficulty=
> > achieving transactional isolation.  Some clients don't want/= need
> > transactional isolation (they just want history to be kept, for example),
> > which is why workspaces and working resources are optional featur= es
> > (we define these two different ways of achieving transactional isolation
> > because some repositories can only support one, while other repos= itories
> > can only support the other, and we could find no way of unifying these
> > two different ways under a single feature).
>
> This is obviously not at all about what I want or don't want to use.
> I'm reasoning about the WebDAV model. I haven't said I was against workspaces.

Well, to be honest, it is not at all clear to me what you do or do not
want to do (:-).  The purpose of the WebDAV mod= el is provide a uniform
protocol for accessing the various authoring features provided by
a wide variety of repositories.  So the interes= ting questions are
"how do I as a client use the protocol to achie= ve this interesting
use case for a user" and "how do I as a repository use the protocol
to expose this particular feature of my repository to a client".
Without one of those questions in hand, one cannot have a productive
discussion about the WebDAV model.

> > As for the why support forking, it is an (undesireable, but inevitable)
> > side-effect of parallel development.  So we don't define it as an
> > independent feature, but we "deal with it" for those features that
> > support parallel development (i.e., workspaces and working resour= ces).
> > In particular, it is what tells you that parallel development has
> > occurred on a particular resource, and that therefore a merge is
> > required (the need for a merge when forking occurs is why it is
> > "undesireable").
> >
> > So creating forks in a non-parallel development context makes no sense ...
> > you are just making trouble for yourself.  Which is why forking only
> > occurs as a side effect of parallel development, and not as a feature that
> > you explicitly invoke.
>
> Which is what I reckoned and it is an encapsulation flaw. Clearly, forking
> on its own is useless, but it is exposed through the WebDAV interface with
> elements such as "checkin-fork", "checkout-fork", "fork-ok". There is no
> reason for this, nor for the UPDATE method to be allowed to change the
> checked-in version, which is the source of the problem.

The way WebDAV (and HTTP) achieves interoperability is by having a client
use a single uniform protocol against a wide variety of servers.  So the
client always uses the UPDATE method to "restor= e" a version from history,
whether it is working with a server that supports working resources, supports
workspaces, supports both, or supports neither. &nbs= p;Changing the checked-in
version is important when the server supports either workspaces or
working resources, so you have clients uniformly use the UPDATE method.
This means that a client is aware of checkin-fork, checkout-fork, and
fork-ok behavior, so that in behaves properly when it is applied to a
server that supports either workspaces or working resources.

> Creating a new
> VCR in a workspace from a given version obviously requires forking, but
> that is merely an internal implementation matter.

No, it's part of the explicit user model, because when you invoke the MERGE
method, the result of the MERGE method is affected by whether or not there has
been any branching, so the client needs to understand when a branch will occur,
and when it won't.  

Cheers,
Geoff
 


--=_alternative 004DFCE785257133_=-- From ovio@ibeu.org.br Thu Mar 16 10:18:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJuFW-0005YJ-3H for webdav-archive@ietf.org; Thu, 16 Mar 2006 10:18:50 -0500 Received: from anancy-156-1-48-217.w83-203.abo.wanadoo.fr ([83.203.247.217] helo=ibeu.org.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJuFU-00054K-60 for webdav-archive@ietf.org; Thu, 16 Mar 2006 10:18:50 -0500 Message-ID: <000001c6490c$e1120e90$5c39a8c0@jzm62> Reply-To: "Ovi Hutton" From: "Ovi Hutton" To: webdav-archive@ietf.org Subject: Re: PharUZamacy news Date: Thu, 16 Mar 2006 10:18:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C648E2.F83C0690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C648E2.F83C0690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 q C u i g a u I e i d s $9 e 9 ( UY 10 o p y i v l u l g s f ) i V k a y I i i b u v m $10 y 5 (3 t0 0 w p n i s l j l b s t ) s V x i i a p g e r y a $ z 69 (10 mp e p t i j l s l i s s ) =20 Many ot 5p her, V RN isit our s qk ite and S Dg ave ove UT r 5 K2 0% ------=_NextPart_000_0001_01C648E2.F83C0690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
q C u i g a u I e i d s $9 e 9 ( UY 10  o p y i v l u l g s f )
i V k a y I i i b u v m $10 y 5 (3 t0 0  w p n i s l j l b s t )
s V x i i a p g e r y a $ z 69 (10 mp   e p t i j l s l i s s )
 
Many ot 5p her, V RN isit our s qk ite and S Dg ave ove UT r 5 K2 0%
------=_NextPart_000_0001_01C648E2.F83C0690-- From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 11:07:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJv0e-0001Zy-6a for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 11:07:32 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJv0d-0006u9-Nn for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 11:07:32 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJuzj-0004h5-5W for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 16:06:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1FJuzY-0004fk-UA for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 16:06:24 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.50) id 1FJuzW-0005sx-AP for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 16:06:24 +0000 Received: from jbaroned600 ([69.107.70.231]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Mar 2006 08:03:13 -0800 From: "John Barone" To: "'Manfred Baedke'" , Date: Thu, 16 Mar 2006 08:03:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <441899D1.70001@greenbytes.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcZIguC7PMPBIMTYScK8/ShITI+dygAjEhNw Message-ID: X-OriginalArrivalTime: 16 Mar 2006 16:03:13.0701 (UTC) FILETIME=[2135AD50:01C64913] Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1FJuzW-0005sx-AP 54edd353177aeab9738325a051384ca8 X-Original-To: w3c-dist-auth@w3.org Subject: RE: rfc2518bis-14: locking terminology X-Archived-At: http://www.w3.org/mid/NSNOVPS00411Ay0BYTx00000e50@NSNOVPS00411.nacio.xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12231 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 16:06:35 +0000 X-Spam-Score: 1.9 (+) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Comments, in-line... -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Manfred Baedke Sent: Wednesday, March 15, 2006 2:49 PM To: w3c-dist-auth@w3.org Subject: rfc2518bis-14: locking terminology Hi, While the new lock model, as presented in section 6.1, seems appropriate to define the terminology needed to deal with locking, I think that the spec should try to avoid falling back to language that is not covered by section 6.1: - Section 6.9: > A resource may be made available through more than one URI. A lock > MUST cover the resource as well as the URI to which the LOCK request > was addressed. The lock MAY cover other URIs mapped to the same > resource as well. It is undefined what it means for a lock to cover an URI. As far as I can tell, this section can be dropped without doing harm. [John] I agree, this section should be dropped; in fact, all references to bindings should be removed from this spec. - From section 7.3: > WebDAV provides the ability to lock an unmapped URL in order to > reserve the name for use. Since it is undefined what it means to lock an URI, I would rephrase this: 'WebDAV provides the ability to create a lock by submitting a LOCK request to an unmapped URL.' [John] Agree; this simplifies the wording. - From section 7.4: > A "Depth 0" write lock on a collection protects the collection metadata... It is undefined what it means for a lock to protect anything. A lock locks resources as defined by section 6.1. That's it. [John] I do not agree with this. It's important to clearly state what the lock behavior is on a collection. This section is reiterating the collection behavior outlined in the opening paragraphs of section 7. (point 2), and clarifies the distinction between depth 0 and depth infinity locks. I think this section is important, and needs to remain as is. > With a depth-infinity lock, the root of the lock is directly locked No, since the root of the lock is an URI. [John] If the root of a lock is a collection, it's important to make clear that that collection is locked, along with all it's decendents. I think this statement should stay (but perhaps reworded to be more precise). > Any indirectly locked resource moved out of a locked source collection > into a depth-infinity locked target collection remains indirectly > locked but is now within the scope of the lock on the target > collection (the target collection's lock token will thereafter be > required to make further changes). The term 'lock scope' is undefined yet. Why not simply say that the resource is locked? [John] The point is that you need to now use the lock token of the target collection to perform subsequent operations (that require a lock token). Yes 'scope' is undefined, but is useful in describing the parent lock by which the resource is now indirectly locked. Perhaps 'scope' should be defined earlier in the section (7.4). > If a lock request causes the URL of a resource to be added as an > internal member URL of a depth-infinity locked collection then the new > resource MUST be automatically added to the lock. This is the only > mechanism that allows a resource to be added to a write lock. Thus, > for example, if the collection /a/b/ is write locked and the resource > /c is moved to /a/b/c then resource /a/b/c will be added to the write > lock. It is undefined yet what it means for a resource to be added to a lock. I think the resource is simply locked. [John] within the 'scope' of the lock target :) This paragraph does seem redundant with the bullet point above it. The point here, again, being that the resource is now iderectly locked, by virtue of the lock on the target parent, and thus a different lock token must be used to perform subsequent operations. - From section 7.6: > A COPY method invocation MUST NOT duplicate any write locks active on > the source. Lock duplication is undefined. [John] Here, simply state that LOCKs are not copied, as, say dead properties would be. > A successful MOVE request on a write locked resource MUST NOT move the > write lock with the resource. Moving a lock is undefined. [John] I think it's important to state this here, otherwise you might think the LOCK is moved with the resource. Simply state that LOCKs are not moved with a resource, as, say dead properties would be. - From section 9.11: > For a successful response to this method, the server MUST remove the > lock from the resource identified by the Request-URI and from all > other resources included in the lock. Removing a lock from a resource (or from anything else) is undefined. The lock is deleted. That's it. [John] Agreed Some of the undefined phrases mentioned above appear more than once in the text. In these cases, I have quoted only the first appearance. Furthermore, I think that section 7 could be made significantly clearer (and shorter) if it concentrated on the general fact that the state of a write locked resource MUST not be modified by a request that does not supply the locktoken or was not issued by the lock creator, rather than listing lots of special cases that follow directly from this rule (together with section 6.1, of course). For example, the sections 7.4 and 7.6 could be dropped completely, as far as I can see. Also, I would prefer to drop all text that might raise the idea that there is something special about empty resources. IMHO, they are not more remarkable than resources with content length 42. (Well, even less, for those who know the magic of the number 42 :)) Finally, as I already stated in a previous mail, I would prefer the text concerning lock-null resources to be moved to an appendix. Regards, Manfred From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 11:36:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvSk-00037e-U6 for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 11:36:34 -0500 Received: from frink.w3.org ([128.30.52.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJvSk-00083c-FT for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 11:36:34 -0500 Received: from lists by frink.w3.org with local (Exim 4.50) id 1FJvSN-00058s-Ku for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 16:36:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1FJvSC-00057V-IP for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 16:36:00 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1FJvS3-0003Cj-32 for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 16:35:59 +0000 Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id EC059498F9; Thu, 16 Mar 2006 17:35:47 +0100 (CET) Message-ID: <441993E3.8080201@greenbytes.de> Date: Thu, 16 Mar 2006 17:35:47 +0100 From: Manfred Baedke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Barone CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1FJvS3-0003Cj-32 f24c5088fc775a5e2814e03cdeb1d78e X-Original-To: w3c-dist-auth@w3.org Subject: Re: rfc2518bis-14: locking terminology X-Archived-At: http://www.w3.org/mid/441993E3.8080201@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/12232 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: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 16 Mar 2006 16:36:11 +0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 850245b51c39701e2700a112f3032caa John Barone wrote: 
Comments, in-line... 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 2:49 PM
To: w3c-dist-auth@w3.org
Subject: rfc2518bis-14: locking terminology


Hi,

While the new lock model, as presented in section 6.1, seems appropriate to
define the terminology needed to deal with locking, I think that the spec
should try to avoid falling back to language that is not covered by section
6.1:

- Section 6.9:
  
A resource may be made available through more than one URI. A lock 
MUST cover the resource as well as the URI to which the LOCK request 
was addressed. The lock MAY cover other URIs mapped to the same 
resource as well.
    
It is undefined what it means for a lock to cover an URI. As far as I can
tell, this section can be dropped without doing harm.

[John] I agree, this section should be dropped; in fact, all references to
bindings should be removed from this spec.


- From section 7.3:
  
WebDAV provides the ability to lock an unmapped URL in order to 
reserve the name for use.
    
Since it is undefined what it means to lock an URI, I would rephrase
this: 'WebDAV provides the ability to create a lock by submitting a LOCK
request to an unmapped URL.'

[John] Agree; this simplifies the wording.


- From section 7.4:
  
A "Depth 0" write lock on a collection protects the collection metadata...
    
It is undefined what it means for a lock to protect anything. A lock locks
resources as defined by section 6.1. That's it.

[John] I do not agree with this.  It's important to clearly state what the
lock behavior is on a collection.  This section is reiterating the
collection behavior outlined in the opening paragraphs of section 7. (point
2), and clarifies the distinction between depth 0 and depth infinity locks.
I think this section is important, and needs to remain as is.

My main point here is the use of undefined terminology, though I indeed think that section 6.1 will be perfectly clear on the distinction between a depth 0 and a depth infinity lock as soon as 6.1.4 uses the term 'member' instead of 'internal member'. 7.4 contains nothing new, and a list of special cases can never be as concise as the general principle itself. 


  

    
With a depth-infinity lock, the root of the lock is directly locked
    

  

  
No, since the root of the lock is an URI.

[John] If the root of a lock is a collection, it's important to make clear
that that collection is locked, along with all it's decendents.  I think
this statement should stay (but perhaps reworded to be more precise).

  





My point here is that URIs cannot be locked. Resources can be locked,
but the root of the lock is not a resource.





  
  

  

    
Any indirectly locked resource moved out of a locked source collection 
into a depth-infinity locked target collection remains indirectly 
locked but is now within the scope of the lock on the target 
collection (the target collection's lock token will thereafter be 
required to make further changes).
    

  

  
The term 'lock scope' is undefined yet. Why not simply say that the resource
is locked?

[John] The point is that you need to now use the lock token of the target
collection to perform subsequent operations (that require a lock token).
Yes 'scope' is undefined, but is useful in describing the parent lock by
which the resource is now indirectly locked.  Perhaps 'scope' should be
defined earlier in the section (7.4).
  





If the term lock scope was defined, section 6.1 would be the right
place IMHO. But since we already have the lockscope element (which is
something completely different), this would be very confusing. One can
always replace the wording "resource x is in the scope of lock y" with
"resource x is locked by lock y".





  

  

    
If a lock request causes the URL of a resource to be added as an 
internal member URL of a depth-infinity locked collection then the new 
resource MUST be automatically added to the lock. This is the only 
mechanism that allows a resource to be added to a write lock. Thus, 
for example, if the collection /a/b/ is write locked and the resource 
/c is moved to /a/b/c then resource /a/b/c will be added to the write 
lock.
    

  

  
It is undefined yet what it means for a resource to be added to a lock.
I think the resource is simply locked.

[John] within the 'scope' of the lock target :)   This paragraph does seem
redundant with the bullet point above it.  The point here, again, being that
the resource is now iderectly locked, by virtue of the lock on the target
parent, and thus a different lock token must be used to perform subsequent
operations.


- From section 7.6:
  

  

    
A COPY method invocation MUST NOT duplicate any write locks active on 
the source.
    

  

  
Lock duplication is undefined.

[John] Here, simply state that LOCKs are not copied, as, say dead properties
would be.
  





Well, copying locks is as undefined as lock duplication.





  

  

    
A successful MOVE request on a write locked resource MUST NOT move the 
write lock with the resource.
    

  

  
Moving a lock is undefined.

[John] I think it's important to state this here, otherwise you might think
the LOCK is moved with the resource.  Simply state that LOCKs are not moved
with a resource, as, say dead properties would be.
  





How could one think that a lock could be moved if it is not defined
what this could mean?





  

- From section 9.11:
  

  

    
For a successful response to this method, the server MUST remove the 
lock from the resource identified by the Request-URI and from all 
other resources included in the lock.
    

  

  
Removing a lock from a resource (or from anything else) is undefined.
The lock is deleted. That's it.

[John] Agreed



Some of the undefined phrases mentioned above appear more than once in the
text. In these cases, I have quoted only the first appearance.

Furthermore, I think that section 7 could be made significantly clearer (and
shorter) if it concentrated on the general fact that the state of a write
locked resource MUST not be modified by a request that does not supply the
locktoken or was not issued by the lock creator, rather than listing lots of
special cases that follow directly from this rule (together with section
6.1, of course). For example, the sections 7.4 and 7.6 could be dropped
completely, as far as I can see.

Also, I would prefer to drop all text that might raise the idea that there
is something special about empty resources. IMHO, they are not more
remarkable than resources with content length 42. (Well, even less, for
those who know the magic of the number 42 :))

Finally, as I already stated in a previous mail, I would prefer the text
concerning lock-null resources to be moved to an appendix.

Regards,
Manfred











  









From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 12:22:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJwAu-0000vW-Ek
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 12:22:12 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJwAt-0001cZ-Jc
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 12:22:12 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FJwA2-0000iu-By
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 17:21:18 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FJw9u-0000iD-KV
	for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 17:21:10 +0000
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FJw9l-0006Ag-TG
	for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 17:21:10 +0000
Received: from jbaroned600 ([69.107.70.231]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 16 Mar 2006 09:20:57 -0800
From: "John Barone" 
To: "'Manfred Baedke'" 
Cc: 
Date: Thu, 16 Mar 2006 09:21:01 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C648DA.F1644AB0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <441993E3.8080201@greenbytes.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcZJF6/ZsVST3pFyRt+KYP0bc7L7iAABDh3w
Message-ID: 
X-OriginalArrivalTime: 16 Mar 2006 17:20:57.0885 (UTC) FILETIME=[FD47ACD0:01C6491D]
Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FJw9l-0006Ag-TG 5fa17df4fbfdd9b430d898f548ba423a
X-Original-To: w3c-dist-auth@w3.org
Subject: RE: rfc2518bis-14: locking terminology
X-Archived-At: http://www.w3.org/mid/NSNOVPS00411J9Svkjj00000e64@NSNOVPS00411.nacio.xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12233
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 16 Mar 2006 17:21:18 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: a852d3320f01cddd04b35de85a7fe713


This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C648DA.F1644AB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

"My main point here is the use of undefined terminology, though I indeed
think that section 6.1 will be perfectly clear on the distinction between a
depth 0 and a depth infinity lock as soon as 6.1.4 uses the term 'member'
instead of 'internal member'. 7.4 contains nothing new, and a list of
special cases can never be as concise as the general principle itself. "
 
[John] OK, I can see that; however section 6.1.4 does not make the
distinction between depth 0 and depth infinity locks.  This section needs to
be cleaned up to make that distinction, and spell out the exact bahavior in
both cases.  Maybe combining what's in section 7. bullet 2 and what's
currently in section 6.1.4.
 
 
 
[John] If the root of a lock is a collection, it's important to make clear
that that collection is locked, along with all it's decendents.  I think
this statement should stay (but perhaps reworded to be more precise).
  
My point here is that URIs cannot be locked. Resources can be locked, but
the root of the lock is not a resource.

 
[John] If the target URI for a depth infinity lock request is a collection,
the collection IS most certainly locked.  But to your point, if the language
in section 6.1.x is cleaned up, this entire section can be removed.
 
 
Move/Copy behavior...
 
Well, copying locks is as undefined as lock duplication
  
How could one think that a lock could be moved if it is not defined what
this could mean?
 
... by the same token, what does it mean to duplicate or move live or dead
properties; those operations aren't defined either for properties, and yet
you MUST/SHOULD do it.  I don't see the harm here, in fact I think it's a
very good idea to explicitly state this in the spec. to remove ambiguity.  I
think the copy/move MUST NOT statements should be kept either in a 7.x
section, or wrapped into a revised 6.1.4 section.
 
-John


 
 



  _____  

From: Manfred Baedke [mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March 16, 2006 8:36 AM
To: John Barone
Cc: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology


John Barone wrote: 

Comments, in-line... 



-----Original Message-----

From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On

Behalf Of Manfred Baedke

Sent: Wednesday, March 15, 2006 2:49 PM

To: w3c-dist-auth@w3.org

Subject: rfc2518bis-14: locking terminology





Hi,



While the new lock model, as presented in section 6.1, seems appropriate to

define the terminology needed to deal with locking, I think that the spec

should try to avoid falling back to language that is not covered by section

6.1:



- Section 6.9:

  

A resource may be made available through more than one URI. A lock 

MUST cover the resource as well as the URI to which the LOCK request 

was addressed. The lock MAY cover other URIs mapped to the same 

resource as well.

    

It is undefined what it means for a lock to cover an URI. As far as I can

tell, this section can be dropped without doing harm.



[John] I agree, this section should be dropped; in fact, all references to

bindings should be removed from this spec.





- From section 7.3:

  

WebDAV provides the ability to lock an unmapped URL in order to 

reserve the name for use.

    

Since it is undefined what it means to lock an URI, I would rephrase

this: 'WebDAV provides the ability to create a lock by submitting a LOCK

request to an unmapped URL.'



[John] Agree; this simplifies the wording.





- From section 7.4:

  

A "Depth 0" write lock on a collection protects the collection metadata...

    

It is undefined what it means for a lock to protect anything. A lock locks

resources as defined by section 6.1. That's it.



[John] I do not agree with this.  It's important to clearly state what the

lock behavior is on a collection.  This section is reiterating the

collection behavior outlined in the opening paragraphs of section 7. (point

2), and clarifies the distinction between depth 0 and depth infinity locks.

I think this section is important, and needs to remain as is. 

  


My main point here is the use of undefined terminology, though I indeed
think that section 6.1 will be perfectly clear on the distinction between a
depth 0 and a depth infinity lock as soon as 6.1.4 uses the term 'member'
instead of 'internal member'. 7.4 contains nothing new, and a list of
special cases can never be as concise as the general principle itself. 





With a depth-infinity lock, the root of the lock is directly locked

    

No, since the root of the lock is an URI.



[John] If the root of a lock is a collection, it's important to make clear

that that collection is locked, along with all it's decendents.  I think

this statement should stay (but perhaps reworded to be more precise).



  


My point here is that URIs cannot be locked. Resources can be locked, but
the root of the lock is not a resource.



  

Any indirectly locked resource moved out of a locked source collection 

into a depth-infinity locked target collection remains indirectly 

locked but is now within the scope of the lock on the target 

collection (the target collection's lock token will thereafter be 

required to make further changes).

    

The term 'lock scope' is undefined yet. Why not simply say that the resource

is locked?



[John] The point is that you need to now use the lock token of the target

collection to perform subsequent operations (that require a lock token).

Yes 'scope' is undefined, but is useful in describing the parent lock by

which the resource is now indirectly locked.  Perhaps 'scope' should be

defined earlier in the section (7.4).

  


If the term lock scope was defined, section 6.1 would be the right place
IMHO. But since we already have the lockscope element (which is something
completely different), this would be very confusing. One can always replace
the wording "resource x is in the scope of lock y" with "resource x is
locked by lock y".





If a lock request causes the URL of a resource to be added as an 

internal member URL of a depth-infinity locked collection then the new 

resource MUST be automatically added to the lock. This is the only 

mechanism that allows a resource to be added to a write lock. Thus, 

for example, if the collection /a/b/ is write locked and the resource 

/c is moved to /a/b/c then resource /a/b/c will be added to the write 

lock.

    

It is undefined yet what it means for a resource to be added to a lock.

I think the resource is simply locked.



[John] within the 'scope' of the lock target :)   This paragraph does seem

redundant with the bullet point above it.  The point here, again, being that

the resource is now iderectly locked, by virtue of the lock on the target

parent, and thus a different lock token must be used to perform subsequent

operations.





- From section 7.6:

  

A COPY method invocation MUST NOT duplicate any write locks active on 

the source.

    

Lock duplication is undefined.



[John] Here, simply state that LOCKs are not copied, as, say dead properties

would be.

  


Well, copying locks is as undefined as lock duplication.





A successful MOVE request on a write locked resource MUST NOT move the 

write lock with the resource.

    

Moving a lock is undefined.



[John] I think it's important to state this here, otherwise you might think

the LOCK is moved with the resource.  Simply state that LOCKs are not moved

with a resource, as, say dead properties would be.

  


How could one think that a lock could be moved if it is not defined what
this could mean?





- From section 9.11:

  

For a successful response to this method, the server MUST remove the 

lock from the resource identified by the Request-URI and from all 

other resources included in the lock.

    

Removing a lock from a resource (or from anything else) is undefined.

The lock is deleted. That's it.



[John] Agreed







Some of the undefined phrases mentioned above appear more than once in the

text. In these cases, I have quoted only the first appearance.



Furthermore, I think that section 7 could be made significantly clearer (and

shorter) if it concentrated on the general fact that the state of a write

locked resource MUST not be modified by a request that does not supply the

locktoken or was not issued by the lock creator, rather than listing lots of

special cases that follow directly from this rule (together with section

6.1, of course). For example, the sections 7.4 and 7.6 could be dropped

completely, as far as I can see.



Also, I would prefer to drop all text that might raise the idea that there

is something special about empty resources. IMHO, they are not more

remarkable than resources with content length 42. (Well, even less, for

those who know the magic of the number 42 :))



Finally, as I already stated in a previous mail, I would prefer the text

concerning lock-null resources to be moved to an appendix.



Regards,

Manfred























  


------=_NextPart_000_000E_01C648DA.F1644AB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable








 


[John] OK, I can see =
that; however=20
section 6.1.4 does not make the distinction between depth 0 and depth =
infinity=20
locks.  This section needs to be cleaned up to make that =
distinction, and=20
spell out the exact bahavior in both cases.  Maybe combining what's =
in=20
section 7. bullet 2 and what's currently in section=20
6.1.4.


 


 


 


[John] If the root of a lock is a=20
collection, it's important to make clear
that that collection is =
locked,=20
along with all it's decendents.  I think
this statement should =
stay (but=20
perhaps reworded to be more precise).
  
My point here is =
that URIs=20
cannot be locked. Resources can be locked, but the root of the lock is =
not a=20
resource.


 


[John]=20
If the target URI for a depth infinity lock request is a collection, the =

collection IS most certainly locked.  But to your point, if the =
language in=20
section 6.1.x is cleaned up, this entire section can be=20
removed.


 


 


Move/Copy behavior...


 


Well, copying locks is as =
undefined as lock=20
duplication


  
How could one think =
that a lock=20
could be moved if it is not defined what this could mean?


 


... by=20
the same token, what does it mean to duplicate or move live or =
dead=20
properties; those operations aren't defined either for properties, and =
yet you=20
MUST/SHOULD do it.  I don't see the harm here, in fact I think it's =
a very=20
good idea to explicitly state this in the spec. to remove =
ambiguity.  I=20
think the copy/move MUST NOT statements should be kept either in a 7.x =
section,=20
or wrapped into a revised 6.1.4 section.


 


-John





 


 









From: Manfred Baedke=20
[mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March =
16, 2006=20
8:36 AM
To: John Barone
Cc:=20
w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking=20
terminology



John Barone wrote:=20

Comments, in-line...=20

-----Original Message-----
From: w3c-dist-auth-request@w3.org=
 [mailto:w3c-dist-auth-request=
@w3.org] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 2:49 PM
To: w3c-dist-auth@w3.org
Subject: rfc2518bis-14: locking terminology


Hi,

While the new lock model, as presented in section 6.1, seems appropriate =
to
define the terminology needed to deal with locking, I think that the =
spec
should try to avoid falling back to language that is not covered by =
section
6.1:

- Section 6.9:
  

  
A resource may be made =
available through more than one URI. A lock=20
MUST cover the resource as well as the URI to which the LOCK request=20
was addressed. The lock MAY cover other URIs mapped to the same=20
resource as well.
    
It is undefined what it =
means for a lock to cover an URI. As far as I can
tell, this section can be dropped without doing harm.

[John] I agree, this section should be dropped; in fact, all references =
to
bindings should be removed from this spec.


- From section 7.3:
  

  
WebDAV provides the ability =
to lock an unmapped URL in order to=20
reserve the name for use.
    
Since it is undefined what =
it means to lock an URI, I would rephrase
this: 'WebDAV provides the ability to create a lock by submitting a LOCK
request to an unmapped URL.'

[John] Agree; this simplifies the wording.


- From section 7.4:
  

  
A "Depth 0" write lock on a =
collection protects the collection metadata...
    
It is undefined what it =
means for a lock to protect anything. A lock locks
resources as defined by section 6.1. That's it.

[John] I do not agree with this.  It's important to clearly state what =
the
lock behavior is on a collection.  This section is reiterating the
collection behavior outlined in the opening paragraphs of section 7. =
(point
2), and clarifies the distinction between depth 0 and depth infinity =
locks.
I think this section is important, and needs to remain as is.=20
  

My main point here is the use of undefined =
terminology,=20
though I indeed think that section 6.1 will be perfectly clear on the=20
distinction between a depth 0 and a depth infinity lock as soon as 6.1.4 =
uses=20
the term 'member' instead of 'internal member'. 7.4 contains nothing =
new, and a=20
list of special cases can never be as concise as the general principle =
itself.=20





  
With a depth-infinity lock, =
the root of the lock is directly locked
    
No, since the root of the =
lock is an URI.

[John] If the root of a lock is a collection, it's important to make =
clear
that that collection is locked, along with all it's decendents.  I think
this statement should stay (but perhaps reworded to be more precise).

  

My point here is that URIs cannot be locked. =
Resources=20
can be locked, but the root of the lock is not a resource.



  

  
Any indirectly locked =
resource moved out of a locked source collection=20
into a depth-infinity locked target collection remains indirectly=20
locked but is now within the scope of the lock on the target=20
collection (the target collection's lock token will thereafter be=20
required to make further changes).
    
The term 'lock scope' is =
undefined yet. Why not simply say that the resource
is locked?

[John] The point is that you need to now use the lock token of the =
target
collection to perform subsequent operations (that require a lock token).
Yes 'scope' is undefined, but is useful in describing the parent lock by
which the resource is now indirectly locked.  Perhaps 'scope' should be
defined earlier in the section (7.4).
  

If the term lock scope was defined, section 6.1 =
would=20
be the right place IMHO. But since we already have the lockscope element =
(which=20
is something completely different), this would be very confusing. One =
can always=20
replace the wording "resource x is in the scope of lock y" with =
"resource x is=20
locked by lock y".




  
If a lock request causes the =
URL of a resource to be added as an=20
internal member URL of a depth-infinity locked collection then the new=20
resource MUST be automatically added to the lock. This is the only=20
mechanism that allows a resource to be added to a write lock. Thus,=20
for example, if the collection /a/b/ is write locked and the resource=20
/c is moved to /a/b/c then resource /a/b/c will be added to the write=20
lock.
    
It is undefined yet what it =
means for a resource to be added to a lock.
I think the resource is simply locked.

[John] within the 'scope' of the lock target :)   This paragraph does =
seem
redundant with the bullet point above it.  The point here, again, being =
that
the resource is now iderectly locked, by virtue of the lock on the =
target
parent, and thus a different lock token must be used to perform =
subsequent
operations.


- From section 7.6:
  

  
A COPY method invocation MUST =
NOT duplicate any write locks active on=20
the source.
    
Lock duplication is =
undefined.

[John] Here, simply state that LOCKs are not copied, as, say dead =
properties
would be.
  

Well, copying locks is as undefined as lock=20
duplication.




  
A successful MOVE request on =
a write locked resource MUST NOT move the=20
write lock with the resource.
    
Moving a lock is undefined.

[John] I think it's important to state this here, otherwise you might =
think
the LOCK is moved with the resource.  Simply state that LOCKs are not =
moved
with a resource, as, say dead properties would be.
  

How could one think that a lock could be moved =
if it is=20
not defined what this could mean?



- From section 9.11:
  

  
For a successful response to =
this method, the server MUST remove the=20
lock from the resource identified by the Request-URI and from all=20
other resources included in the lock.
    
Removing a lock from a =
resource (or from anything else) is undefined.
The lock is deleted. That's it.

[John] Agreed



Some of the undefined phrases mentioned above appear more than once in =
the
text. In these cases, I have quoted only the first appearance.

Furthermore, I think that section 7 could be made significantly clearer =
(and
shorter) if it concentrated on the general fact that the state of a =
write
locked resource MUST not be modified by a request that does not supply =
the
locktoken or was not issued by the lock creator, rather than listing =
lots of
special cases that follow directly from this rule (together with section
6.1, of course). For example, the sections 7.4 and 7.6 could be dropped
completely, as far as I can see.

Also, I would prefer to drop all text that might raise the idea that =
there
is something special about empty resources. IMHO, they are not more
remarkable than resources with content length 42. (Well, even less, for
those who know the magic of the number 42 :))

Finally, as I already stated in a previous mail, I would prefer the text
concerning lock-null resources to be moved to an appendix.

Regards,
Manfred











  


------=_NextPart_000_000E_01C648DA.F1644AB0--





From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 12:35:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJwNs-0000sy-UK
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 12:35:36 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJwNs-0001xw-HC
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 12:35:36 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FJwNR-00057Y-DF
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 17:35:09 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FJwN8-0004hP-Hy
	for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 17:34:50 +0000
Received: from asia.telenet-ops.be ([195.130.137.74])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FJwMx-00077o-Vh
	for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 17:34:49 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by asia.telenet-ops.be (Postfix) with SMTP
	id 729CE16829B; Thu, 16 Mar 2006 18:34:39 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by asia.telenet-ops.be (Postfix) with ESMTP
	id 8184916830E; Thu, 16 Mar 2006 18:34:38 +0100 (CET)
Message-ID: <4419A1B5.3080306@re.be>
Date: Thu, 16 Mar 2006 18:34:45 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm 
Cc: w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (maggie.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FJwMx-00077o-Vh 13a42c3aaed42ba645c399a9bb99710d
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/4419A1B5.3080306@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12234
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 16 Mar 2006 17:35:09 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7


Geoffrey M Clemm wrote:
>=20
> Werner Donn=E9  wrote on 03/16/2006 08:01:57 AM:
>=20
>> Geoffrey M Clemm wrote:
>> >
>> > (1) Why does this scenario have to be in one transaction?  In
> particular,
>> > why isn't it sufficient just to wrap the sequence of operations in
>> > a LOCK/UNLOCK? =20
>>
>> Because anything in between can go wrong, leaving the system in an
>> inconsistent state. It can't be the responsibility of the client to
>> keep the state consistent. That is a co-operative and hence unreliable
>> design.
>=20
> The only thing that can go wrong is that the client neglects to perform
> an UNLOCK, which is why there are timeout and administrative override
> mechanisms
> in the locking protocol.  But I agree that many clients would rather no=
t
> deal with locks, which is why we introduced the workspace feature.  So =
lets
> focus on whether or not the workspace feature provides what you need.

Between each step in the sequence the dialogue can be interrupted. Not on=
ly
would the lock not be released, but the checked-in version of the VCR cou=
ld
also be on another version than it was originally. This is an unexpected
global state change for all clients, which is not acceptable in a concurr=
ent
system.

Regarding the lock release the timeout mechanism is not good enough if
locking is used like that, because VCR is blocked too long. This impacts
concurrency severely. When a transaction fails, for example, everything
is rolled back and release immediately.

Again, I'm not discussing what I need. I'm not a user.

>=20
>> > (2) I agree that the locking mechanism is not designed to implement
>> > transactional isolation.  That is what workspaces and working resour=
ces
>> > are designed for.  If (for unexplained reasons :-) you don't want to
>> > use the versioning features that were designed for transactional
>> > isolation, it should come as no surprise that you have difficulty
>> > achieving transactional isolation.  Some clients don't want/need
>> > transactional isolation (they just want history to be kept, for
> example),
>> > which is why workspaces and working resources are optional features
>> > (we define these two different ways of achieving transactional isola=
tion
>> > because some repositories can only support one, while other reposito=
ries
>> > can only support the other, and we could find no way of unifying the=
se
>> > two different ways under a single feature).
>>
>> This is obviously not at all about what I want or don't want to use.
>> I'm reasoning about the WebDAV model. I haven't said I was against
> workspaces.
>=20
> Well, to be honest, it is not at all clear to me what you do or do not
> want to do (:-).  The purpose of the WebDAV model is provide a uniform
> protocol for accessing the various authoring features provided by
> a wide variety of repositories.  So the interesting questions are
> "how do I as a client use the protocol to achieve this interesting
> use case for a user" and "how do I as a repository use the protocol
> to expose this particular feature of my repository to a client".
> Without one of those questions in hand, one cannot have a productive
> discussion about the WebDAV model.

I'm assessing the model, because I want to implement it. It is important
that a model is consistent and stable, otherwise its implementation will
be expensive. In my opinion exposing forking is not consistent. It is not
because there is another feature that does the trick, that a particular
feature shouldn't be scrutinised.

Inconsistent parts in a model have a life of their own and can have an
impact on other areas of the model during evolution, just for the sake
of compatibility.

>=20
>> > As for the why support forking, it is an (undesireable, but inevitab=
le)
>> > side-effect of parallel development.  So we don't define it as an
>> > independent feature, but we "deal with it" for those features that
>> > support parallel development (i.e., workspaces and working resources=
).
>> > In particular, it is what tells you that parallel development has
>> > occurred on a particular resource, and that therefore a merge is
>> > required (the need for a merge when forking occurs is why it is
>> > "undesireable").
>> >
>> > So creating forks in a non-parallel development context makes no
> sense ...
>> > you are just making trouble for yourself.  Which is why forking only
>> > occurs as a side effect of parallel development, and not as a
> feature that
>> > you explicitly invoke.
>>
>> Which is what I reckoned and it is an encapsulation flaw. Clearly, for=
king
>> on its own is useless, but it is exposed through the WebDAV interface =
with
>> elements such as "checkin-fork", "checkout-fork", "fork-ok". There is =
no
>> reason for this, nor for the UPDATE method to be allowed to change the
>> checked-in version, which is the source of the problem.
>=20
> The way WebDAV (and HTTP) achieves interoperability is by having a clie=
nt
> use a single uniform protocol against a wide variety of servers.  So th=
e
> client always uses the UPDATE method to "restore" a version from histor=
y,
> whether it is working with a server that supports working resources,
> supports
> workspaces, supports both, or supports neither.  Changing the checked-i=
n
> version is important when the server supports either workspaces or
> working resources, so you have clients uniformly use the UPDATE method.
> This means that a client is aware of checkin-fork, checkout-fork, and
> fork-ok behavior, so that in behaves properly when it is applied to a
> server that supports either workspaces or working resources.

It strikes me that workspaces don't expose forking, while working resourc=
es
do. Workspaces prove it is perfectly possible to offer branching and merg=
ing
without exposing an implementation artifact such as forking. Note that th=
ey
also make it possible to work transactionally within the repository witho=
ut
exposing transaction demarcation.

Workspaces are well designed, while working resources are not. Their diff=
erence
should only about configurations, not in the way they offer branching. Th=
at
should be exactly the same. The two things are orthogonal.

>=20
>> Creating a new
>> VCR in a workspace from a given version obviously requires forking, bu=
t
>> that is merely an internal implementation matter.
>=20
> No, it's part of the explicit user model, because when you invoke the M=
ERGE
> method, the result of the MERGE method is affected by whether or not
> there has
> been any branching, so the client needs to understand when a branch wil=
l
> occur,
> and when it won't. =20

Merging and branching go together and you can do it with VCRs only. So th=
ere
is no reason to offer another user model for branching than that of works=
paces.
Working resources should be made compatible with it.

>=20
> Cheers,
> Geoff
> =20
>=20
>=20

Regards,

Werner.
--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 13:25:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxAa-0007dE-0Q
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 13:25:56 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxAZ-0003Bu-Le
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 13:25:55 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FJx9f-0003z8-Tm
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 18:24:59 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FJx9U-0003xj-Qz
	for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 18:24:48 +0000
Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FJx9S-0002gm-0n
	for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 18:24:48 +0000
Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 66ECC2EA39;
	Thu, 16 Mar 2006 19:24:44 +0100 (CET)
Message-ID: <4419AD6E.3070606@greenbytes.de>
Date: Thu, 16 Mar 2006 19:24:46 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: John Barone 
CC:  w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: lisa.w3.org 1FJx9S-0002gm-0n cef3a0eceb1212a7bab422b9a335d872
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology
X-Archived-At: http://www.w3.org/mid/4419AD6E.3070606@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12235
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 16 Mar 2006 18:24:59 +0000
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5





  
  


John Barone wrote:


  
  
  
"My main point here is the use of undefined
terminology, though I indeed think that section 6.1 will be perfectly
clear on the distinction between a depth 0 and a depth infinity lock as
soon as 6.1.4 uses the term 'member' instead of 'internal member'. 7.4
contains nothing new, and a list of special cases can never be as
concise as the general principle itself. "

  
 

  
[John] OK, I can see
that; however section 6.1.4 does not make the distinction between depth
0 and depth infinity locks.  This section needs to be cleaned up to
make that distinction, and spell out the exact bahavior in both cases. 
Maybe combining what's in section 7. bullet 2 and what's currently in
section 6.1.4.

  
 

  



Agreed that section 6.1 should define lock depth.



  
 

  
 

  
[John] If the root of a lock is
a collection, it's important to make clear

that that collection is locked, along with all it's decendents.  I think

this statement should stay (but perhaps reworded to be more precise).

  

My point here is that URIs cannot be locked. Resources can be locked,
but the root of the lock is not a resource.

  

  
 

  
[John] If the target URI for a depth infinity
lock request is a collection, the collection IS most certainly locked. 
But to your point, if the language in section 6.1.x is cleaned up, this
entire section can be removed.

  
 

  



The target URI of a lock request will never be a collection, but the
URI of a collection. An URI is an URI and a resource is a resource. As
defined in 6.1, resources can be locked. URIs can't.



  
 

  
Move/Copy behavior...

  
 

  
Well, copying locks is as
undefined as lock duplication

  
  

How could one think that a lock could be moved if it is not defined
what this could mean?

  
 

  
... by the same token, what does it mean
to duplicate or move live or dead properties; those operations aren't
defined either for properties, and yet you MUST/SHOULD do it.  I don't
see the harm here, in fact I think it's a very good idea to explicitly
state this in the spec. to remove ambiguity.  I think the copy/move
MUST NOT statements should be kept either in a 7.x section, or wrapped
into a revised 6.1.4 section.

  



Well, if the spec does not define what it means to move a property,
then it should either correct this or stop to use this terminology.



Section 6.1 defines what a lock is. This is done by giving a set of
"axioms", propositions using the term 'lock' which are true by
convention. It should be possible to read the spec without the
slightest idea what a lock could be. Let us assume that we have no such
idea and read section 6.1. Then we have an understanding of what a lock
is, but we would be very surprised if someone spoke of 'moving locks'.
We would say something like: "Hey, wait, how can you move it if it does
not even have a location?".



If one thinks that it makes sense to move a lock, he simply has an
understanding of the term 'lock' that does not match the definitions in
this specification. If the specification never mentioned 'moving
locks', why would any reader think that this term even had a meaning?



Regards,

Manfred









From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 14:17:37 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJxyb-0002UR-2a
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 14:17:37 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJxya-0005Rg-Jq
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 14:17:37 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FJxy9-0001gA-DQ
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 19:17:09 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FJxxx-0001cB-79
	for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 19:16:57 +0000
Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FJxxu-0004uR-2E
	for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 19:16:57 +0000
Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 666432E95A;
	Thu, 16 Mar 2006 20:16:52 +0100 (CET)
Message-ID: <4419B9A7.4080205@greenbytes.de>
Date: Thu, 16 Mar 2006 20:16:55 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To:  werner.donne@re.be
CC:  w3c-dist-auth@w3.org,  geoffrey.clemm@us.ibm.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FJxxu-0004uR-2E 77a8607e538309b554abcd1480e7e843
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/4419B9A7.4080205@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12236
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 16 Mar 2006 19:17:09 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f


Hi Werner,

comments inline:

>> Werner Donn=E9  wrote on 03/16/2006 08:01:57 AM:
>>=20
>>> Geoffrey M Clemm wrote:
>>> >
>>> > (1) Why does this scenario have to be in one transaction?  In
>> particular,
>>> > why isn't it sufficient just to wrap the sequence of operations in
>>> > a LOCK/UNLOCK? =20
>>>
>>> Because anything in between can go wrong, leaving the system in an
>>> inconsistent state. It can't be the responsibility of the client to
>>> keep the state consistent. That is a co-operative and hence unreliabl=
e
>>> design.
>>=20
>> The only thing that can go wrong is that the client neglects to perfor=
m
>> an UNLOCK, which is why there are timeout and administrative override
>> mechanisms
>> in the locking protocol.  But I agree that many clients would rather n=
ot
>> deal with locks, which is why we introduced the workspace feature.  So=
 lets
>> focus on whether or not the workspace feature provides what you need.
>=20
> Between each step in the sequence the dialogue can be interrupted. Not =
only
> would the lock not be released, but the checked-in version of the VCR c=
ould
> also be on another version than it was originally. This is an unexpecte=
d
> global state change for all clients, which is not acceptable in a concu=
rrent
> system.
>=20

So the checked-in version of the VCR changed. Every client (at least=20
those who do not hold a lock) must be aware of this possibility at any=20
time. Why should this be unexpected?

> Regarding the lock release the timeout mechanism is not good enough if
> locking is used like that, because VCR is blocked too long. This impact=
s
> concurrency severely. When a transaction fails, for example, everything
> is rolled back and release immediately.
>=20

Yes, long lasting exclusive locks are evil. Again, why not use=20
workspaces or working resources?

> Again, I'm not discussing what I need. I'm not a user.
>=20
>>=20
>>> > (2) I agree that the locking mechanism is not designed to implement
>>> > transactional isolation.  That is what workspaces and working resou=
rces
>>> > are designed for.  If (for unexplained reasons :-) you don't want t=
o
>>> > use the versioning features that were designed for transactional
>>> > isolation, it should come as no surprise that you have difficulty
>>> > achieving transactional isolation.  Some clients don't want/need
>>> > transactional isolation (they just want history to be kept, for
>> example),
>>> > which is why workspaces and working resources are optional features
>>> > (we define these two different ways of achieving transactional isol=
ation
>>> > because some repositories can only support one, while other reposit=
ories
>>> > can only support the other, and we could find no way of unifying th=
ese
>>> > two different ways under a single feature).
>>>
>>> This is obviously not at all about what I want or don't want to use.
>>> I'm reasoning about the WebDAV model. I haven't said I was against
>> workspaces.
>>=20
>> Well, to be honest, it is not at all clear to me what you do or do not
>> want to do (:-).  The purpose of the WebDAV model is provide a uniform
>> protocol for accessing the various authoring features provided by
>> a wide variety of repositories.  So the interesting questions are
>> "how do I as a client use the protocol to achieve this interesting
>> use case for a user" and "how do I as a repository use the protocol
>> to expose this particular feature of my repository to a client".
>> Without one of those questions in hand, one cannot have a productive
>> discussion about the WebDAV model.
>=20
> I'm assessing the model, because I want to implement it. It is importan=
t
> that a model is consistent and stable, otherwise its implementation wil=
l
> be expensive. In my opinion exposing forking is not consistent. It is n=
ot
> because there is another feature that does the trick, that a particular
> feature shouldn't be scrutinised.
>=20

Please explain in detail where you see inconsistencies. I can only see a=20
non-linear version history so far, which is perfectly consistent.

> Inconsistent parts in a model have a life of their own and can have an
> impact on other areas of the model during evolution, just for the sake
> of compatibility.
>=20
>>=20
>>> > As for the why support forking, it is an (undesireable, but inevita=
ble)
>>> > side-effect of parallel development.  So we don't define it as an
>>> > independent feature, but we "deal with it" for those features that
>>> > support parallel development (i.e., workspaces and working resource=
s).
>>> > In particular, it is what tells you that parallel development has
>>> > occurred on a particular resource, and that therefore a merge is
>>> > required (the need for a merge when forking occurs is why it is
>>> > "undesireable").
>>> >
>>> > So creating forks in a non-parallel development context makes no
>> sense ...
>>> > you are just making trouble for yourself.  Which is why forking onl=
y
>>> > occurs as a side effect of parallel development, and not as a
>> feature that
>>> > you explicitly invoke.
>>>
>>> Which is what I reckoned and it is an encapsulation flaw. Clearly, fo=
rking
>>> on its own is useless, but it is exposed through the WebDAV interface=
 with
>>> elements such as "checkin-fork", "checkout-fork", "fork-ok". There is=
 no
>>> reason for this, nor for the UPDATE method to be allowed to change th=
e
>>> checked-in version, which is the source of the problem.
>>=20
>> The way WebDAV (and HTTP) achieves interoperability is by having a cli=
ent
>> use a single uniform protocol against a wide variety of servers.  So t=
he
>> client always uses the UPDATE method to "restore" a version from histo=
ry,
>> whether it is working with a server that supports working resources,
>> supports
>> workspaces, supports both, or supports neither.  Changing the checked-=
in
>> version is important when the server supports either workspaces or
>> working resources, so you have clients uniformly use the UPDATE method=
.
>> This means that a client is aware of checkin-fork, checkout-fork, and
>> fork-ok behavior, so that in behaves properly when it is applied to a
>> server that supports either workspaces or working resources.
>=20
> It strikes me that workspaces don't expose forking, while working resou=
rces
> do. Workspaces prove it is perfectly possible to offer branching and me=
rging
> without exposing an implementation artifact such as forking. Note that =
they
> also make it possible to work transactionally within the repository wit=
hout
> exposing transaction demarcation.
>=20
> Workspaces are well designed, while working resources are not. Their di=
fference
> should only about configurations, not in the way they offer branching. =
That
> should be exactly the same. The two things are orthogonal.
>=20

The main difference between workspaces and working resources is, IMHO,=20
whether the client controls the namespace or not. In both cases, you get=20
multiple VCRs sharing a common version history. I really do not see a=20
relevant difference in fork handling. What am I missing?


Regards,
Manfred






>>=20
>>> Creating a new
>>> VCR in a workspace from a given version obviously requires forking, b=
ut
>>> that is merely an internal implementation matter.
>>=20
>> No, it's part of the explicit user model, because when you invoke the =
MERGE
>> method, the result of the MERGE method is affected by whether or not
>> there has
>> been any branching, so the client needs to understand when a branch wi=
ll
>> occur,
>> and when it won't. =20
>=20
> Merging and branching go together and you can do it with VCRs only. So =
there
> is no reason to offer another user model for branching than that of wor=
kspaces.
> Working resources should be made compatible with it.
>=20
>>=20
>> Cheers,
>> Geoff
>> =20
>>=20
>>=20
>=20
> Regards,
>=20
> Werner.
> --=20
> Werner Donn=E9  --  Re
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803	e-mail: werner.donne@re.be
>=20
> Received on Thursday, 16 March 2006 17:34:50 GMT
>=20
>     * This message: [ Message body ]
>     * Next message: Manfred Baedke: "Re: rfc2518bis-14: locking termino=
logy"
>     * Previous message: John Barone: "RE: rfc2518bis-14: locking termin=
ology"
>     * In reply to: Geoffrey M Clemm: "Re: UPDATE method and forking"
>=20
>     * Mail actions: [ respond to this message ] [ mail a new topic ]
>     * Contemporary messages sorted: [ by date ] [ by thread ] [ by subj=
ect ] [ by author ]
>     * Help: [ How to use the archives ] [ Search in the archives ]=20
>=20
> This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 M=
arch 2006 17:35:02 GMT




From w3c-dist-auth-request@listhub.w3.org Thu Mar 16 15:56:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJzWY-0001vO-HC
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 15:56:46 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJzWX-0000OZ-Ud
	for webdav-archive@lists.ietf.org; Thu, 16 Mar 2006 15:56:46 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FJzVI-0000BW-DS
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Mar 2006 20:55:28 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FJzV9-0000AZ-Qh
	for w3c-dist-auth@listhub.w3.org; Thu, 16 Mar 2006 20:55:20 +0000
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FJzV0-0004Ul-OA
	for w3c-dist-auth@w3.org; Thu, 16 Mar 2006 20:55:19 +0000
Received: from jbaroned600 ([69.107.70.231]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 16 Mar 2006 12:55:06 -0800
From: "John Barone" 
To: "'Manfred Baedke'" 
Cc: 
Date: Thu, 16 Mar 2006 12:55:10 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0016_01C648F8.DC364030"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <4419AD6E.3070606@greenbytes.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcZJJuecCCn9yikHS+qU1qehINI/hQAE9Hsw
Message-ID: 
X-OriginalArrivalTime: 16 Mar 2006 20:55:06.0567 (UTC) FILETIME=[E7B0F570:01C6493B]
Received-SPF: none (maggie.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FJzV0-0004Ul-OA ff75e5835fda1a62709f30ac8aeacc9d
X-Original-To: w3c-dist-auth@w3.org
Subject: RE: rfc2518bis-14: locking terminology
X-Archived-At: http://www.w3.org/mid/NSNOVPS00411b63Kbc900000e8a@NSNOVPS00411.nacio.xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12237
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 16 Mar 2006 20:55:28 +0000
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc


This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C648F8.DC364030
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

"Section 6.1 defines what a lock is. This is done by giving a set of
"axioms", propositions using the term 'lock' which are true by convention.
It should be possible to read the spec without the slightest idea what a
lock could be. Let us assume that we have no such idea and read section 6.1.
Then we have an understanding of what a lock is, but we would be very
surprised if someone spoke of 'moving locks'. We would say something like:
"Hey, wait, how can you move it if it does not even have a location?".

If one thinks that it makes sense to move a lock, he simply has an
understanding of the term 'lock' that does not match the definitions in this
specification. If the specification never mentioned 'moving locks', why
would any reader think that this term even had a meaning?"
 
[John] I still don't agree.  The basic question is if you copy a resource
has a lock, does the target resource have a lock (albeit with a different
lock-root).  The answer is "no" it doesn't, if the target is not under a
locked parent; that should be clearly stated somewhere.  Similarly a locked
resource that is MOVED, does it still have a lock?  The answer here is also
"no" it doesn't, if the target is not under a locked parent; this should
also be clearly stated somewhere.  Why not clear up ambiguity with
definitive statements?  Argue as you might, clearly there are those who
believe there is ambiguity, otherwise this language wouldn't have been
added.  BTW, this language, or something similar was in the previous 2518
spec., and I don't see a compelling reason to remove it now.
 
-John 





  _____  

From: Manfred Baedke [mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March 16, 2006 10:25 AM
To: John Barone
Cc: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology


John Barone wrote: 

"My main point here is the use of undefined terminology, though I indeed
think that section 6.1 will be perfectly clear on the distinction between a
depth 0 and a depth infinity lock as soon as 6.1.4 uses the term 'member'
instead of 'internal member'. 7.4 contains nothing new, and a list of
special cases can never be as concise as the general principle itself. "
 
[John] OK, I can see that; however section 6.1.4 does not make the
distinction between depth 0 and depth infinity locks.  This section needs to
be cleaned up to make that distinction, and spell out the exact bahavior in
both cases.  Maybe combining what's in section 7. bullet 2 and what's
currently in section 6.1.4.



Agreed that section 6.1 should define lock depth.


 
 
[John] If the root of a lock is a collection, it's important to make clear
that that collection is locked, along with all it's decendents.  I think
this statement should stay (but perhaps reworded to be more precise).
  
My point here is that URIs cannot be locked. Resources can be locked, but
the root of the lock is not a resource.

 
[John] If the target URI for a depth infinity lock request is a collection,
the collection IS most certainly locked.  But to your point, if the language
in section 6.1.x is cleaned up, this entire section can be removed.



The target URI of a lock request will never be a collection, but the URI of
a collection. An URI is an URI and a resource is a resource. As defined in
6.1, resources can be locked. URIs can't.


 
Move/Copy behavior...
 
Well, copying locks is as undefined as lock duplication

How could one think that a lock could be moved if it is not defined what
this could mean?
 
... by the same token, what does it mean to duplicate or move live or dead
properties; those operations aren't defined either for properties, and yet
you MUST/SHOULD do it.  I don't see the harm here, in fact I think it's a
very good idea to explicitly state this in the spec. to remove ambiguity.  I
think the copy/move MUST NOT statements should be kept either in a 7.x
section, or wrapped into a revised 6.1.4 section.


Well, if the spec does not define what it means to move a property, then it
should either correct this or stop to use this terminology.

Section 6.1 defines what a lock is. This is done by giving a set of
"axioms", propositions using the term 'lock' which are true by convention.
It should be possible to read the spec without the slightest idea what a
lock could be. Let us assume that we have no such idea and read section 6.1.
Then we have an understanding of what a lock is, but we would be very
surprised if someone spoke of 'moving locks'. We would say something like:
"Hey, wait, how can you move it if it does not even have a location?".

If one thinks that it makes sense to move a lock, he simply has an
understanding of the term 'lock' that does not match the definitions in this
specification. If the specification never mentioned 'moving locks', why
would any reader think that this term even had a meaning?

Regards,
Manfred



------=_NextPart_000_0016_01C648F8.DC364030
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







"Section 6.1 defines what a lock is. =
This is=20
done by giving a set of "axioms", propositions using the term 'lock' =
which are=20
true by convention. It should be possible to read the spec without the =
slightest=20
idea what a lock could be. Let us assume that we have no such idea and =
read=20
section 6.1. Then we have an understanding of what a lock is, but we =
would be=20
very surprised if someone spoke of 'moving locks'. We would say =
something like:=20
"Hey, wait, how can you move it if it does not even have a =
location?".

If=20
one thinks that it makes sense to move a lock, he simply has an =
understanding of=20
the term 'lock' that does not match the definitions in this =
specification. If=20
the specification never mentioned 'moving locks', why would any reader =
think=20
that this term even had a meaning?"


 

[John] I still =
don't=20
agree.  The basic question is if you copy a resource has a lock, =
does the=20
target resource have a lock (albeit with a different lock-root).  =
The=20
answer is "no" it doesn't, if the target is not under a locked parent; =
that=20
should be clearly stated somewhere.  Similarly a locked resource =
that is=20
MOVED, does it still have a lock?  The answer here is =
also "no" it=20
doesn't, if the target is not under a locked parent; this should =
also be=20
clearly stated somewhere.  Why not clear up ambiguity with =
definitive=20
statements?  Argue as you might, clearly there are those who =
believe there=20
is ambiguity, otherwise this language wouldn't have been added.  =
BTW, this=20
language, or something similar was in the previous 2518 spec., and I =
don't see a=20
compelling reason to remove it =
now.


 

-John 










From: Manfred Baedke=20
[mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March =
16, 2006=20
10:25 AM
To: John Barone
Cc:=20
w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking=20
terminology



John Barone wrote:=20


  
  
"My main point here is =
the use of=20
  undefined terminology, though I indeed think that section 6.1 will be=20
  perfectly clear on the distinction between a depth 0 and a depth =
infinity lock=20
  as soon as 6.1.4 uses the term 'member' instead of 'internal member'. =
7.4=20
  contains nothing new, and a list of special cases can never be as =
concise as=20
  the general principle itself. "

  
 

  
[John] OK, I can see =
that; however=20
  section 6.1.4 does not make the distinction between depth 0 and depth =
infinity=20
  locks.  This section needs to be cleaned up to make that =
distinction, and=20
  spell out the exact bahavior in both cases.  Maybe combining =
what's in=20
  section 7. bullet 2 and what's currently in section=20
  6.1.4.

  

Agreed that section 6.1 should =
define lock=20
depth.



  
 

  
 

  
[John] If the root of a lock is =
a=20
  collection, it's important to make clear
that that collection is =
locked,=20
  along with all it's decendents.  I think
this statement should =
stay=20
  (but perhaps reworded to be more precise).
  
My point here =
is that=20
  URIs cannot be locked. Resources can be locked, but the root of the =
lock is=20
  not a resource.

  
 

  
[John] If the target URI for a depth infinity lock request is =
a=20
  collection, the collection IS most certainly locked.  But to your =
point,=20
  if the language in section 6.1.x is cleaned up, this entire section =
can be=20
  removed.

  

The target URI of a lock =
request will never=20
be a collection, but the URI of a collection. An URI is an URI and a =
resource is=20
a resource. As defined in 6.1, resources can be locked. URIs can't.



  
 

  
Move/Copy behavior...

  
 

  
Well, copying locks is as =
undefined as=20
  lock duplication

  
 
How could one think that a =
lock could=20
  be moved if it is not defined what this could mean?

  
 

  
...=20
  by the same token, what does it mean to duplicate or =
move live or=20
  dead properties; those operations aren't defined either for =
properties, and=20
  yet you MUST/SHOULD do it.  I don't see the harm here, in fact I =
think=20
  it's a very good idea to explicitly state this in the spec. to remove=20
  ambiguity.  I think the copy/move MUST NOT statements should be =
kept=20
  either in a 7.x section, or wrapped into a revised 6.1.4=20
  section.

  
Well, =
if the spec=20
does not define what it means to move a property, then it should either =
correct=20
this or stop to use this terminology.

Section 6.1 defines what a =
lock is.=20
This is done by giving a set of "axioms", propositions using the term =
'lock'=20
which are true by convention. It should be possible to read the spec =
without the=20
slightest idea what a lock could be. Let us assume that we have no such =
idea and=20
read section 6.1. Then we have an understanding of what a lock is, but =
we would=20
be very surprised if someone spoke of 'moving locks'. We would say =
something=20
like: "Hey, wait, how can you move it if it does not even have a=20
location?".

If one thinks that it makes sense to move a lock, he =
simply=20
has an understanding of the term 'lock' that does not match the =
definitions in=20
this specification. If the specification never mentioned 'moving locks', =
why=20
would any reader think that this term even had a=20
meaning?

Regards,
Manfred



------=_NextPart_000_0016_01C648F8.DC364030--





From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 03:42:50 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKAXq-0007yT-7m
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 03:42:50 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKAXp-00068P-Fd
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 03:42:49 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKAWH-0006AF-Li
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 08:41:13 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKAW9-00069W-5h
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 08:41:05 +0000
Received: from asia.telenet-ops.be ([195.130.137.74])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKAW4-0004Zp-Hv
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 08:41:04 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by asia.telenet-ops.be (Postfix) with SMTP
	id E2C5E16810E; Fri, 17 Mar 2006 09:40:55 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by asia.telenet-ops.be (Postfix) with ESMTP
	id 24146168106; Fri, 17 Mar 2006 09:40:55 +0100 (CET)
Message-ID: <441A7622.3010508@re.be>
Date: Fri, 17 Mar 2006 09:41:06 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manfred Baedke 
Cc: w3c-dist-auth@w3.org, geoffrey.clemm@us.ibm.com
References: <4419B9A7.4080205@greenbytes.de>
In-Reply-To: <4419B9A7.4080205@greenbytes.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (aji.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1FKAW4-0004Zp-Hv 05e3011fdc9e67a3fff2b68ac4923f0f
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441A7622.3010508@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12238
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 08:41:13 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 850245b51c39701e2700a112f3032caa


Hi Manfred,

Manfred Baedke wrote:
> Hi Werner,
>=20
> comments inline:
>=20
>>> Werner Donn=E9  wrote on 03/16/2006 08:01:57 AM:
>>>
>>>> Geoffrey M Clemm wrote:
>>>> >
>>>> > (1) Why does this scenario have to be in one transaction?  In
>>> particular,
>>>> > why isn't it sufficient just to wrap the sequence of operations in
>>>> > a LOCK/UNLOCK?=20
>>>> Because anything in between can go wrong, leaving the system in an
>>>> inconsistent state. It can't be the responsibility of the client to
>>>> keep the state consistent. That is a co-operative and hence unreliab=
le
>>>> design.
>>>
>>> The only thing that can go wrong is that the client neglects to perfo=
rm
>>> an UNLOCK, which is why there are timeout and administrative override
>>> mechanisms
>>> in the locking protocol.  But I agree that many clients would rather =
not
>>> deal with locks, which is why we introduced the workspace feature.=20
>>> So lets
>>> focus on whether or not the workspace feature provides what you need.
>>
>> Between each step in the sequence the dialogue can be interrupted. Not
>> only
>> would the lock not be released, but the checked-in version of the VCR
>> could
>> also be on another version than it was originally. This is an unexpect=
ed
>> global state change for all clients, which is not acceptable in a
>> concurrent
>> system.
>>
>=20
> So the checked-in version of the VCR changed. Every client (at least
> those who do not hold a lock) must be aware of this possibility at any
> time. Why should this be unexpected?

Several clients can be executing such scenarios at the same time with the
same VCR. In order to avoid sudden changes of the checked-in version they
all have to use locking. Locking, however, is not mandatory, so it is up
to the clients to make sure there are no races. This is a co-operative
process. It is like saying that multiple clients can update tables in a
database, but they have to manage table or record locking themselves. It
was like that decades ago.

The forking and update mechanisms require isolation and locking is not
the good instrument for that. Workspaces achieve concurrency in a natural
way without imposing co-operative scenarios with locking. This is both
safer and simpler.

>=20
>> Regarding the lock release the timeout mechanism is not good enough if
>> locking is used like that, because VCR is blocked too long. This impac=
ts
>> concurrency severely. When a transaction fails, for example, everythin=
g
>> is rolled back and release immediately.
>>
>=20
> Yes, long lasting exclusive locks are evil. Again, why not use
> workspaces or working resources?

They are not evil if the repository supports branching. It is common to
reserve a branch, because branches are a tool to let people work together
on the same topic. Long-lasting locks should not be used on the integrati=
on
branch in which all work will be merged.

>=20
>> Again, I'm not discussing what I need. I'm not a user.
>>
>>>
>>>> > (2) I agree that the locking mechanism is not designed to implemen=
t
>>>> > transactional isolation.  That is what workspaces and working
>>>> resources
>>>> > are designed for.  If (for unexplained reasons :-) you don't want =
to
>>>> > use the versioning features that were designed for transactional
>>>> > isolation, it should come as no surprise that you have difficulty
>>>> > achieving transactional isolation.  Some clients don't want/need
>>>> > transactional isolation (they just want history to be kept, for
>>> example),
>>>> > which is why workspaces and working resources are optional feature=
s
>>>> > (we define these two different ways of achieving transactional
>>>> isolation
>>>> > because some repositories can only support one, while other
>>>> repositories
>>>> > can only support the other, and we could find no way of unifying
>>>> these
>>>> > two different ways under a single feature).
>>>>
>>>> This is obviously not at all about what I want or don't want to use.
>>>> I'm reasoning about the WebDAV model. I haven't said I was against
>>> workspaces.
>>>
>>> Well, to be honest, it is not at all clear to me what you do or do no=
t
>>> want to do (:-).  The purpose of the WebDAV model is provide a unifor=
m
>>> protocol for accessing the various authoring features provided by
>>> a wide variety of repositories.  So the interesting questions are
>>> "how do I as a client use the protocol to achieve this interesting
>>> use case for a user" and "how do I as a repository use the protocol
>>> to expose this particular feature of my repository to a client".
>>> Without one of those questions in hand, one cannot have a productive
>>> discussion about the WebDAV model.
>>
>> I'm assessing the model, because I want to implement it. It is importa=
nt
>> that a model is consistent and stable, otherwise its implementation wi=
ll
>> be expensive. In my opinion exposing forking is not consistent. It is =
not
>> because there is another feature that does the trick, that a particula=
r
>> feature shouldn't be scrutinised.
>>
>=20
> Please explain in detail where you see inconsistencies. I can only see =
a
> non-linear version history so far, which is perfectly consistent.

You have two alternatives for working in parallel, where one suffices. On=
e
method, working resources, exposes physical aspects such as forking and
puts the resposibility for integrity at the client. The other is abstract=
.
It doesn't expose implementation details, because each "branch" has its
own VCR and the checked-in version of each VCR can be left to be the most
recent version. The integrity responsibility is within the server.

The only functional difference there is supposed to be between workspaces
and working resources is that the latter work in their own configuration,
a term that is nowhere defined by the way prior to section 9 of RFC 3253.

That makes it still possible to use workspaces in a client that would hav=
e
to resort to working resources. Workspaces are now positioned as a pure
server functionality. They are, however, an abstract mechanism that can
be perfectly implemented differently in a real server and in a stand-alon=
e
client. For the latter the implementation may be lighter because there is
perhaps no cuncurrency, making the preservation of integrity easier. It
is as if such a client has its own built-in server.

>=20
>> Inconsistent parts in a model have a life of their own and can have an
>> impact on other areas of the model during evolution, just for the sake
>> of compatibility.
>>
>>>
>>>> > As for the why support forking, it is an (undesireable, but
>>>> inevitable)
>>>> > side-effect of parallel development.  So we don't define it as an
>>>> > independent feature, but we "deal with it" for those features that
>>>> > support parallel development (i.e., workspaces and working
>>>> resources).
>>>> > In particular, it is what tells you that parallel development has
>>>> > occurred on a particular resource, and that therefore a merge is
>>>> > required (the need for a merge when forking occurs is why it is
>>>> > "undesireable").
>>>> >
>>>> > So creating forks in a non-parallel development context makes no
>>> sense ...
>>>> > you are just making trouble for yourself.  Which is why forking on=
ly
>>>> > occurs as a side effect of parallel development, and not as a
>>> feature that
>>>> > you explicitly invoke.
>>>>
>>>> Which is what I reckoned and it is an encapsulation flaw. Clearly,
>>>> forking
>>>> on its own is useless, but it is exposed through the WebDAV
>>>> interface with
>>>> elements such as "checkin-fork", "checkout-fork", "fork-ok". There
>>>> is no
>>>> reason for this, nor for the UPDATE method to be allowed to change t=
he
>>>> checked-in version, which is the source of the problem.
>>>
>>> The way WebDAV (and HTTP) achieves interoperability is by having a
>>> client
>>> use a single uniform protocol against a wide variety of servers.  So =
the
>>> client always uses the UPDATE method to "restore" a version from
>>> history,
>>> whether it is working with a server that supports working resources,
>>> supports
>>> workspaces, supports both, or supports neither.  Changing the checked=
-in
>>> version is important when the server supports either workspaces or
>>> working resources, so you have clients uniformly use the UPDATE metho=
d.
>>> This means that a client is aware of checkin-fork, checkout-fork, and
>>> fork-ok behavior, so that in behaves properly when it is applied to a
>>> server that supports either workspaces or working resources.
>>
>> It strikes me that workspaces don't expose forking, while working
>> resources
>> do. Workspaces prove it is perfectly possible to offer branching and
>> merging
>> without exposing an implementation artifact such as forking. Note that
>> they
>> also make it possible to work transactionally within the repository
>> without
>> exposing transaction demarcation.
>>
>> Workspaces are well designed, while working resources are not. Their
>> difference
>> should only about configurations, not in the way they offer branching.
>> That
>> should be exactly the same. The two things are orthogonal.
>>
>=20
> The main difference between workspaces and working resources is, IMHO,
> whether the client controls the namespace or not. In both cases, you ge=
t
> multiple VCRs sharing a common version history. I really do not see a
> relevant difference in fork handling. What am I missing?

See above.

>=20
>=20
> Regards,
> Manfred
>=20

Regards,

Werner.
--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 04:01:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKApb-0003ci-4t
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 04:01:11 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKApY-0006eS-Nu
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 04:01:11 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKAp8-0002S9-I1
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 09:00:42 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKAoz-0002L5-8h
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 09:00:33 +0000
Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FKAow-0002gQ-14
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 09:00:33 +0000
Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id EC61F499C0;
	Fri, 17 Mar 2006 10:00:27 +0100 (CET)
Message-ID: <441A7AB1.30504@greenbytes.de>
Date: Fri, 17 Mar 2006 10:00:33 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: John Barone 
CC:  w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FKAow-0002gQ-14 273e68378a00a1de24be5c4735335bfb
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology
X-Archived-At: http://www.w3.org/mid/441A7AB1.30504@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12239
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 09:00:42 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365


John Barone wrote:
> "Section 6.1 defines what a lock is. This is done by giving a set of 
> "axioms", propositions using the term 'lock' which are true by 
> convention. It should be possible to read the spec without the slightest 
> idea what a lock could be. Let us assume that we have no such idea and 
> read section 6.1. Then we have an understanding of what a lock is, but 
> we would be very surprised if someone spoke of 'moving locks'. We would 
> say something like: "Hey, wait, how can you move it if it does not even 
> have a location?".
> 
> If one thinks that it makes sense to move a lock, he simply has an 
> understanding of the term 'lock' that does not match the definitions in 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?"
>  
> [John] I still don't agree.  The basic question is if you copy a 
> resource has a lock, does the target resource have a lock (albeit with a 
> different lock-root).  The answer is "no" it doesn't, if the target is 
> not under a locked parent; that should be clearly stated somewhere.  
> Similarly a locked resource that is MOVED, does it still have a lock?  
> The answer here is also "no" it doesn't, if the target is not under a 
> locked parent; this should also be clearly stated somewhere.  Why not 
> clear up ambiguity with definitive statements?  Argue as you might, 
> clearly there are those who believe there is ambiguity, otherwise this 
> language wouldn't have been added.  BTW, this language, or something 
> similar was in the previous 2518 spec., and I don't see a compelling 
> reason to remove it now.
>  
> -John 
> 
> 

First of all, this part of my original mail was about _how_ things are 
stated, not _if_ they are stated.
There are some operations that can, by definition, be performed with a 
lock. You can create it. You can delete it. Section 6.1 defines what 
that means. But since it is not defined, you can't eat it, you can't 
take it around the block, and no, you can't move or copy it!

Second of all, when you COPY a resource A which is locked by the lock L, 
the destination resource B may of course also be locked by L, namely if 
it's a member resource of the resource which the lock root is mapped to. 
This follows immediately from 6.1.4.
So generally, after the COPY is performed, B may or may not be locked by L.

Regards,
Manfred


Regards,
Manfred

> 
> ------------------------------------------------------------------------
> *From:* Manfred Baedke [mailto:manfred.baedke@greenbytes.de]
> *Sent:* Thursday, March 16, 2006 10:25 AM
> *To:* John Barone
> *Cc:* w3c-dist-auth@w3.org
> *Subject:* Re: rfc2518bis-14: locking terminology
> 
> John Barone wrote:
>> "My main point here is the use of undefined terminology, though I 
>> indeed think that section 6.1 will be perfectly clear on the 
>> distinction between a depth 0 and a depth infinity lock as soon as 
>> 6.1.4 uses the term 'member' instead of 'internal member'. 7.4 
>> contains nothing new, and a list of special cases can never be as 
>> concise as the general principle itself. "
>>  
>> [John] OK, I can see that; however section 6.1.4 does not make the 
>> distinction between depth 0 and depth infinity locks.  This section 
>> needs to be cleaned up to make that distinction, and spell out the 
>> exact bahavior in both cases.  Maybe combining what's in section 7. 
>> bullet 2 and what's currently in section 6.1.4.
>>
> Agreed that section 6.1 should define lock depth.
>>  
>>  
>> [John] If the root of a lock is a collection, it's important to make clear
>> that that collection is locked, along with all it's decendents.  I think
>> this statement should stay (but perhaps reworded to be more precise).
>>  
>> My point here is that URIs cannot be locked. Resources can be locked, 
>> but the root of the lock is not a resource.
>>  
>> [John] If the target URI for a depth infinity lock request is a 
>> collection, the collection IS most certainly locked.  But to your 
>> point, if the language in section 6.1.x is cleaned up, this entire 
>> section can be removed.
>>
> The target URI of a lock request will never be a collection, but the URI 
> of a collection. An URI is an URI and a resource is a resource. As 
> defined in 6.1, resources can be locked. URIs can't.
>>  
>> Move/Copy behavior...
>>  
>> Well, copying locks is as undefined as lock duplication
>>
>> How could one think that a lock could be moved if it is not defined 
>> what this could mean?
>>  
>> ... by the same token, what does it mean to duplicate or move live or 
>> dead properties; those operations aren't defined either for 
>> properties, and yet you MUST/SHOULD do it.  I don't see the harm here, 
>> in fact I think it's a very good idea to explicitly state this in the 
>> spec. to remove ambiguity.  I think the copy/move MUST NOT statements 
>> should be kept either in a 7.x section, or wrapped into a revised 
>> 6.1.4 section.
> Well, if the spec does not define what it means to move a property, then 
> it should either correct this or stop to use this terminology.
> 
> Section 6.1 defines what a lock is. This is done by giving a set of 
> "axioms", propositions using the term 'lock' which are true by 
> convention. It should be possible to read the spec without the slightest 
> idea what a lock could be. Let us assume that we have no such idea and 
> read section 6.1. Then we have an understanding of what a lock is, but 
> we would be very surprised if someone spoke of 'moving locks'. We would 
> say something like: "Hey, wait, how can you move it if it does not even 
> have a location?".
> 
> If one thinks that it makes sense to move a lock, he simply has an 
> understanding of the term 'lock' that does not match the definitions in 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?
> 
> Regards,
> Manfred
> 





From kelcerieme@gmmb.com Fri Mar 17 06:36:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKDFp-0003Ui-O0
	for webdav-archive@ietf.org; Fri, 17 Mar 2006 06:36:25 -0500
Received: from [83.214.198.78] (helo=gmmb.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FKDFo-0003AW-43
	for webdav-archive@ietf.org; Fri, 17 Mar 2006 06:36:25 -0500
Message-ID: <000001c649b6$fe354fa0$2539a8c0@ilb83>
Reply-To: "Kelcey Riemer" 
From: "Kelcey Riemer" 
To: webdav-archive@ietf.org
Subject: Re: Phar5Lamacy news
Date: Fri, 17 Mar 2006 06:36:12 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C6498D.155F47A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 2.5 (++)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6498D.155F47A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
n C c i g a q I q i s s $ z 99 (10 n6   o p p i c l p l u s u )
f V z a a I f i y u r m $ t 105 (3 Sp 0  x p f i i l h l h s f )
p V i i d a i g o r m a $ x 69 (1 qW 0  f p l i e l s l q s e )
=20
Many o YP ther, Vi Ky sit our sit cz e   and
Sa n9 ve o 6h ver 50 X0 %

------=_NextPart_000_0001_01C6498D.155F47A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









 


 n C c i g a q I q i s s $ z 99 (10 n6   o p p i c l p l u s u )


 f V z a a I f i y u r m $ t 105 (3 Sp 0  x p f i i l h l h s f )


 p V i i d a i g o r m a $ x 69 (1 qW 0  f p l i e l s l q s e )


 


Many o YP ther, Vi Ky sit our sit cz e and Sa n9 ve o 6h ver 50 X0 %

------=_NextPart_000_0001_01C6498D.155F47A0--






From nickebecka@animalstop.com Fri Mar 17 07:12:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKDoT-0004La-4F
	for webdav-archive@ietf.org; Fri, 17 Mar 2006 07:12:13 -0500
Received: from host166-99.pool871.interbusiness.it ([87.1.99.166] helo=animalstop.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FKDoR-0004Cc-Bt
	for webdav-archive@ietf.org; Fri, 17 Mar 2006 07:12:13 -0500
Message-ID: <000001c649bb$ffddb630$8d0ba8c0@fah83>
Reply-To: "Becka Nickell" 
From: "Becka Nickell" 
To: webdav-archive@ietf.org
Subject: Re: PharamacNmy news
Date: Fri, 17 Mar 2006 07:12:02 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C64992.1707AE30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.2 (++++)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C64992.1707AE30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
o C s i j a h I t i y s $ l 99 ( VB 10  x p h i c l r l y s w )
u V n a r I x i d u f m $10 e 5 (30 6C   j p z i b l u l e s y )
l V z i i a z g e r j a $6 w 9 (1 ny 0  j p y i w l l l p s h )
=20
Many Ck other, Visi UA t our sit xc e   and
Sa 38 ve ov TO er 5 12 0%

------=_NextPart_000_0001_01C64992.1707AE30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









 


 o C s i j a h I t i y s $ l 99 ( VB 10  x p h i c l r l y s w )


 u V n a r I x i d u f m $10 e 5 (30 6C   j p z i b l u l e s y )


 l V z i i a z g e r j a $6 w 9 (1 ny 0  j p y i w l l l p s h )


 


Many Ck  other, Visi UA t our sit xc e and Sa 38 ve ov TO er 5 12 0%

------=_NextPart_000_0001_01C64992.1707AE30--






From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 09:58:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGPO-0006Wt-3U
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 09:58:30 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKGPM-0001CG-RX
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 09:58:30 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKGON-0000CL-VT
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 14:57:27 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKGOC-00009J-PX
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 14:57:16 +0000
Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FKGOB-0006Bv-5i
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 14:57:16 +0000
Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 6101830F57;
	Fri, 17 Mar 2006 15:57:13 +0100 (CET)
Message-ID: <441ACE48.3010305@greenbytes.de>
Date: Fri, 17 Mar 2006 15:57:12 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To:  werner.donne@re.be
CC:  w3c-dist-auth@w3.org,  geoffrey.clemm@us.ibm.com
References: <4419B9A7.4080205@greenbytes.de> <441A7622.3010508@re.be>
In-Reply-To: <441A7622.3010508@re.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FKGOB-0006Bv-5i 4a570e291d558d3961d0810e54f2a503
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441ACE48.3010305@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12240
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 14:57:27 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


Hi Werner,

> You have two alternatives for working in parallel, where one suffices. One
> method, working resources, exposes physical aspects such as forking and
> puts the resposibility for integrity at the client. The other is abstract.
> It doesn't expose implementation details, because each "branch" has its
> own VCR and the checked-in version of each VCR can be left to be the most
> recent version. The integrity responsibility is within the server.
>   
First of all, checking out a working resource _does_ create a new VCR, 
much like a VERSION-CONTROL request to an unmapped URL which is a member 
URL of a workspace, the main difference being that in the latter case 
the client can choose the URL. Both mechanisms can be used to create 
multiple VCRs sharing a common version history and both can (but not 
must) be used in the way you describe (letting the checked-in version of 
each VCR be the "end of a branch").
I am still trying to understand what you mean when you speak of 
'integrity'. Am I right that you propose, speaking loosely, that the 
'original' VCR should belong to something like a 'main branch', its 
checked-in version always being the end of that branch, and that a new 
branch should be created by creating a new VCR (based on an 'old 
version') within a workspace?
I you do so, feel free not to support the UPDATE feature in your 
implementation.

Regards,
Manfred






From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 10:13:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGdo-0006Qu-AL
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:13:24 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKGdn-0001gV-IU
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:13:24 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKGdN-00072U-S1
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 15:12:57 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKGdC-0006o6-Nl
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 15:12:47 +0000
Received: from e2.ny.us.ibm.com ([32.97.182.142])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKGd1-00086g-PL
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 15:12:45 +0000
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2HFCULl026180
	for ; Fri, 17 Mar 2006 10:12:30 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2HFCUvj154500
	for ; Fri, 17 Mar 2006 10:12:30 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2HFCUPR002500
	for ; Fri, 17 Mar 2006 10:12:30 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2HFCTjG002416
	for ; Fri, 17 Mar 2006 10:12:29 -0500
In-Reply-To: <441A7622.3010508@re.be>
To: " webdav" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Fri, 17 Mar 2006 09:05:27 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/17/2006 10:12:29,
	Serialize complete at 03/17/2006 10:12:29
Content-Type: multipart/alternative; boundary="=_alternative 004CBE6F85257134_="
Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: aji.w3.org 1FKGd1-00086g-PL b0c6b683aeb1035c46a98c381dac3de7
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/OF5CD2FBBB.8DCF9863-ON85257134.0047F5C7-85257134.004D66B0@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12241
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 15:12:57 +0000
X-Spam-Score: 0.5 (/)
X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c


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

A few initial comments, and then additional comments in-line:

The reason for supporting locking is not because locking is a good way
to do parallel development on a versioning server (it isn't), but rather
because there are a lot of WebDAV locking clients out there, and we
want to ensure that they work as well as possible against a versioning
server.  So when we argue that "locking works", we aren't saying that
locking is a good way to solve this problem, but rather that if you have
a locking client, it will interoperate well with a versioning server
that supports the RFC-3253 versioning protocol.

The reason for supporting working resources is not because it provides
a good model for clients to work with (it doesn't), but rather that
it provides a different distribution of work between the client and
server.  In particular, with a workspace server, all of the work is
being done on the server, which means clients are much simpler to write.
With a working-resource server, a large part of the work has to be done
on a client (effectively, the client implements a client-side 
workspace, using local persistent state on the client, and the
low-level working-resource mechanisms provided by the server),
but because the server (the shared resource) does
significantly less work, it is actually much simpler to write a scalable
system using the working-resource mechanism than it is to write one
using the workspace mechanism.  This was the one architectural choice
which we found we couldn't hide beneath a common protocol (and I can
vouch for the fact that we tried very hard for a very long time to
do so). 

In that context, some additional comments below:


Werner wrote on 03/17/2006 03:41:06 AM:
> Manfred Baedke wrote:
> > 
> > So the checked-in version of the VCR changed. Every client (at least
> > those who do not hold a lock) must be aware of this possibility at any
> > time. Why should this be unexpected?
> 
> Several clients can be executing such scenarios at the same time with 
the
> same VCR. In order to avoid sudden changes of the checked-in version 
they
> all have to use locking. Locking, however, is not mandatory, so it is up
> to the clients to make sure there are no races. This is a co-operative
> process. 

A single locking client on its own can ensure there are
no races by taking out the lock.  An attempt to modify this resource by
any method (PUT, UPDATE, MERGE) by another client will fail while the 
client
has the lock.  The only time co-operation is required is amoung a group of
non-locking clients ... but in this case they use etags, which will also
work against a versioning server.  To emphasize the point made above, this 
is
not an argument that locking the VCR is a good way to handle this problem 
...
it is an argument that existing locking clients will interoperate in a 
reasonable
way with a server that supports RFC-3253.

> It is like saying that multiple clients can update tables in a
> database, but they have to manage table or record locking themselves. It
> was like that decades ago.

Yes, but if you have thousands of deployed clients (written years ago
when there was no workspace protocol) that do this table and
record locking management, it is a very good thing if they will just work
unmodified against the new versioning servers.

> The forking and update mechanisms require isolation and locking is not
> the good instrument for that. Workspaces achieve concurrency in a 
natural
> way without imposing co-operative scenarios with locking. This is both
> safer and simpler.

Totally agree.  Newer clients that take advantage of the workspace 
protocol
will be much easier to write than it was to write the older clients that 
only
could use the locking protocol.

> >> Regarding the lock release the timeout mechanism is not good enough 
if
> >> locking is used like that, because VCR is blocked too long. This 
impacts
> >> concurrency severely. When a transaction fails, for example, 
everything
> >> is rolled back and release immediately.
> > 
> > Yes, long lasting exclusive locks are evil. Again, why not use
> > workspaces or working resources?
> 
> They are not evil if the repository supports branching. It is common to
> reserve a branch, because branches are a tool to let people work 
together
> on the same topic. Long-lasting locks should not be used on the 
integration
> branch in which all work will be merged.

A branch is modeled in the WebDAV protocol as an "activity".  Note that
we use the term "reserve" for what you do to a branch, to avoid confusion 
with the
"lock" protocol.  The lock protocol was not used for reserving branches,
because we didn't want the client to have to maintain lock tokens for the
branch they are working on.

> > Please explain in detail where you see inconsistencies. I can only see 
a
> > non-linear version history so far, which is perfectly consistent.
> 
> You have two alternatives for working in parallel, where one suffices. 
One
> method, working resources, exposes physical aspects such as forking and
> puts the resposibility for integrity at the client. The other is 
abstract.
> It doesn't expose implementation details, because each "branch" has its
> own VCR and the checked-in version of each VCR can be left to be the 
most
> recent version. The integrity responsibility is within the server.

Yes, I agree that the workspace protocol allows for much simpler clients
to be written.

> The only functional difference there is supposed to be between 
workspaces
> and working resources is that the latter work in their own 
configuration,
> a term that is nowhere defined by the way prior to section 9 of RFC 
3253.

Actually, it is section 10.2 ... "Advanced Versioning Terms".  Before 
then,
it was just used in an informal descriptive way, and was not part of the 
protocol.

Since my repository supports workspaces, I did try for quite a while to
convince the standards group that we only needed to support workspaces, 
but
the reality is that there are repositories that do not (and cannot) 
support
workspaces, but do support working resources, and unless we defined
working resources support in the protocol, clients would not be able to
interoperate in a useful way with those repositories.

> That makes it still possible to use workspaces in a client that would 
have
> to resort to working resources. Workspaces are now positioned as a pure
> server functionality. They are, however, an abstract mechanism that can
> be perfectly implemented differently in a real server and in a 
stand-alone
> client. For the latter the implementation may be lighter because there 
is
> perhaps no cuncurrency, making the preservation of integrity easier. It
> is as if such a client has its own built-in server.

But from a protocol perspective, you cannot hide this difference.  This is
in fact one of the major reasons why we started JSR-147, which is a 
client-level
API rather than a client-server protocol.  In JSR-147, there is only the
workspace model, because in a client API, you can hide the implementation 
choice
of "fat client" (working-resource model) or "skinny client" (workspace 
model)
under the client library layer that supports the JSR-147 API.

Cheers,
Geoff

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



A few initial comments, and then additional comments
in-line:



The reason for supporting locking is not because locking
is a good way

to do parallel development on a versioning server
(it isn't), but rather

because there are a lot of WebDAV locking clients
out there, and we

want to ensure that they work as well as possible
against a versioning

server.  So when we argue that "locking
works", we aren't saying that

locking is a good way to solve this problem, but rather
that if you have

a locking client, it will interoperate well with a
versioning server

that supports the RFC-3253 versioning protocol.



The reason for supporting working resources is not
because it provides

a good model for clients to work with (it doesn't),
but rather that

it provides a different distribution of work between
the client and

server.  In particular, with a workspace server,
all of the work is

being done on the server, which means clients are
much simpler to write.

With a working-resource server, a large part of the
work has to be done

on a client (effectively, the client implements a
client-side 

workspace, using local persistent state on the client,
and the

low-level working-resource mechanisms provided by
the server),

but because the server (the shared resource) does

significantly less work, it is actually much simpler
to write a scalable

system using the working-resource mechanism than it
is to write one

using the workspace mechanism.  This was the
one architectural choice

which we found we couldn't hide beneath a common protocol
(and I can

vouch for the fact that we tried very hard for a very
long time to

do so). 



In that context, some additional comments below:





Werner wrote on 03/17/2006 03:41:06 AM:

> Manfred Baedke wrote:

> > 

> > So the checked-in version of the VCR changed. Every client (at
least

> > those who do not hold a lock) must be aware of this possibility
at any

> > time. Why should this be unexpected?

> 

> Several clients can be executing such scenarios at the same time with
the

> same VCR. In order to avoid sudden changes of the checked-in version
they

> all have to use locking. Locking, however, is not mandatory, so it
is up

> to the clients to make sure there are no races. This is a co-operative

> process. 



A single locking client on its own can ensure there
are

no races by taking out the lock.  An attempt
to modify this resource by

any method (PUT, UPDATE, MERGE) by another client
will fail while the client

has the lock.  The only time co-operation is
required is amoung a group of

non-locking clients ... but in this case they use
etags, which will also

work against a versioning server.  To emphasize
the point made above, this is

not an argument that locking the VCR is a good way
to handle this problem ...

it is an argument that existing locking clients will
interoperate in a reasonable

way with a server that supports RFC-3253.



> It is like saying that multiple clients can update
tables in a

> database, but they have to manage table or record locking themselves.
It

> was like that decades ago.



Yes, but if you have thousands of deployed clients
(written years ago

when there was no workspace protocol) that do this
table and

record locking management, it is a very good thing
if they will just work

unmodified against the new versioning servers.



> The forking and update mechanisms require isolation and locking is
not

> the good instrument for that. Workspaces achieve concurrency in a
natural

> way without imposing co-operative scenarios with locking. This is
both

> safer and simpler.



Totally agree.  Newer clients that take advantage
of the workspace protocol

will be much easier to write than it was to write
the older clients that only

could use the locking protocol.



> >> Regarding the lock release the timeout mechanism is not good
enough if

> >> locking is used like that, because VCR is blocked too long.
This impacts

> >> concurrency severely. When a transaction fails, for example,
everything

> >> is rolled back and release immediately.

> > 

> > Yes, long lasting exclusive locks are evil. Again, why not use

> > workspaces or working resources?

> 

> They are not evil if the repository supports branching. It is common
to

> reserve a branch, because branches are a tool to let people work together

> on the same topic. Long-lasting locks should not be used on the integration

> branch in which all work will be merged.



A branch is modeled in the WebDAV protocol as an "activity".
 Note that

we use the term "reserve" for what you do
to a branch, to avoid confusion with the

"lock" protocol.  The lock protocol
was not used for reserving branches,

because we didn't want the client to have to maintain
lock tokens for the

branch they are working on.



> > Please explain in detail where you see inconsistencies. I can
only see a

> > non-linear version history so far, which is perfectly consistent.

> 

> You have two alternatives for working in parallel, where one suffices.
One

> method, working resources, exposes physical aspects such as forking
and

> puts the resposibility for integrity at the client. The other is abstract.

> It doesn't expose implementation details, because each "branch"
has its

> own VCR and the checked-in version of each VCR can be left to be the
most

> recent version. The integrity responsibility is within the server.



Yes, I agree that the workspace protocol allows for
much simpler clients

to be written.



> The only functional difference there is supposed to be between workspaces

> and working resources is that the latter work in their own configuration,

> a term that is nowhere defined by the way prior to section 9 of RFC
3253.



Actually, it is section 10.2 ... "Advanced Versioning
Terms".  Before then,

it was just used in an informal descriptive way, and
was not part of the protocol.



Since my repository supports workspaces, I did try
for quite a while to

convince the standards group that we only needed to
support workspaces, but

the reality is that there are repositories that do
not (and cannot) support

workspaces, but do support working resources, and
unless we defined

working resources support in the protocol, clients
would not be able to

interoperate in a useful way with those repositories.



> That makes it still possible to use workspaces in a client that would
have

> to resort to working resources. Workspaces are now positioned as a
pure

> server functionality. They are, however, an abstract mechanism that
can

> be perfectly implemented differently in a real server and in a stand-alone

> client. For the latter the implementation may be lighter because there
is

> perhaps no cuncurrency, making the preservation of integrity easier.
It

> is as if such a client has its own built-in server.



But from a protocol perspective, you cannot hide this
difference.  This is

in fact one of the major reasons why we started JSR-147,
which is a client-level

API rather than a client-server protocol.  In
JSR-147, there is only the

workspace model, because in a client API, you can
hide the implementation choice

of "fat client" (working-resource model)
or "skinny client" (workspace model)

under the client library layer that supports the JSR-147
API.



Cheers,

Geoff


--=_alternative 004CBE6F85257134_=--




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 10:25:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGpX-0005Kz-Gz
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:25:31 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKGpX-0002JU-70
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:25:31 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKGpE-0004lQ-Et
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 15:25:12 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKGp2-0004KF-RH
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 15:25:00 +0000
Received: from hoboe1bl1.telenet-ops.be ([195.130.137.72])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FKGos-0004YD-My
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 15:24:59 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by hoboe1bl1.telenet-ops.be (Postfix) with SMTP
	id 822CAD42A9; Fri, 17 Mar 2006 16:24:48 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by hoboe1bl1.telenet-ops.be (Postfix) with ESMTP
	id 00BDDD4198; Fri, 17 Mar 2006 16:24:48 +0100 (CET)
Message-ID: <441AD4CC.4060606@re.be>
Date: Fri, 17 Mar 2006 16:25:00 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manfred Baedke 
Cc: w3c-dist-auth@w3.org, geoffrey.clemm@us.ibm.com
References: <4419B9A7.4080205@greenbytes.de> <441A7622.3010508@re.be> <441ACE48.3010305@greenbytes.de>
In-Reply-To: <441ACE48.3010305@greenbytes.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (lisa.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FKGos-0004YD-My d207d5e89ee7aeb56649681eb8344dea
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441AD4CC.4060606@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12242
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 15:25:12 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8


Hi Manfred,

Manfred Baedke wrote:
> Hi Werner,
>=20
>> You have two alternatives for working in parallel, where one suffices.
>> One
>> method, working resources, exposes physical aspects such as forking an=
d
>> puts the resposibility for integrity at the client. The other is
>> abstract.
>> It doesn't expose implementation details, because each "branch" has it=
s
>> own VCR and the checked-in version of each VCR can be left to be the m=
ost
>> recent version. The integrity responsibility is within the server.
>>  =20
> First of all, checking out a working resource _does_ create a new VCR,
> much like a VERSION-CONTROL request to an unmapped URL which is a membe=
r
> URL of a workspace, the main difference being that in the latter case
> the client can choose the URL. Both mechanisms can be used to create
> multiple VCRs sharing a common version history and both can (but not
> must) be used in the way you describe (letting the checked-in version o=
f
> each VCR be the "end of a branch").

I have reread section 9 of RFC 3253 and I can't find prove of a VCR being
created for a working resource, but I'm misinterpreting something perhaps=
.

> I am still trying to understand what you mean when you speak of
> 'integrity'. Am I right that you propose, speaking loosely, that the
> 'original' VCR should belong to something like a 'main branch', its
> checked-in version always being the end of that branch, and that a new
> branch should be created by creating a new VCR (based on an 'old
> version') within a workspace?

Indeed, that is correct. With integrity I mean making sure that the
system is always in a consistent and predictable state. This is
normally achieved with transactions. Workspaces, being more abstract,
provide the opportunity for an "advanced" implementation to offer
such a guarantee. At the same time a less advanced implementation that
is deployed in a stand-alone environment, i.e. without concurrency
and the risk for races, can also comply to the workspaces specification.

Since the UPDATE method can change the checked-in version of a VCR
globally, the result may be unpredictable. (It will probably be
consistent, however, because the UPDATE method itself is normally
atomic.) This is because client may "forget" to use locking. If two
such clients are working concurrently on the same VCR, the checked-in
version may change in the middle of their scenario. They may end up
checking out from some other version without realising it. You can blame
those clients rightfully for it, but when there is a central system
it must make sure itself that this can't happen. The central system
can't rely on all clients to behave correctly.

Contrarily to what the spec suggests, I think it is simpler for both
client AND server if only workspaces are supported for working in
parallel.

> I you do so, feel free not to support the UPDATE feature in your
> implementation.

That is indeed possible, but I still would like to know where this
UPDATE and forking comes from and what purpose it serves. Turning it
the other way around, which problems would arise if it was left out?

>=20
> Regards,
> Manfred

Regards,

Werner.
--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 10:48:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHCD-0005D2-K2
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:48:57 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHCD-00036m-4j
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 10:48:57 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKHBj-0003ds-Fv
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 15:48:27 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKHBc-0003cq-5L
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 15:48:20 +0000
Received: from astra.telenet-ops.be ([195.130.132.58])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FKHBU-0003V0-40
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 15:48:19 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP
	id 3E7DCD0250; Fri, 17 Mar 2006 16:48:11 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by astra.telenet-ops.be (Postfix) with ESMTP
	id 8A9D5D015D; Fri, 17 Mar 2006 16:48:10 +0100 (CET)
Message-ID: <441ADA47.10606@re.be>
Date: Fri, 17 Mar 2006 16:48:23 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm 
Cc: webdav , manfred.baedke@greenbytes.de
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (maggie.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FKHBU-0003V0-40 20eaccc39d3aae0bd499609377175153
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441ADA47.10606@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12243
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 15:48:27 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75


Hi Geoff,

I understand now that there is in fact legacy to support, which is
fair enough. So Manfred doesn't have to answer the question in my
previous post anymore. The conclusion is important, because it
comes down to the choice whether an new server implementation wants
to support those older clients or not.

The JSR-147 initiative seems interesting. How does it relate to
JSR-170? Sections 4.10 and 4.11 of the latter may overlap.

Regards,

Werner.

Geoffrey M Clemm wrote:
>=20
> A few initial comments, and then additional comments in-line:
>=20
> The reason for supporting locking is not because locking is a good way
> to do parallel development on a versioning server (it isn't), but rathe=
r
> because there are a lot of WebDAV locking clients out there, and we
> want to ensure that they work as well as possible against a versioning
> server.  So when we argue that "locking works", we aren't saying that
> locking is a good way to solve this problem, but rather that if you hav=
e
> a locking client, it will interoperate well with a versioning server
> that supports the RFC-3253 versioning protocol.
>=20
> The reason for supporting working resources is not because it provides
> a good model for clients to work with (it doesn't), but rather that
> it provides a different distribution of work between the client and
> server.  In particular, with a workspace server, all of the work is
> being done on the server, which means clients are much simpler to write=
.
> With a working-resource server, a large part of the work has to be done
> on a client (effectively, the client implements a client-side
> workspace, using local persistent state on the client, and the
> low-level working-resource mechanisms provided by the server),
> but because the server (the shared resource) does
> significantly less work, it is actually much simpler to write a scalabl=
e
> system using the working-resource mechanism than it is to write one
> using the workspace mechanism.  This was the one architectural choice
> which we found we couldn't hide beneath a common protocol (and I can
> vouch for the fact that we tried very hard for a very long time to
> do so).
>=20
> In that context, some additional comments below:
>=20
>=20
> Werner wrote on 03/17/2006 03:41:06 AM:
>> Manfred Baedke wrote:
>> >
>> > So the checked-in version of the VCR changed. Every client (at least
>> > those who do not hold a lock) must be aware of this possibility at a=
ny
>> > time. Why should this be unexpected?
>>
>> Several clients can be executing such scenarios at the same time with =
the
>> same VCR. In order to avoid sudden changes of the checked-in version t=
hey
>> all have to use locking. Locking, however, is not mandatory, so it is =
up
>> to the clients to make sure there are no races. This is a co-operative
>> process.
>=20
> A single locking client on its own can ensure there are
> no races by taking out the lock.  An attempt to modify this resource by
> any method (PUT, UPDATE, MERGE) by another client will fail while the
> client
> has the lock.  The only time co-operation is required is amoung a group=
 of
> non-locking clients ... but in this case they use etags, which will als=
o
> work against a versioning server.  To emphasize the point made above,
> this is
> not an argument that locking the VCR is a good way to handle this
> problem ...
> it is an argument that existing locking clients will interoperate in a
> reasonable
> way with a server that supports RFC-3253.
>=20
>> It is like saying that multiple clients can update tables in a
>> database, but they have to manage table or record locking themselves. =
It
>> was like that decades ago.
>=20
> Yes, but if you have thousands of deployed clients (written years ago
> when there was no workspace protocol) that do this table and
> record locking management, it is a very good thing if they will just wo=
rk
> unmodified against the new versioning servers.
>=20
>> The forking and update mechanisms require isolation and locking is not
>> the good instrument for that. Workspaces achieve concurrency in a natu=
ral
>> way without imposing co-operative scenarios with locking. This is both
>> safer and simpler.
>=20
> Totally agree.  Newer clients that take advantage of the workspace prot=
ocol
> will be much easier to write than it was to write the older clients tha=
t
> only
> could use the locking protocol.
>=20
>> >> Regarding the lock release the timeout mechanism is not good enough=
 if
>> >> locking is used like that, because VCR is blocked too long. This
> impacts
>> >> concurrency severely. When a transaction fails, for example, everyt=
hing
>> >> is rolled back and release immediately.
>> >
>> > Yes, long lasting exclusive locks are evil. Again, why not use
>> > workspaces or working resources?
>>
>> They are not evil if the repository supports branching. It is common t=
o
>> reserve a branch, because branches are a tool to let people work toget=
her
>> on the same topic. Long-lasting locks should not be used on the
> integration
>> branch in which all work will be merged.
>=20
> A branch is modeled in the WebDAV protocol as an "activity".  Note that
> we use the term "reserve" for what you do to a branch, to avoid
> confusion with the
> "lock" protocol.  The lock protocol was not used for reserving branches=
,
> because we didn't want the client to have to maintain lock tokens for t=
he
> branch they are working on.
>=20
>> > Please explain in detail where you see inconsistencies. I can only s=
ee a
>> > non-linear version history so far, which is perfectly consistent.
>>
>> You have two alternatives for working in parallel, where one suffices.=
 One
>> method, working resources, exposes physical aspects such as forking an=
d
>> puts the resposibility for integrity at the client. The other is abstr=
act.
>> It doesn't expose implementation details, because each "branch" has it=
s
>> own VCR and the checked-in version of each VCR can be left to be the m=
ost
>> recent version. The integrity responsibility is within the server.
>=20
> Yes, I agree that the workspace protocol allows for much simpler client=
s
> to be written.
>=20
>> The only functional difference there is supposed to be between workspa=
ces
>> and working resources is that the latter work in their own configurati=
on,
>> a term that is nowhere defined by the way prior to section 9 of RFC 32=
53.
>=20
> Actually, it is section 10.2 ... "Advanced Versioning Terms".  Before t=
hen,
> it was just used in an informal descriptive way, and was not part of th=
e
> protocol.
>=20
> Since my repository supports workspaces, I did try for quite a while to
> convince the standards group that we only needed to support workspaces,=
 but
> the reality is that there are repositories that do not (and cannot) sup=
port
> workspaces, but do support working resources, and unless we defined
> working resources support in the protocol, clients would not be able to
> interoperate in a useful way with those repositories.
>=20
>> That makes it still possible to use workspaces in a client that would =
have
>> to resort to working resources. Workspaces are now positioned as a pur=
e
>> server functionality. They are, however, an abstract mechanism that ca=
n
>> be perfectly implemented differently in a real server and in a stand-a=
lone
>> client. For the latter the implementation may be lighter because there=
 is
>> perhaps no cuncurrency, making the preservation of integrity easier. I=
t
>> is as if such a client has its own built-in server.
>=20
> But from a protocol perspective, you cannot hide this difference.  This=
 is
> in fact one of the major reasons why we started JSR-147, which is a
> client-level
> API rather than a client-server protocol.  In JSR-147, there is only th=
e
> workspace model, because in a client API, you can hide the
> implementation choice
> of "fat client" (working-resource model) or "skinny client" (workspace
> model)
> under the client library layer that supports the JSR-147 API.
>=20
> Cheers,
> Geoff

--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 11:08:05 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHUj-0005Lb-So
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:08:05 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHUi-0003oh-8k
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:08:05 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKHTw-0000MN-0i
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 16:07:16 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKHTo-0000L7-3n
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 16:07:08 +0000
Received: from e2.ny.us.ibm.com ([32.97.182.142])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKHTd-0000o2-B7
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 16:07:07 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2HG6qJN028325
	for ; Fri, 17 Mar 2006 11:06:52 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2HG6qR5138060
	for ; Fri, 17 Mar 2006 11:06:52 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2HG6pHg005740
	for ; Fri, 17 Mar 2006 11:06:52 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2HG6p8f005735;
	Fri, 17 Mar 2006 11:06:51 -0500
In-Reply-To: <441AD4CC.4060606@re.be>
To: werner.donne@re.be
Cc: Manfred Baedke , w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Fri, 17 Mar 2006 11:06:58 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/17/2006 11:06:51,
	Serialize complete at 03/17/2006 11:06:51
Content-Type: multipart/alternative; boundary="=_alternative 0058853685257134_="
Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: aji.w3.org 1FKHTd-0000o2-B7 5f8f70ee2a36248a480e89d74bdade4c
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/OF18CA510E.A10ECA53-ON85257134.00565258-85257134.005886ED@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12244
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 16:07:16 +0000
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 410b68b37343617c6913e76d02180b14


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

Werner Donn=E9  wrote on 03/17/2006 10:25:00 AM:
> Manfred Baedke wrote:
> > First of all, checking out a working resource =5Fdoes=5F create a new V=
CR,
> > much like a VERSION-CONTROL request to an unmapped URL which is a=20
member
> > URL of a workspace, the main difference being that in the latter case
> > the client can choose the URL. Both mechanisms can be used to create
> > multiple VCRs sharing a common version history and both can (but not
> > must) be used in the way you describe (letting the checked-in version=20
of
> > each VCR be the "end of a branch").
>=20
> I have reread section 9 of RFC 3253 and I can't find prove of a VCR=20
being
> created for a working resource, but I'm misinterpreting something=20
perhaps.

Manfred's description isn't quite right ... you don't check out a working
resource ... you create a working resource by checking out a version.
You then update the working resource (with PUT) and check it in, which
deletes the working resource and creates a new version.  So Werner is=20
correct
that there are two distinct ways of working.
The workspace way:
- you apply CHECKOUT to a VCR, which makes the VCR writeable
- you update the VCR with PUT
- you apply CHECKIN to the VCR, which creates a new version and makes the=20
VCR
  unwriteable.
The working resource way:
- you apply CHECKOUT to a version, which creates a new working resource
- you update the working resource with PUT
- you apply CHECKIN to the working resource, which creates a new version=20
and
  deletes the working resource.

> > I am still trying to understand what you mean when you speak of
> > 'integrity'. Am I right that you propose, speaking loosely, that the
> > 'original' VCR should belong to something like a 'main branch', its
> > checked-in version always being the end of that branch, and that a new
> > branch should be created by creating a new VCR (based on an 'old
> > version') within a workspace?
>=20
> Indeed, that is correct. With integrity I mean making sure that the
> system is always in a consistent and predictable state. This is
> normally achieved with transactions. Workspaces, being more abstract,
> provide the opportunity for an "advanced" implementation to offer
> such a guarantee. At the same time a less advanced implementation that
> is deployed in a stand-alone environment, i.e. without concurrency
> and the risk for races, can also comply to the workspaces specification.

Or with the working resource model, the state of the transaction is
basically the set of working resources currently held by the client.
Those working resources are effectively private to that client, and
therefore no other client can interfere with the transaction.  Much
lower level than workspaces, more work/complexity for the client, but much =

lower
overhead on the server.

> Since the UPDATE method can change the checked-in version of a VCR
> globally, the result may be unpredictable. (It will probably be
> consistent, however, because the UPDATE method itself is normally
> atomic.) This is because client may "forget" to use locking. If two
> such clients are working concurrently on the same VCR, the checked-in
> version may change in the middle of their scenario. They may end up
> checking out from some other version without realising it. You can blame
> those clients rightfully for it, but when there is a central system
> it must make sure itself that this can't happen. The central system
> can't rely on all clients to behave correctly.

Yes, the workspace model is the simple/clean way to achieve this.
The locking model is the "works with existing clients" approach.

> Contrarily to what the spec suggests, I think it is simpler for both
> client AND server if only workspaces are supported for working in
> parallel.

The working resource model is worse for the client than the workspace
model, but is significantly better than locking and a scalable
working resource server is significantly easier to implement than
a scalable workspace server.

> > I you do so, feel free not to support the UPDATE feature in your
> > implementation.
>=20
> That is indeed possible, but I still would like to know where this
> UPDATE and forking comes from and what purpose it serves. Turning it
> the other way around, which problems would arise if it was left out?

If your server does not support workspaces, then the only real benefit
of UPDATE is that it allows you to avoid creating a new version when
a client wants to restore an old version.  In particular,
if you don't support UPDATE, then the only way that your client can
tell the server that it wants to change the state back to that of some
previous version is to GET the content of the desired version,
CHECKOUT the VCR, PUT the content it got, and then CHECKIN, which creates
a new version (which is a copy of an existing version).  With UPDATE,
you can just send an UPDATE request to the server, with the URL of the
desired version (which both avoids creating a new version, and avoids
streaming the content back to the client via GET and then back to the
server via PUT).

Cheers,
Geoff




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



Werner Donn=E9 <werner.donne@re.be> wrote on 0=
3/17/2006
10:25:00 AM:

> Manfred Baedke wrote:

> > First of all, checking out a working resource =5Fdoes=5F create a
new VCR,

> > much like a VERSION-CONTROL request to an unmapped URL which
is a member

> > URL of a workspace, the main difference being that in the latter
case

> > the client can choose the URL. Both mechanisms can be used to
create

> > multiple VCRs sharing a common version history and both can (but
not

> > must) be used in the way you describe (letting the checked-in
version of

> > each VCR be the "end of a branch").

> 

> I have reread section 9 of RFC 3253 and I can't find prove of a VCR
being

> created for a working resource, but I'm misinterpreting something
perhaps.



Manfred's description isn't quite right ... you don't
check out a working

resource ... you create a working resource by checki=
ng
out a version.

You then update the working resource (with PUT) and
check it in, which

deletes the working resource and creates a new versi=
on.
 So Werner is correct

that there are two distinct ways of working.

The workspace way:

- you apply CHECKOUT to a VCR, which makes the VCR
writeable

- you update the VCR with PUT

- you apply CHECKIN to the VCR, which creates a new
version and makes the VCR

  unwriteable.

The working resource way:

- you apply CHECKOUT to a version, which creates a
new working resource

- you update the working resource with PUT

- you apply CHECKIN to the working resource, which
creates a new version and

  deletes the working resource.



> > I am still trying to understand what you mean when you speak
of

> > 'integrity'. Am I right that you propose, speaking loosely, that
the

> > 'original' VCR should belong to something like a 'main branch',
its

> > checked-in version always being the end of that branch, and that
a new

> > branch should be created by creating a new VCR (based on an 'old<=
br>
> > version') within a workspace?

> 

> Indeed, that is correct. With integrity I mean making sure that the

> system is always in a consistent and predictable state. This is

> normally achieved with transactions. Workspaces, being more abstract,<=
br>
> provide the opportunity for an "advanced" implementation
to offer

> such a guarantee. At the same time a less advanced implementation
that

> is deployed in a stand-alone environment, i.e. without concurrency

> and the risk for races, can also comply to the workspaces specificatio=
n.



Or with the working resource model, the state of the
transaction is

basically the set of working resources currently held
by the client.

Those working resources are effectively private to
that client, and

therefore no other client can interfere with the tra=
nsaction.
 Much

lower level than workspaces, more work/complexity
for the client, but much lower

overhead on the server.



> Since the UPDATE method can change the checked-in version of a VCR

> globally, the result may be unpredictable. (It will probably be

> consistent, however, because the UPDATE method itself is normally

> atomic.) This is because client may "forget" to use locking.
If two

> such clients are working concurrently on the same VCR, the checked-in<=
br>
> version may change in the middle of their scenario. They may end up

> checking out from some other version without realising it. You can
blame

> those clients rightfully for it, but when there is a central system

> it must make sure itself that this can't happen. The central system

> can't rely on all clients to behave correctly.



Yes, the workspace model is the simple/clean way to
achieve this.

The locking model is the "works with existing
clients" approach.



> Contrarily to what the spec suggests, I think it is simpler for both
> client AND server if only workspaces are supported for working in

> parallel.



The working resource model is worse for the client
than the workspace

model, but is significantly better than locking and
a scalable

working resource server is significantly easier to
implement than

a scalable workspace server.



> > I you do so, feel free not to support the
UPDATE feature in your

> > implementation.

> 

> That is indeed possible, but I still would like to know where this

> UPDATE and forking comes from and what purpose it serves. Turning
it

> the other way around, which problems would arise if it was left out?


If your server does not support workspaces, then the
only real benefit

of UPDATE is that it allows you to avoid creating
a new version when

a client wants to restore an old version.  In
particular,

if you don't support UPDATE, then the only way that
your client can

tell the server that it wants to change the state
back to that of some

previous version is to GET the content of the desired
version,

CHECKOUT the VCR, PUT the content it got, and then
CHECKIN, which creates

a new version (which is a copy of an existing versio=
n).
 With UPDATE,

you can just send an UPDATE request to the server,
with the URL of the

desired version (which both avoids creating a new
version, and avoids

streaming the content back to the client via GET and
then back to the

server via PUT).



Cheers,

Geoff








--=_alternative 0058853685257134_=--




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 11:17:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHdT-00086s-U1
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:17:07 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHdT-0004D5-K8
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:17:07 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKHdA-00047J-Mm
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 16:16:48 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKHd3-00043h-7J
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 16:16:41 +0000
Received: from e6.ny.us.ibm.com ([32.97.182.146])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKHcu-0002Vv-TL
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 16:16:39 +0000
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2HGGUfS015147
	for ; Fri, 17 Mar 2006 11:16:30 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2HGGUvj045768
	for ; Fri, 17 Mar 2006 11:16:30 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2HGGUXw009501
	for ; Fri, 17 Mar 2006 11:16:30 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2HGGU8C009495
	for ; Fri, 17 Mar 2006 11:16:30 -0500
In-Reply-To: <441ADA47.10606@re.be>
To: " webdav" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Fri, 17 Mar 2006 11:16:37 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/17/2006 11:16:29,
	Serialize complete at 03/17/2006 11:16:29
Content-Type: multipart/alternative; boundary="=_alternative 005967C285257134_="
Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: aji.w3.org 1FKHcu-0002Vv-TL 58c7d8519f669aa67c612aeab01c0140
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/OF66620861.4EAC277F-ON85257134.00589548-85257134.005968DD@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12245
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 16:16:48 +0000
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac


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

Werner wrote on 03/17/2006 10:48:23 AM:

> I understand now that there is in fact legacy to support, which is
> fair enough. So Manfred doesn't have to answer the question in my
> previous post anymore.

Yes, the design of WebDAV versioning was especially challenging since
we were concerned both with legacy WebDAV clients, and legacy versioning
repositories, in addition to wanting to define a "good model" for
the future.

> The conclusion is important, because it
> comes down to the choice whether an new server implementation wants
> to support those older clients or not.

That is exactly right.

> The JSR-147 initiative seems interesting. How does it relate to
> JSR-170? Sections 4.10 and 4.11 of the latter may overlap.

Being semantically compatible with JSR-147 was an explicit goal of 
JSR-170.
We are currently considering adding the more advanced semantics of JSR-147
(activities, baselines) into JSR-283, the next version of JSR-170.

Cheers,
Geoff



--=_alternative 005967C285257134_=
Content-Type: text/html; charset="US-ASCII"



Werner wrote on 03/17/2006 10:48:23 AM:



> I understand now that there is in fact legacy
to support, which is

> fair enough. So Manfred doesn't have to answer the question in my

> previous post anymore.



Yes, the design of WebDAV versioning was especially
challenging since

we were concerned both with legacy WebDAV clients,
and legacy versioning

repositories, in addition to wanting to define a "good
model" for

the future.



> The conclusion is important, because it

> comes down to the choice whether an new server implementation wants

> to support those older clients or not.



That is exactly right.



> The JSR-147 initiative seems interesting. How does it relate to

> JSR-170? Sections 4.10 and 4.11 of the latter may overlap.



Being semantically compatible with JSR-147 was an
explicit goal of JSR-170.

We are currently considering adding the more advanced
semantics of JSR-147

(activities, baselines) into JSR-283, the next version
of JSR-170.



Cheers,

Geoff






--=_alternative 005967C285257134_=--




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 11:34:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHud-0004PD-E7
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:34:51 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKHub-0004sn-5k
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 11:34:51 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKHuE-0000Y6-Ed
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 16:34:26 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKHu3-0000VD-38
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 16:34:15 +0000
Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de)
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FKHtz-0004vD-O1
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 16:34:14 +0000
Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 247144991A;
	Fri, 17 Mar 2006 17:34:07 +0100 (CET)
Message-ID: <441AE506.3070602@greenbytes.de>
Date: Fri, 17 Mar 2006 17:34:14 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Geoffrey M Clemm 
CC:  werner.donne@re.be,  w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (maggie.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FKHtz-0004vD-O1 a17f1bdf34809fd715aaadd064bf9f15
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441AE506.3070602@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12246
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 16:34:26 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007


Hi,

>  >
>  > I have reread section 9 of RFC 3253 and I can't find prove of a VCR being
>  > created for a working resource, but I'm misinterpreting something 
> perhaps.
> 
> Manfred's description isn't quite right ... you don't check out a working
> resource ... you create a working resource by checking out a version.

This is of course true.

> You then update the working resource (with PUT) and check it in, which
> deletes the working resource and creates a new version.  So Werner is 
> correct

My point was that the working resource itself is a VCR, whose deletion 
on a subsequent CHECKIN can be avoided using the DAV:keep-checked-out 
flag, in which case the working resource behaves much like any other VCR.

Regards,
Manfred




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 14:33:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKKhF-0005V4-5a
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 14:33:13 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKKhE-0002a8-SG
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 14:33:13 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKKgL-0007a1-Qw
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 19:32:17 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKKgE-0007Xj-Ik
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 19:32:10 +0000
Received: from e1.ny.us.ibm.com ([32.97.182.141])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FKKg7-0005qX-0k
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 19:32:09 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2HJW2AS002088
	for ; Fri, 17 Mar 2006 14:32:02 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2HJW2R5046456
	for ; Fri, 17 Mar 2006 14:32:02 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2HJW1JS027410
	for ; Fri, 17 Mar 2006 14:32:02 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2HJW1ww027405;
	Fri, 17 Mar 2006 14:32:01 -0500
In-Reply-To: <441AE506.3070602@greenbytes.de>
To: Manfred Baedke 
Cc: w3c-dist-auth@w3.org, werner.donne@re.be
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Fri, 17 Mar 2006 14:32:07 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/17/2006 14:32:01,
	Serialize complete at 03/17/2006 14:32:01
Content-Type: multipart/alternative; boundary="=_alternative 006B4D7105257134_="
Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: lisa.w3.org 1FKKg7-0005qX-0k 04f5b86b068bf5a9b93c6bce51ade70a
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/OF078249AB.17C3C201-ON85257134.006AEA1C-05257134.006B4EF8@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12247
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 19:32:17 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15


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

Manfred Baedke  wrote on 03/17/2006 11:34:14 
AM:

> My point was that the working resource itself is a VCR, whose deletion 
> on a subsequent CHECKIN can be avoided using the DAV:keep-checked-out 
> flag, in which case the working resource behaves much like any other 
VCR.

Well, to be precise, a working resource is a "checked-out resource".
A checked-out VCR is also a checked-out resource,
but although both a working resource and a checked-out VCR share 
properties
and methods (i.e., all the properties and methods of a checked-out 
resource),
a working resource is actually not a VCR (in particular, a VCR has 
properties
that a working resource does not have).

Cheers,
Geoff




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



Manfred Baedke <manfred.baedke@greenbytes.de>
wrote on 03/17/2006 11:34:14 AM:



> My point was that the working resource itself is a VCR, whose deletion


> on a subsequent CHECKIN can be avoided using the DAV:keep-checked-out


> flag, in which case the working resource behaves much like any other
VCR.



Well, to be precise, a working resource is a "checked-out
resource".

A checked-out VCR is also a checked-out resource,

but although both a working resource and a checked-out
VCR share properties

and methods (i.e., all the properties and methods
of a checked-out resource),

a working resource is actually not a VCR (in particular,
a VCR has properties

that a working resource does not have).



Cheers,

Geoff








--=_alternative 006B4D7105257134_=--




From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 15:46:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKLqA-0006aP-P0
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 15:46:30 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKLq9-0004pT-Gn
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 15:46:30 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKLod-0007CZ-Cj
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 20:44:55 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKLoT-00079g-LJ
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 20:44:45 +0000
Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de)
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKLoL-0002ni-Fi
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 20:44:44 +0000
Received: from [192.168.0.100] (port-83-236-26-84.dynamic.qsc.de [83.236.26.84])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 647C42EA89;
	Fri, 17 Mar 2006 21:44:30 +0100 (CET)
Message-ID: <441B1FB5.1030709@greenbytes.de>
Date: Fri, 17 Mar 2006 21:44:37 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Geoffrey M Clemm 
CC:  w3c-dist-auth@w3.org,  werner.donne@re.be
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (aji.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1FKLoL-0002ni-Fi 33699eb1ffe7f92b79f91d23dc2ce877
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/441B1FB5.1030709@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12248
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 20:44:55 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f


Geoff,

again you are right.
The reason for my confusion is that in our implementation (i.e. SAP 
Netweaver) a working resource _is_ a version controlled resource. I will 
have to meditate about this being a bug or just an implementation detail.

Regards,
Manfred

Geoffrey M Clemm wrote:
> 
> Manfred Baedke  wrote on 03/17/2006 
> 11:34:14 AM:
> 
>  > My point was that the working resource itself is a VCR, whose deletion
>  > on a subsequent CHECKIN can be avoided using the DAV:keep-checked-out
>  > flag, in which case the working resource behaves much like any other 
> VCR.
> 
> Well, to be precise, a working resource is a "checked-out resource".
> A checked-out VCR is also a checked-out resource,
> but although both a working resource and a checked-out VCR share properties
> and methods (i.e., all the properties and methods of a checked-out 
> resource),
> a working resource is actually not a VCR (in particular, a VCR has 
> properties
> that a working resource does not have).
> 
> Cheers,
> Geoff
> 
> 
> 





From w3c-dist-auth-request@listhub.w3.org Fri Mar 17 16:44:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKMjx-0001FF-O9
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 16:44:09 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKMjx-0006YM-CF
	for webdav-archive@lists.ietf.org; Fri, 17 Mar 2006 16:44:09 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKMjV-0005Ik-Lf
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Mar 2006 21:43:41 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKMjM-0005Ez-JJ
	for w3c-dist-auth@listhub.w3.org; Fri, 17 Mar 2006 21:43:33 +0000
Received: from e6.ny.us.ibm.com ([32.97.182.146])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FKMjF-0002Z4-GD
	for w3c-dist-auth@w3.org; Fri, 17 Mar 2006 21:43:31 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2HLhBXW021281
	for ; Fri, 17 Mar 2006 16:43:11 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2HLh0R5053584
	for ; Fri, 17 Mar 2006 16:43:00 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2HLh0u7022579
	for ; Fri, 17 Mar 2006 16:43:00 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2HLh0ca022570
	for ; Fri, 17 Mar 2006 16:43:00 -0500
In-Reply-To: <441B1FB5.1030709@greenbytes.de>
To: " webdav" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Fri, 17 Mar 2006 16:43:05 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/17/2006 16:42:59,
	Serialize complete at 03/17/2006 16:42:59
Content-Type: multipart/alternative; boundary="=_alternative 00774BFD85257134_="
Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: aji.w3.org 1FKMjF-0002Z4-GD 8454d7c079a1f51798bb6d85d9536531
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: UPDATE method and forking
X-Archived-At: http://www.w3.org/mid/OF6619BBF6.EF580AE0-ON85257134.0076F2BC-85257134.00774C97@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12249
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 17 Mar 2006 21:43:41 +0000
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c


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

I would call this an implementation detail, and definitely not call
it a bug.  All it means is that working resources have more properties
in your system than the standard requires.

Also, since that is exactly what we would have done if we had
supported working resources on our workspace-based server (basically,
just allocating the working resources in some system-maintained
workspace), I consider it a very sensible implementation choice (:-).

Cheers,
Geoff


Manfred Baedke  wrote on 03/17/2006 03:44:37 
PM:

> Geoff,
> 
> again you are right.
> The reason for my confusion is that in our implementation (i.e. SAP 
> Netweaver) a working resource _is_ a version controlled resource. I will 

> have to meditate about this being a bug or just an implementation 
detail.
> 
> Regards,
> Manfred
> 
> Geoffrey M Clemm wrote:
> > 
> > Manfred Baedke  wrote on 03/17/2006 
> > 11:34:14 AM:
> > 
> >  > My point was that the working resource itself is a VCR, whose 
deletion
> >  > on a subsequent CHECKIN can be avoided using the 
DAV:keep-checked-out
> >  > flag, in which case the working resource behaves much like any 
other 
> > VCR.
> > 
> > Well, to be precise, a working resource is a "checked-out resource".
> > A checked-out VCR is also a checked-out resource,
> > but although both a working resource and a checked-out VCR share 
properties
> > and methods (i.e., all the properties and methods of a checked-out 
> > resource),
> > a working resource is actually not a VCR (in particular, a VCR has 
> > properties
> > that a working resource does not have).
> > 
> > Cheers,
> > Geoff
> > 
> > 
> > 
> 

--=_alternative 00774BFD85257134_=
Content-Type: text/html; charset="US-ASCII"



I would call this an implementation detail, and definitely
not call

it a bug.  All it means is that working resources
have more properties

in your system than the standard requires.



Also, since that is exactly what we would have done
if we had

supported working resources on our workspace-based
server (basically,

just allocating the working resources in some system-maintained

workspace), I consider it a very sensible implementation
choice (:-).



Cheers,

Geoff





Manfred Baedke <manfred.baedke@greenbytes.de>
wrote on 03/17/2006 03:44:37 PM:



> Geoff,

> 

> again you are right.

> The reason for my confusion is that in our implementation (i.e. SAP


> Netweaver) a working resource _is_ a version controlled resource.
I will 

> have to meditate about this being a bug or just an implementation
detail.

> 

> Regards,

> Manfred

> 

> Geoffrey M Clemm wrote:

> > 

> > Manfred Baedke <manfred.baedke@greenbytes.de> wrote on
03/17/2006 

> > 11:34:14 AM:

> > 

> >  > My point was that the working resource itself is a
VCR, whose deletion

> >  > on a subsequent CHECKIN can be avoided using the DAV:keep-checked-out

> >  > flag, in which case the working resource behaves much
like any other 

> > VCR.

> > 

> > Well, to be precise, a working resource is a "checked-out
resource".

> > A checked-out VCR is also a checked-out resource,

> > but although both a working resource and a checked-out VCR share
properties

> > and methods (i.e., all the properties and methods of a checked-out


> > resource),

> > a working resource is actually not a VCR (in particular, a VCR
has 

> > properties

> > that a working resource does not have).

> > 

> > Cheers,

> > Geoff

> > 

> > 

> > 

> 


--=_alternative 00774BFD85257134_=--




From w3c-dist-auth-request@listhub.w3.org Sat Mar 18 12:51:42 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKfaY-0005H3-DM
	for webdav-archive@lists.ietf.org; Sat, 18 Mar 2006 12:51:42 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKfaX-0001P5-58
	for webdav-archive@lists.ietf.org; Sat, 18 Mar 2006 12:51:42 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FKfZQ-0001FE-0b
	for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Mar 2006 17:50:32 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FKfZH-0001EZ-Gh
	for w3c-dist-auth@listhub.w3.org; Sat, 18 Mar 2006 17:50:23 +0000
Received: from mail.gmx.net ([213.165.64.20])
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FKfZA-0004IG-Cj
	for w3c-dist-auth@w3.org; Sat, 18 Mar 2006 17:50:23 +0000
Received: (qmail invoked by alias); 18 Mar 2006 17:43:35 -0000
Received: from p508F85E1.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.133.225]
  by mail.gmx.net (mp020) with SMTP; 18 Mar 2006 18:43:35 +0100
X-Authenticated: #1915285
Message-ID: <441C4676.2080507@gmx.de>
Date: Sat, 18 Mar 2006 18:42:14 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Bernard Desruisseaux 
CC: CalDAV DevList , 
 Calsify WG ,
 WebDAV WG , Ted Hardie 
References: <43FD273E.3020702@oracle.com> <440D8CFC.3040706@oracle.com> <4418CF08.7090300@oracle.com>
In-Reply-To: <4418CF08.7090300@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FKfZA-0004IG-Cj 1feff07e8cbd117d2af257ec7846441f
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
X-Archived-At: http://www.w3.org/mid/441C4676.2080507@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12250
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Sat, 18 Mar 2006 17:50:32 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1


Bernard Desruisseaux wrote:
> 
> I thought it would be worthwhile to update everybody on the
> changes we are planning to make in draft -11 based on the
> issues that have been brought up so far:
> 
> - Added new preconditions:
>    * CALDAV:number-of-recurrences-within-limits for PUT;
>    * CALDAV:calendar-collection-location-ok for MOVE and COPY.
> - Redefined the CALDAV:no-uid-conflict precondition.
> - Minor editorial changes.
> - Update to references.
> - Added element CALDAV:is-not-defined.
> - Added new attribute "negate-condition" to the
>   CALDAV:text-match element.
> 
> The last two changes were required to be able to query the to-dos
> that are *not* completed and *not* cancelled. The issue is that
> the CALDAV:calendar-query REPORT does not provide support for a
> "not" operator. To be able to address the above use case without
> increasing the complexity of the CALDAV:calendar-query REPORT
> significantly we have decided to add a new condition "is-not-defined" 
> and to add a "negate-condition" attribute to be able to negate the
> "text-match" condition.
> ...

Bernard,

so did you consider whether CalDAV is going to be based on RFC2518 or on 
RFC2518bis? That is, would a CalDAV client be able to rely on 
RFC2518bis, or would they need to interact with both kinds of servers?

Are CalDAV server implementors implementing RFC2518bis (or are they 
planning to)?

Best regards, Julian




From miroslvazguez@bbsltd.co.uk Sat Mar 18 12:57:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKffz-00063E-QX
	for webdav-archive@ietf.org; Sat, 18 Mar 2006 12:57:19 -0500
Received: from [219.130.154.45] (helo=bbsltd.co.uk)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FKffx-0001d6-9J
	for webdav-archive@ietf.org; Sat, 18 Mar 2006 12:57:19 -0500
Message-ID: <000001c64ab5$5426e910$80c3a8c0@cpw73>
Reply-To: "Miroslav Vazguez" 
From: "Miroslav Vazguez" 
To: webdav-archive@ietf.org
Subject: Re: P2Eharamacy news
Date: Sat, 18 Mar 2006 12:56:48 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C64A8B.6B50E110"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 1.0 (+)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C64A8B.6B50E110
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
f C s i b a f I e i o s $9 o 9 ( U9 10  r p y i i l n l r s m )
h V s a m I k i a u g m $1 h 05 (30 HM   j p i i r l v l y s b )
m V j i j a y g o r j a $ n 69 (10 Dt   g p h i q l n l b s y )
=20
M q1 any other, Vi 7C sit our s A9 ite 
and Sav G5 e o S8 ver 50 Vq %

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









 


 f C s i b a f I e i o s $9 o 9 ( U9 10  r p y i i l n l r s m )


 h V s a m I k i a u g m $1 h 05 (30 HM   j p i i r l v l y s b )


 m V j i j a y g o r j a $ n 69 (10 Dt   g p h i q l n l b s y )


 


M q1 any other, Vi 7C sit our s A9 ite and Sav G5 e o S8 ver 50 Vq %

------=_NextPart_000_0001_01C64A8B.6B50E110--






From jauregi@atm.cyberec.com Sun Mar 19 14:41:15 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL3m7-0006wZ-89
	for webdav-archive@ietf.org; Sun, 19 Mar 2006 14:41:15 -0500
Received: from 88-136-2-247.adslgp.cegetel.net ([88.136.2.247] helo=atm.cyberec.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FL3m5-0007CO-Kh
	for webdav-archive@ietf.org; Sun, 19 Mar 2006 14:41:15 -0500
Message-ID: <000001c64b8d$0cb8afe0$0f10a8c0@jmc98>
Reply-To: "Shereen Jauregui" 
From: "Shereen Jauregui" 
To: webdav-archive@ietf.org
Subject: Re: news
Date: Sun, 19 Mar 2006 14:41:00 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C64B63.23E2A7E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Antivirus: avast! (VPS 0611-2, 17/03/2006), Outbound message
X-Antivirus-Status: Clean
X-Spam-Score: 2.3 (++)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C64B63.23E2A7E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Do you want to t O l V n E x R u P i A q Y for your r M q e m d c i b a
j c t t u i b o o n b s?
=20
Nothing like you need it, c S c a k v m e over m 5 a 0 k % with
http://aima38.tenbakcolloid.com

------=_NextPart_000_0001_01C64B63.23E2A7E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi,


 


Do you want to  t O l V n E x R u P i A q Y for your  r M q e m d c i b a j c t t u i b o o n b s?


 


Nothing like you need it,  c S c a k v m e over  m 5 a 0 k % with http://aima38.tenbakcolloid.com<=
/A>

------=_NextPart_000_0001_01C64B63.23E2A7E0--






From w3c-dist-auth-request@listhub.w3.org Sun Mar 19 15:47:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL4oe-0002UL-4A
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 15:47:56 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL4oc-0001Sk-QI
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 15:47:56 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FL4mw-00072j-KK
	for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Mar 2006 20:46:10 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FL4mn-00071c-PA
	for w3c-dist-auth@listhub.w3.org; Sun, 19 Mar 2006 20:46:01 +0000
Received: from mail.gmx.net ([213.165.64.20])
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FL4mk-0002Ja-Tc
	for w3c-dist-auth@w3.org; Sun, 19 Mar 2006 20:46:01 +0000
Received: (qmail invoked by alias); 19 Mar 2006 20:45:57 -0000
Received: from p508FA73A.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.167.58]
  by mail.gmx.net (mp028) with SMTP; 19 Mar 2006 21:45:57 +0100
X-Authenticated: #1915285
Message-ID: <441DC2AB.7070901@gmx.de>
Date: Sun, 19 Mar 2006 21:44:27 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Geoffrey M Clemm 
CC: Kevin Wiggen ,  w3c-dist-auth@w3.org, 
 w3c-dist-auth-request@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FL4mk-0002Ja-Tc 391d989e07aa51b044f4d1e1b80c1162
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/441DC2AB.7070901@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12251
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Sun, 19 Mar 2006 20:46:10 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793


Geoffrey M Clemm wrote:
> 
> +1 from me as well.  I believe Kevin's paragraph addresses the key
> confusions around DAV:displayname.
> 
> Cheers,
> Geoff

OK, I have opened an issue for proposed changes to DAV:displayname, see 
.

The proposed changes are:

Section 15.2., para. 6:
OLD:

     Description:   The DAV:displayname property should be defined on all
       DAV compliant resources.  If present, the property contains a
       description of the resource that is suitable for presentation to a
       user.  This property is defined on the resource, and hence SHOULD
       have the same value independent of the Request-URI used to
       retrieve it (thus computing this property based on the Request-URI
       is deprecated).

NEW:

     Description:   The property contains a description of the resource
       that is suitable for presentation to a user.  This property is
       defined on the resource, and hence SHOULD have the same value
       independent of the Request-URI used to retrieve it (thus computing
       this property based on the Request-URI is deprecated).

       Servers and clients must understand that the method for
       identifying resources is still the URL.  While generic clients
       will be able to display DAV:displayname to end users, both sides
       of the protocol must understand that if users are allowed to
       perform operations such as rename, move, copy etc, generic clients
       must display the URLs (or the path segments used in the displayed
       collection) to allow these operations.  Changes to DAV:displayname
       do not issue moves or copies to the server, but simply change a
       piece of meta-data on the individual resource.


1) Take out the statement "The DAV:displayname property should be 
defined on all DAV compliant resources." - that doesn't make any sense 
at all. If a server doesn't know a good displayname, it shouldn't return 
one.

2) Incorporate text based on Kevin's suggestion.

Best regards, Julian




From w3c-dist-auth-request@listhub.w3.org Sun Mar 19 17:45:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FL6el-0004cW-EN
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 17:45:51 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FL6el-0006B0-27
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 17:45:51 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FL6dj-0002Sx-Hi
	for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Mar 2006 22:44:47 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FL6db-0002SE-19
	for w3c-dist-auth@listhub.w3.org; Sun, 19 Mar 2006 22:44:39 +0000
Received: from bandage.seagull.net ([67.136.24.2])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FL6dT-0007k7-1D
	for w3c-dist-auth@w3.org; Sun, 19 Mar 2006 22:44:38 +0000
Received: (mail@localhost) by bandage.seagull.net (8.13.3) id k2JMiSH7011206 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 19 Mar 2006 14:44:28 -0800
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by bandage.seagull.net (8.13.3) with ESMTP id k2JMiPp8011076 sender obsfucated@us.ibm.com; Sun, 19 Mar 2006 14:44:26 -0800
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2JMi29E024137; Sun, 19 Mar 2006 17:44:02 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2JMhqMU137846; Sun, 19 Mar 2006 17:43:52 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2JMhqEq026959; Sun, 19 Mar 2006 17:43:52 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2JMhqDW026954; Sun, 19 Mar 2006 17:43:52 -0500
To: w3c-dist-auth@w3.org
Cc: 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Jason Crawford 
Message-ID: 
Date: Sun, 19 Mar 2006 17:43:51 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/19/2006 17:43:51, Serialize complete at 03/19/2006 17:43:51
Content-Type: multipart/alternative; boundary="=_alternative 007C2F3785257136_="
Received-SPF: none (maggie.w3.org: domain of nn683849@smallcue.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: maggie.w3.org 1FL6dT-0007k7-1D 0de56a36db2307a33dba6d9fd0d9a618
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/OF8E88E37E.E0DA9430-ON85257136.0078B5CE-85257136.007CDD56@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12252
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Sun, 19 Mar 2006 22:44:47 +0000
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30


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

> Servers and clients must understand that the method for
> identifying resources is still the URL.  While generic clients
> will be able to display DAV:displayname to end users, both sides
> of the protocol must understand that if users are allowed to
> perform operations such as rename, move, copy etc, generic clients
> must display the URLs (or the path segments used in the displayed
> collection) to allow these operations. 

I don't know what last sentence means.   Clients do not need to display 
the URL or segments for the client to do those operations.   'at least not 
in GUI based clients.  Because I can't tell what is meant by "generic 
client" above,  I can't tell if the sentence is incorrect.  Nevertheless, 
as stated, I'm uncomfortable with the "must" in there.   And in general, 
I'm also not comfortable with us providing "must" statements regarding UI 
design.  UI is not the business of this spec. 


> Changes to DAV:displayname
> do not issue moves or copies to the server, but simply change a
> piece of meta-data on the individual resource.

I'd suggest changing this second paragraph to something
that largely removes that sentence:

  While generic clients
  will be able to display DAV:displayname to end users,
  client UI designers must understand that the method for
  identifying resources is still the URL.   Changes to DAV:displayname
  do not issue moves or copies to the server, but simply change a
  piece of meta-data on the individual resource.

We can then also perhaps make a statement about two resources
in the same collection having the same DAV:displayname.

J.

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



> Servers and clients must understand
that the method for

> identifying resources is still the URL.  While generic clients

> will be able to display DAV:displayname to end users, both sides

> of the protocol must understand that if users are allowed to

> perform operations such as rename, move, copy etc, generic clients

> must display the URLs (or the path segments used in the displayed

> collection) to allow these operations.  



I don't know what last sentence means.
  Clients do not need to display the URL or segments for the client
to do those operations.   'at least not in GUI based clients.  Because
I can't tell what is meant by "generic client" above,  I
can't tell if the sentence is incorrect.  Nevertheless, as stated,
I'm uncomfortable with the "must" in there.   And in general,
I'm also not comfortable with us providing "must" statements
regarding UI design.  UI is not the business of this spec.  





> Changes to DAV:displayname

> do not issue moves or copies to the server, but simply change a

> piece of meta-data on the individual resource.



I'd suggest changing this second paragraph
to something

that largely removes that sentence:



  While generic clients

  will be able to display DAV:displayname to end users,

  client UI designers must understand
that the method for

  identifying resources is still the URL.   Changes to DAV:displayname

  do not issue moves or copies to the server, but simply change a

  piece of meta-data on the individual resource.



We can then also perhaps make a statement
about two resources

in the same collection having the same
DAV:displayname.



J.


--=_alternative 007C2F3785257136_=--




From w3c-dist-auth-request@listhub.w3.org Sun Mar 19 22:59:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLBY0-0002l8-Lm
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 22:59:12 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLBY0-0007hA-9g
	for webdav-archive@lists.ietf.org; Sun, 19 Mar 2006 22:59:12 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLBWg-0000oL-Eq
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 03:57:50 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLBWX-0000my-Di; Mon, 20 Mar 2006 03:57:41 +0000
Received: from e2.ny.us.ibm.com ([32.97.182.142])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FLBWO-0002Oa-K3; Mon, 20 Mar 2006 03:57:40 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2K3vUEu012741;
	Sun, 19 Mar 2006 22:57:30 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2K3vVMU240778;
	Sun, 19 Mar 2006 22:57:31 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2K3vU6u023478;
	Sun, 19 Mar 2006 22:57:31 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2K3vTW8023453;
	Sun, 19 Mar 2006 22:57:30 -0500
In-Reply-To: 
To: Jason Crawford 
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
From: Geoffrey M Clemm 
Message-ID: 
Date: Sun, 19 Mar 2006 22:57:33 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/19/2006 22:57:30,
	Serialize complete at 03/19/2006 22:57:30
Content-Type: multipart/alternative; boundary="=_alternative 0015BD2A85257137_="
Received-SPF: none (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: maggie.w3.org 1FLBWO-0002Oa-K3 f7d9cf249aba6bb20c03347405d00291
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/OF82AB451C.71755BD6-ON85257137.0015B2C3-85257137.0015BDC3@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12253
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 03:57:50 +0000
X-Spam-Score: 2.3 (++)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f


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

I agree that Jason's suggested rewording is clearer.

Cheers,
Geoff

Jason wrote on 03/19/2006 05:43:51 PM:

> 
> > Servers and clients must understand that the method for
> > identifying resources is still the URL.  While generic clients
> > will be able to display DAV:displayname to end users, both sides
> > of the protocol must understand that if users are allowed to
> > perform operations such as rename, move, copy etc, generic clients
> > must display the URLs (or the path segments used in the displayed
> > collection) to allow these operations. 
> 
> I don't know what last sentence means.   Clients do not need to 
> display the URL or segments for the client to do those operations. 
> 'at least not in GUI based clients.  Because I can't tell what is 
> meant by "generic client" above,  I can't tell if the sentence is 
> incorrect.  Nevertheless, as stated, I'm uncomfortable with the 
> "must" in there.   And in general, I'm also not comfortable with us 
> providing "must" statements regarding UI design.  UI is not the 
> business of this spec. 
> 
> 
> > Changes to DAV:displayname
> > do not issue moves or copies to the server, but simply change a
> > piece of meta-data on the individual resource. 
> 
> I'd suggest changing this second paragraph to something 
> that largely removes that sentence: 
> 
>   While generic clients
>  will be able to display DAV:displayname to end users, 
>   client UI designers must understand that the method for
>  identifying resources is still the URL.   Changes to DAV:displayname
>  do not issue moves or copies to the server, but simply change a
>  piece of meta-data on the individual resource. 
> 
> We can then also perhaps make a statement about two resources 
> in the same collection having the same DAV:displayname. 
> 
> J. 
--=_alternative 0015BD2A85257137_=
Content-Type: text/html; charset="US-ASCII"



I agree that Jason's suggested rewording is clearer.



Cheers,

Geoff



Jason wrote on 03/19/2006 05:43:51 PM:



> 

> > Servers and clients must understand that the method for

> > identifying resources is still the URL.  While generic clients

> > will be able to display DAV:displayname to end users, both sides

> > of the protocol must understand that if users are allowed to

> > perform operations such as rename, move, copy etc, generic clients

> > must display the URLs (or the path segments used in the displayed

> > collection) to allow these operations.   

> 

> I don't know what last sentence means.   Clients do not need
to 

> display the URL or segments for the client to do those operations.
 

> 'at least not in GUI based clients.  Because I can't tell what
is 

> meant by "generic client" above,  I can't tell if the
sentence is 

> incorrect.  Nevertheless, as stated, I'm uncomfortable with the


> "must" in there.   And in general, I'm also not comfortable
with us 

> providing "must" statements regarding UI design.  UI
is not the 

> business of this spec.   

> 

> 

> > Changes to DAV:displayname

> > do not issue moves or copies to the server, but simply change
a

> > piece of meta-data on the individual resource. 

> 

> I'd suggest changing this second paragraph to something 

> that largely removes that sentence: 

> 

>   While generic clients

>  will be able to display DAV:displayname to end users, 

>   client UI designers must understand that the method for

>  identifying resources is still the URL.   Changes to DAV:displayname

>  do not issue moves or copies to the server, but simply change
a

>  piece of meta-data on the individual resource. 

> 

> We can then also perhaps make a statement about two resources 

> in the same collection having the same DAV:displayname. 

> 

> J. 
--=_alternative 0015BD2A85257137_=--




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 03:51:00 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLG6O-00087i-52
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 03:51:00 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLG6K-0000b2-PU
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 03:51:00 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLG4g-00058N-Cc
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 08:49:14 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLG4X-00057P-Cx
	for w3c-dist-auth@listhub.w3.org; Mon, 20 Mar 2006 08:49:05 +0000
Received: from astra.telenet-ops.be ([195.130.132.58])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FLG4V-0002Mk-JT
	for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 08:49:05 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by astra.telenet-ops.be (Postfix) with SMTP
	id 04F1BD01BF; Mon, 20 Mar 2006 09:49:02 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by astra.telenet-ops.be (Postfix) with ESMTP
	id D34D1D0201; Mon, 20 Mar 2006 09:49:01 +0100 (CET)
Message-ID: <441E6C9D.2040404@re.be>
Date: Mon, 20 Mar 2006 09:49:33 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (lisa.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLG4V-0002Mk-JT e4d56b330c8d7cc6a574325570cde4c9
X-Original-To: w3c-dist-auth@w3.org
Subject: rfc3253: DIFF method
X-Archived-At: http://www.w3.org/mid/441E6C9D.2040404@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12254
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 08:49:14 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


Hi,

Shouldn't there be a DIFF method? Calculating the difference between
two versions may be a very specialised operation for some document
formats. The software or resources to accomplish it may not be available
to clients.

Regards,

Werner.
--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 08:12:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLKBp-0005GD-Mh
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:12:53 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLKBl-0001WG-BW
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:12:51 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLKAr-0007Is-W3
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 13:11:53 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLKAh-0007Hd-SK; Mon, 20 Mar 2006 13:11:43 +0000
Received: from e6.ny.us.ibm.com ([32.97.182.146])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FLKAa-0004zy-9r; Mon, 20 Mar 2006 13:11:43 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2KDBIEa025061;
	Mon, 20 Mar 2006 08:11:18 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2KDB8OM199988;
	Mon, 20 Mar 2006 08:11:08 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2KDB8kl015035;
	Mon, 20 Mar 2006 08:11:08 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2KDB8Sh015032;
	Mon, 20 Mar 2006 08:11:08 -0500
In-Reply-To: <441E75C2.1050300@re.be>
To: werner.donne@re.be
Cc: ietf-dav-versioning@w3.org, " webdav" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Mon, 20 Mar 2006 08:11:08 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/20/2006 08:11:07,
	Serialize complete at 03/20/2006 08:11:07
Content-Type: multipart/alternative; boundary="=_alternative 00486BB485257137_="
Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: lisa.w3.org 1FLKAa-0004zy-9r 00370f9c0c98ed4807d4e16255e5a335
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: DIFF method
X-Archived-At: http://www.w3.org/mid/OFFD2DD7E8.567EBCC0-ON85257137.0041BEE9-85257137.00486C6D@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12255
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 13:11:53 +0000
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64


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

The only interesting thing aobut a DIFF method is the format of its 
result.
There was such a wide variation in the different formats that diff tools
use for different types of resources that it didn't appear to be something
on which we could get consensus.  There are some standards for diff 
formats,
e.g., http://www.ietf.org/rfc/rfc3284.txt?number=3284 (The VCDIFF Generic
Differencing and Compression Data Format) and some new ones being
proposed, e.g., 
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.txt

Cheers,
Geoff

Werner wrote on 03/20/2006 04:28:34 AM:
> Shouldn't there be a DIFF method? Calculating the difference between
> two versions may be a very specialised operation for some document
> formats. The software or resources to accomplish it may not be available
> to clients.

--=_alternative 00486BB485257137_=
Content-Type: text/html; charset="US-ASCII"



The only interesting thing aobut a DIFF method is
the format of its result.

There was such a wide variation in the different formats
that diff tools

use for different types of resources that it didn't
appear to be something

on which we could get consensus.  There are some
standards for diff formats,

e.g., http://www.ietf.org/rfc/rfc3284.txt?number=3284
(The VCDIFF Generic

Differencing and Compression Data Format)
and some new ones being

proposed, e.g., http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.txt



Cheers,

Geoff



Werner wrote on 03/20/2006 04:28:34 AM:

> Shouldn't there be a DIFF method? Calculating the difference between

> two versions may be a very specialised operation for some document

> formats. The software or resources to accomplish it may not be available

> to clients.


--=_alternative 00486BB485257137_=--




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 08:24:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLKNT-0003kM-Jv
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:24:55 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLKNS-00026K-Bv
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:24:55 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLKNB-0002cf-Bl
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 13:24:37 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLKN2-0002c6-RA; Mon, 20 Mar 2006 13:24:28 +0000
Received: from hoboe2bl1.telenet-ops.be ([195.130.137.73])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FLKN0-00086r-M1; Mon, 20 Mar 2006 13:24:28 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by hoboe2bl1.telenet-ops.be (Postfix) with SMTP
	id 7F831124307; Mon, 20 Mar 2006 14:24:23 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by hoboe2bl1.telenet-ops.be (Postfix) with ESMTP
	id 4E98212439E; Mon, 20 Mar 2006 14:24:23 +0100 (CET)
Message-ID: <441EAD27.7030601@re.be>
Date: Mon, 20 Mar 2006 14:24:55 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm 
Cc: ietf-dav-versioning@w3.org, webdav 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (lisa.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLKN0-00086r-M1 309ae4e93eaf86fdf500bab4c67f42d0
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: DIFF method
X-Archived-At: http://www.w3.org/mid/441EAD27.7030601@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12256
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 13:24:37 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb


Geoffrey M Clemm wrote:
>=20
> The only interesting thing aobut a DIFF method is the format of its res=
ult.

The diff calculation itself can require software that can't be distribute=
d
to clients, because of licensing limitations, programming language, resou=
rces
or whatever. Note that it can be more than just a diff of text files. I
will use DeltaXML, for example, which is specialised in calculating the d=
iff
between two XML documents. It inserts mark-up in its own namespace in the
resulting document.

The format can also be converted on the fly, depending on the "Accept"
request header. I could convert it to PDF, again with tools that are only
available on the server.

> Cheers,
> Geoff

Regards,

Werner.

>=20
> Werner wrote on 03/20/2006 04:28:34 AM:
>> Shouldn't there be a DIFF method? Calculating the difference between
>> two versions may be a very specialised operation for some document
>> formats. The software or resources to accomplish it may not be availab=
le
>> to clients.

--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 08:38:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLKaC-0003XD-IU
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:38:04 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLKaC-0002S3-52
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:38:04 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLKZs-00008l-8Q
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 13:37:44 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLKZo-000088-KM; Mon, 20 Mar 2006 13:37:40 +0000
Received: from e6.ny.us.ibm.com ([32.97.182.146])
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FLKZg-0002in-74; Mon, 20 Mar 2006 13:37:40 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2KDbLaN006428;
	Mon, 20 Mar 2006 08:37:21 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2KDbBOM159484;
	Mon, 20 Mar 2006 08:37:11 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2KDbA3E014666;
	Mon, 20 Mar 2006 08:37:11 -0500
Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2KDbA2G014652;
	Mon, 20 Mar 2006 08:37:10 -0500
In-Reply-To: <441EAD27.7030601@re.be>
To: werner.donne@re.be
Cc: ietf-dav-versioning@w3.org, webdav 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm 
Message-ID: 
Date: Mon, 20 Mar 2006 08:37:11 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at
 03/20/2006 08:37:10,
	Serialize complete at 03/20/2006 08:37:10
Content-Type: multipart/alternative; boundary="=_alternative 004ACE2B85257137_="
Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Scan-Sig: lisa.w3.org 1FLKZg-0002in-74 f76d5b750fce525b041d9e85fed892c1
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: DIFF method
X-Archived-At: http://www.w3.org/mid/OFA5F91626.257D6547-ON85257137.0049D552-85257137.004ACECC@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12257
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 13:37:44 +0000
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760


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

I wasn't questioning the desirability (from a client's perspective) of
having a DIFF method, but was just pointing out that the challenge is
to come up with a standard result format that more than one server will
be willing/able to produce.

Cheers,
Geoff

Werner wrote on 03/20/2006 08:24:55 AM:

> Geoffrey M Clemm wrote:
> > The only interesting thing about a DIFF method is the format of its=20
result.
> > There was such a wide variation in the different formats that diff=20
tools=20
> > use for different types of resources that it didn't appear to be=20
something=20
> > on which we could get consensus.  There are some standards for diff=20
formats,=20
> > e.g., http://www.ietf.org/rfc/rfc3284.txt?number=3D3284 (The VCDIFF=20
Generic=20
> > Differencing and Compression Data Format) and some new ones being=20
> > proposed, e.g.,=20
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.txt=20
>=20
> The diff calculation itself can require software that can't be=20
distributed
> to clients, because of licensing limitations, programming language,=20
resources
> or whatever. Note that it can be more than just a diff of text files. I
> will use DeltaXML, for example, which is specialised in calculating the=20
diff
> between two XML documents. It inserts mark-up in its own namespace in=20
the
> resulting document.
>=20
> The format can also be converted on the fly, depending on the "Accept"
> request header. I could convert it to PDF, again with tools that are=20
only
> available on the server.
>=20
> > Cheers,
> > Geoff
>=20
> Regards,
>=20
> Werner.
>=20
> >=20
> > Werner wrote on 03/20/2006 04:28:34 AM:
> >> Shouldn't there be a DIFF method? Calculating the difference between
> >> two versions may be a very specialised operation for some document
> >> formats. The software or resources to accomplish it may not be=20
available
> >> to clients.
>=20
> --=20
> Werner Donn=E9  --  Re
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>=20

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



I wasn't questioning the desirability (from a client=
's
perspective) of

having a DIFF method, but was just pointing out that
the challenge is

to come up with a standard result format that more
than one server will

be willing/able to produce.



Cheers,

Geoff



Werner wrote on 03/20/2006 08:24:55 AM:



> Geoffrey M Clemm wrote:

> > The only interesting thing about a DIFF method is the format
of its result.

> > There was such a wide variation in the dif=
ferent
formats that diff tools 

> > use for different types of resources that it didn't appear to
be something 

> > on which we could get consensus.  There are some standards
for diff formats, 

> > e.g., http://www.ietf.org/rfc/rfc3284.txt?number=3D3284 (The
VCDIFF Generic 

> > Dif=
ferencing
and Compression Data Format) and some new
ones being 

> > proposed, e.g., http://www.ietf.org/internet-drafts/draft-ietf-si=
mple-xcap-diff-03.txt


> 

> The diff calculation itself can require software that can't be distrib=
uted

> to clients, because of licensing limitations, programming language,
resources

> or whatever. Note that it can be more than just a diff of text files.
I

> will use DeltaXML, for example, which is specialised in calculating
the diff

> between two XML documents. It inserts mark-up in its own namespace
in the

> resulting document.

> 

> The format can also be converted on the fly, depending on the "Ac=
cept"

> request header. I could convert it to PDF, again with tools that are
only

> available on the server.

> 

> > Cheers,

> > Geoff

> 

> Regards,

> 

> Werner.

> 

> > 

> > Werner wrote on 03/20/2006 04:28:34 AM:

> >> Shouldn't there be a DIFF method? Calculating the difference
between

> >> two versions may be a very specialised operation for some
document

> >> formats. The software or resources to accomplish it may not
be available

> >> to clients.

> 

> -- 

> Werner Donn=E9  --  Re

> Engelbeekstraat 8

> B-3300 Tienen

> tel: (+32) 486 425803   e-mail: werner.donne@re.be

> 


--=_alternative 004ACE2B85257137_=--




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 08:47:09 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLKiz-0000Nv-66
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:47:09 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLKiy-0002cC-Sw
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 08:47:09 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLKid-0003xB-2C
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 13:46:47 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLKiX-0003wY-33; Mon, 20 Mar 2006 13:46:41 +0000
Received: from europa.telenet-ops.be ([195.130.137.75])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FLKiO-0005B6-HM; Mon, 20 Mar 2006 13:46:40 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by europa.telenet-ops.be (Postfix) with SMTP
	id 82401234434; Mon, 20 Mar 2006 14:46:25 +0100 (CET)
Received: from [192.168.0.106] (d51533D4B.access.telenet.be [81.83.61.75])
	by europa.telenet-ops.be (Postfix) with ESMTP
	id 01A71234455; Mon, 20 Mar 2006 14:46:25 +0100 (CET)
Message-ID: <441EB251.6000609@re.be>
Date: Mon, 20 Mar 2006 14:46:57 +0100
From: =?ISO-8859-1?Q?Werner_Donn=E9?= 
Reply-To: werner.donne@re.be
Organization: Re BVBA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm 
Cc: ietf-dav-versioning@w3.org, webdav 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (maggie.w3.org: domain of werner.donne@re.be does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FLKiO-0005B6-HM 5eed88a6dc14f06202366598ce505012
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: DIFF method
X-Archived-At: http://www.w3.org/mid/441EB251.6000609@re.be
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12258
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 13:46:47 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1


Geoffrey M Clemm wrote:
>=20
> I wasn't questioning the desirability (from a client's perspective) of
> having a DIFF method, but was just pointing out that the challenge is
> to come up with a standard result format that more than one server will
> be willing/able to produce.

I don't see why there should be a standard result format. There are by
definition many, because there are many content types. For some a diff
may even not be possible. There can also be several result formats
for the same content type. That is a matter of representation.

>=20
> Cheers,
> Geoff

Regards,

Werner.

>=20
> Werner wrote on 03/20/2006 08:24:55 AM:
>=20
>> Geoffrey M Clemm wrote:
>> > The only interesting thing about a DIFF method is the format of its
> result.
>> > There was such a wide variation in the different formats that diff
> tools
>> > use for different types of resources that it didn't appear to be
> something
>> > on which we could get consensus.  There are some standards for diff
> formats,
>> > e.g., http://www.ietf.org/rfc/rfc3284.txt?number=3D3284 (The VCDIFF
> Generic
>> > Differencing and Compression Data Format) and some new ones being
>> > proposed, e.g.,
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.txt
>>
>> The diff calculation itself can require software that can't be distrib=
uted
>> to clients, because of licensing limitations, programming language,
> resources
>> or whatever. Note that it can be more than just a diff of text files. =
I
>> will use DeltaXML, for example, which is specialised in calculating
> the diff
>> between two XML documents. It inserts mark-up in its own namespace in =
the
>> resulting document.
>>
>> The format can also be converted on the fly, depending on the "Accept"
>> request header. I could convert it to PDF, again with tools that are o=
nly
>> available on the server.
>>
>> > Cheers,
>> > Geoff
>>
>> Regards,
>>
>> Werner.
>>
>> >
>> > Werner wrote on 03/20/2006 04:28:34 AM:
>> >> Shouldn't there be a DIFF method? Calculating the difference betwee=
n
>> >> two versions may be a very specialised operation for some document
>> >> formats. The software or resources to accomplish it may not be
> available
>> >> to clients.
>>
>> --
>> Werner Donn=E9  --  Re
>> Engelbeekstraat 8
>> B-3300 Tienen
>> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>>

--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 09:22:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLLHU-0004yr-Ld
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 09:22:48 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLLHR-0003hy-Cf
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 09:22:48 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLLGp-0005bk-94
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 14:22:07 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLLGg-0005Yf-To
	for w3c-dist-auth@listhub.w3.org; Mon, 20 Mar 2006 14:21:59 +0000
Received: from mail.gmx.net ([213.165.64.20])
	by maggie.w3.org with smtp (Exim 4.50)
	id 1FLLGZ-0004oW-PT
	for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 14:21:58 +0000
Received: (qmail invoked by alias); 20 Mar 2006 14:21:50 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233]
  by mail.gmx.net (mp042) with SMTP; 20 Mar 2006 15:21:50 +0100
X-Authenticated: #1915285
Message-ID: <441EBA2B.40600@gmx.de>
Date: Mon, 20 Mar 2006 15:20:27 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Geoffrey M Clemm 
CC: Jason Crawford ,  w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: none (maggie.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FLLGZ-0004oW-PT a81f83ee1803ba57eb3e550a5c932b01
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/441EBA2B.40600@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12259
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 14:22:07 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352


Geoffrey M Clemm wrote:
> 
> I agree that Jason's suggested rewording is clearer.
> 
> Cheers,
> Geoff

OK; new proposed text; based on Jason's text and proposal:

15.2.  displayname Property

    Name:   displayname

    Purpose:   Provides a name for the resource that is suitable for
       presentation to a user.

    Value:   Any text.

    Protected:   SHOULD NOT be protected.  Note that servers implementing
       [RFC2518] might have made this a protected property as this is a
       new requirement.

    COPY/MOVE behaviour:   This property value SHOULD be preserved in
       COPY and MOVE operations.

    Description:   The property contains a description of the resource
       that is suitable for presentation to a user.  This property is
       defined on the resource, and hence SHOULD have the same value
       independent of the Request-URI used to retrieve it (thus computing
       this property based on the Request-URI is deprecated).

       While generic clients will be able to use the value of the DAV:
       displayname property for display to end users, client UI designers
       must understand that the method for identifying resources is still
       the URL.  In particular, there is no guarantee whatsoever that the
       values of this property are unique for each member of a
       collection.  Also note that changes to DAV:displayname do not
       issue moves or copies to the server, but simply change a piece of
       meta-data on the individual resource.

    





From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 10:44:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLMYE-0002Ob-M7
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 10:44:10 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLMYC-00072U-Bu
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 10:44:10 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLMXP-00042H-Ll
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 15:43:19 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLMX7-0003xw-Pl
	for w3c-dist-auth@listhub.w3.org; Mon, 20 Mar 2006 15:43:01 +0000
Received: from ifeelusedbooks.com ([67.136.24.186] helo=bandage.seagull.net)
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FLMX3-0006tV-LZ
	for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 15:43:01 +0000
Received: (mail@localhost) by bandage.seagull.net (8.13.3) id k2KFgrOh020851 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 07:42:53 -0800
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by bandage.seagull.net (8.13.3) with ESMTP id k2KFgofn020712 sender obsfucated@us.ibm.com; Mon, 20 Mar 2006 07:42:51 -0800
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2KFgT6t009413; Mon, 20 Mar 2006 10:42:29 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2KFgMOM143776; Mon, 20 Mar 2006 10:42:22 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2KFgL2F022323; Mon, 20 Mar 2006 10:42:22 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2KFgLk7022155; Mon, 20 Mar 2006 10:42:21 -0500
To: Julian Reschke 
Cc: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Jason Crawford 
Message-ID: 
Date: Mon, 20 Mar 2006 10:42:18 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/20/2006 10:42:20, Serialize complete at 03/20/2006 10:42:20
Content-Type: multipart/alternative; boundary="=_alternative 0056262E85257137_="
Received-SPF: none (maggie.w3.org: domain of nn683849@smallcue.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Scan-Sig: maggie.w3.org 1FLMX3-0006tV-LZ eeb922efbe8cc471d6cd4a6124f57670
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/OFEA249575.F08D6A8B-ON85257137.0056114D-85257137.00564516@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12260
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 15:43:19 +0000
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f


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

> While generic clients will be able to use the value of the DAV:
> displayname property for display to end users, client UI designers
> must understand that the method for identifying resources is still
> the URL.  In particular, there is no guarantee whatsoever that the
> values of this property are unique for each member of a
> collection.  Also note that changes to DAV:displayname do not
> issue moves or copies to the server, but simply change a piece of
> meta-data on the individual resource.


'Nice improvement over my wording. :-)

--=_alternative 0056262E85257137_=
Content-Type: text/html; charset="US-ASCII"



> While generic clients will be able
to use the value of the DAV:

> displayname property for display to end users, client UI designers

> must understand that the method for identifying resources is still

> the URL.  In particular, there is no guarantee whatsoever that
the

> values of this property are unique for each member of a

> collection.  Also note that changes to DAV:displayname do not

> issue moves or copies to the server, but simply change a piece of

> meta-data on the individual resource.





'Nice improvement over my wording. :-)


--=_alternative 0056262E85257137_=--




From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 10:46:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLMaU-0003B9-MA
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 10:46:30 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLMaT-00076i-53
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 10:46:30 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLMaF-0006kh-Uq
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 15:46:15 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLMa8-0006QF-Qx
	for w3c-dist-auth@listhub.w3.org; Mon, 20 Mar 2006 15:46:08 +0000
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FLMa5-0008TB-OE
	for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 15:46:08 +0000
Received: from jbaroned600 ([69.107.70.231]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 20 Mar 2006 07:46:03 -0800
From: "John Barone" 
To: "'Julian Reschke'" ,
	"'Geoffrey M Clemm'" 
Cc: "'Jason Crawford'" ,
	
Date: Mon, 20 Mar 2006 07:46:10 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcZMKcPcy42JssRFQpmtPow1uMr9iQAC5arA
In-Reply-To: <441EBA2B.40600@gmx.de>
Message-ID: 
X-OriginalArrivalTime: 20 Mar 2006 15:46:03.0933 (UTC) FILETIME=[65128CD0:01C64C35]
Received-SPF: none (lisa.w3.org: domain of jbarone@xythos.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLMa5-0008TB-OE a03d4602fe457b22b6d5068984dcf26a
X-Original-To: w3c-dist-auth@w3.org
Subject: RE: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/NSNOVPS004111UbDBRA000010da@NSNOVPS00411.nacio.xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12261
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 15:46:15 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab


+1

-John 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Julian Reschke
Sent: Monday, March 20, 2006 6:20 AM
To: Geoffrey M Clemm
Cc: Jason Crawford; w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name


Geoffrey M Clemm wrote:
> 
> I agree that Jason's suggested rewording is clearer.
> 
> Cheers,
> Geoff

OK; new proposed text; based on Jason's text and proposal:

15.2.  displayname Property

    Name:   displayname

    Purpose:   Provides a name for the resource that is suitable for
       presentation to a user.

    Value:   Any text.

    Protected:   SHOULD NOT be protected.  Note that servers implementing
       [RFC2518] might have made this a protected property as this is a
       new requirement.

    COPY/MOVE behaviour:   This property value SHOULD be preserved in
       COPY and MOVE operations.

    Description:   The property contains a description of the resource
       that is suitable for presentation to a user.  This property is
       defined on the resource, and hence SHOULD have the same value
       independent of the Request-URI used to retrieve it (thus computing
       this property based on the Request-URI is deprecated).

       While generic clients will be able to use the value of the DAV:
       displayname property for display to end users, client UI designers
       must understand that the method for identifying resources is still
       the URL.  In particular, there is no guarantee whatsoever that the
       values of this property are unique for each member of a
       collection.  Also note that changes to DAV:displayname do not
       issue moves or copies to the server, but simply change a piece of
       meta-data on the individual resource.

    







From w3c-dist-auth-request@listhub.w3.org Mon Mar 20 13:55:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLPXN-0004Rr-V4
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 13:55:29 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLPXM-00069I-Lk
	for webdav-archive@lists.ietf.org; Mon, 20 Mar 2006 13:55:29 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLPWJ-0001Qk-Pj
	for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Mar 2006 18:54:23 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLPWA-0001Q1-8k
	for w3c-dist-auth@listhub.w3.org; Mon, 20 Mar 2006 18:54:14 +0000
Received: from services.cse.ucsc.edu ([128.114.48.10])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FLPW2-0004hN-Fz
	for w3c-dist-auth@w3.org; Mon, 20 Mar 2006 18:54:14 +0000
Received: from [192.168.2.102] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219])
	(authenticated bits=0)
	by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id k2KIs2Tk025315
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 20 Mar 2006 10:54:03 -0800 (PST)
Message-ID: <441EFA4A.5010000@cse.ucsc.edu>
Date: Mon, 20 Mar 2006 10:54:02 -0800
From: Elias Sinderson 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References:  <441EBA2B.40600@gmx.de>
In-Reply-To: <441EBA2B.40600@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FLPW2-0004hN-Fz be6a2ed15bd8d0c9bf38fdc38e0eff4e
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518--Display Name
X-Archived-At: http://www.w3.org/mid/441EFA4A.5010000@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12262
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Mon, 20 Mar 2006 18:54:23 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352


I am satisfied with the proposed text, below.

Best,
Elias


Julian Reschke wrote:

> 15.2.  displayname Property
>
>    Name:   displayname
>
>    Purpose:   Provides a name for the resource that is suitable for
>       presentation to a user.
>
>    Value:   Any text.
>
>    Protected:   SHOULD NOT be protected.  Note that servers implementing
>       [RFC2518] might have made this a protected property as this is a
>       new requirement.
>
>    COPY/MOVE behaviour:   This property value SHOULD be preserved in
>       COPY and MOVE operations.
>
>    Description:   The property contains a description of the resource
>       that is suitable for presentation to a user.  This property is
>       defined on the resource, and hence SHOULD have the same value
>       independent of the Request-URI used to retrieve it (thus computing
>       this property based on the Request-URI is deprecated).
>
>       While generic clients will be able to use the value of the DAV:
>       displayname property for display to end users, client UI designers
>       must understand that the method for identifying resources is still
>       the URL.  In particular, there is no guarantee whatsoever that the
>       values of this property are unique for each member of a
>       collection.  Also note that changes to DAV:displayname do not
>       issue moves or copies to the server, but simply change a piece of
>       meta-data on the individual resource.
>
>    
>





From w3c-dist-auth-request@listhub.w3.org Tue Mar 21 12:41:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLkr3-0003mo-VN
	for webdav-archive@lists.ietf.org; Tue, 21 Mar 2006 12:41:13 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLkr2-0000zf-DB
	for webdav-archive@lists.ietf.org; Tue, 21 Mar 2006 12:41:13 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLkpg-0007tb-4U
	for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Mar 2006 17:39:48 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLhvS-0003Cq-PF
	for w3c-dist-auth@listhub.w3.org; Tue, 21 Mar 2006 14:33:34 +0000
Received: from mail.gmx.net ([213.165.64.20])
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FLhvM-0005c4-U5
	for w3c-dist-auth@w3.org; Tue, 21 Mar 2006 14:33:32 +0000
Received: (qmail invoked by alias); 21 Mar 2006 14:33:27 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233]
  by mail.gmx.net (mp028) with SMTP; 21 Mar 2006 15:33:27 +0100
X-Authenticated: #1915285
Message-ID: <44200E62.7020509@gmx.de>
Date: Tue, 21 Mar 2006 15:32:02 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To:  w3c-dist-auth@w3.org
References: <03E7D3E231BB7B4A915A6581D4296CC60206325B@NSNOVPS00411.nacio.xythos.com>
In-Reply-To: <03E7D3E231BB7B4A915A6581D4296CC60206325B@NSNOVPS00411.nacio.xythos.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLhvM-0005c4-U5 166148224cf790d54286286e701c68d4
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518 -- XSS
X-Archived-At: http://www.w3.org/mid/44200E62.7020509@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12263
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Tue, 21 Mar 2006 17:39:48 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1


Hi,

I think that Kevin is correct that this is a new type of attack not 
discussed before, although I think it's misleading to call it an XSS attack.

I have opened a BugZilla issue for it 
(). Once we 
have consensus that this is a real problem, we need to discuss what to 
say in the Security Considerations section.

Best regards, Julian



Kevin Wiggen wrote:
> 
> 
> I believe this is way too weak of language on what the risks are around
> Webdav (and HTTP for that matter).  We need to point out to people that
> there is a LARGE risk in allowing users to post data to servers because
> of the way HTTP and Webdav work.
> 
> "The server might not have a close trust relationship with the author
> that is publishing the document."  -- Even in corporate, I don't have a
> strong trust relationship with every employee...  There are also
> numerous servers that are being used by multiple sets of people.  If
> someone for ANY reason can PUT information on the server, it is possible
> for others to be compromised by that person.  I think we need to spell
> this out for people so they understand the risks.  
> 
> "Servers that allow clients to publish arbitrary content can usefully
> implement precautions to check that content published to the server is
> not harmful to other clients. Servers could do this by techniques such
> as restricting the types of content that is allowed to be published and
> running virus and malware detection software on published content."  --
> Again this is a catch 22.  Basically there is a line between usefulness
> and security.  People have valid reasons for posting lots of different
> content.  How do you know if they are malicious or not?  Also I know of
> no virus protection software that flags xmlHTTP() as a virus.  Right now
> clicking on index.html in web folders launches my browser which can then
> execute code (and since IE shares login info) that will make any type of
> Webdav calls to the server using xmlHTTP and my security permissions.
> The major problem I believe we need to solve is the relationship between
> a GET and HTML.  
> 
> "Servers can also mitigate the risk by having appropriate access
> restriction and authentication of users that are allowed to publish
> content to the server." -- This makes it seem like valid ACL will solve
> the problem.  This is not necessarily true.  If you allow me to write to
> ANY part of your server, I can trick you into letting me have access to
> the rest of it.  I think this language is vague and leads people to
> believe things are safe when they are not.  We need to spell out what
> the risks are and let people know.
> 
> I remember a few years ago when MS had a buffer overflow exploit in
> there Webdav server, it took a lot of convincing to prove to people that
> it was a problem with the MS server and not the protocol. "Webdav is
> insecure" is what people kept saying.  We need to discuss these issues
> else Webdav could get a really bad rap (even though most of these
> problems also affect HTTP itself).
> 
> 
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Julian Reschke
> Sent: Thursday, March 02, 2006 12:34 AM
> To: Kevin Wiggen
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Comments on the "new" 2518 -- XSS
> 
> 
> Kevin Wiggen wrote:
>> Webdav needs to mention (and hopefully help) solve XSS attack
> problems.  
>> XSS (Cross-Site Scripting) is aimed at inserting active code in an
> HTML 
>> document to either abuse client-side active scripting holes, or to
> send 
>> privileged information (e.g. authentication/session cookies) to a 
>> previously unknown evil collection site.
> 
> We currently have 
>  fc.section.20.8>, 
> which says:
> 
> "HTTP has the ability to host programs which are executed on client 
> machines. These programs can take many forms including web scripts, 
> executables, plug in modules, and macros in documents. WebDAV does not 
> change any of the security concerns around these programs yet often 
> WebDAV is used in contexts where a wide range of users can publish 
> documents on a server. The server might not have a close trust 
> relationship with the author that is publishing the document. Servers 
> that allow clients to publish arbitrary content can usefully implement 
> precautions to check that content published to the server is not harmful
> 
> to other clients. Servers could do this by techniques such as 
> restricting the types of content that is allowed to be published and 
> running virus and malware detection software on published content. 
> Servers can also mitigate the risk by having appropriate access 
> restriction and authentication of users that are allowed to publish 
> content to the server."
> 
> I don't think that saying more would be good. This is a general problem 
> *not* specific to WebDAV.
> 
>> Webdav to date is content agnostic and allows for clients to retrieve 
>> and save information to/from a server.  Unfortunately with Javascript 
>> and some knowledge of webdav, people can start to "hack" webdav
> servers 
>> to do unexpected things.  Imagine I upload (using PUT) a HTML page
> that 
>> uses a browser xmlHTTP() to send a propfind to the server and then
> issue 
>> DELETE to everything I could find.  By simply sending you a link to a 
>> URL on a common secured server, a browser will ask you to log in and 
>> then execute the javascript AS YOU.  There are a lot of problems that 
>> smart people can create because the GET and other Webdav methods all 
>> originate from the same server.  There are possible solutions (from 
>> scraping all input and not allowing certain content) but each always
> has 
>> some drawbacks (hey I want that javascript to do something important
> on 
>> my webpage, you can't cut it out when I upload it). 
> 
> So do you have any specific proposal about what to do?
> 
>> A separate but related issue is the MS "translate" issue.  If someone 
>> uploads a jsp to a server, when they request it back, do they want the
> 
>> server to give the jsp? Or execute the jsp and return the result? 
>>
>> It seems that Webdav (web distributed AUTHORING and versioning) could 
>> take some steps to help out both of these areas.  One line of thinking
> 
>> (notice I don't say solution) is to have Webdav separate the authoring
> 
>> world from the view (or execute world).  In this world there would be 
>> two different namespaces (one for Webdav and one for GET/Execute).
> The 
>> webdav world would tell clients that it is meant for authoring and
> thus 
>> servers will NOT execute things like jsps and clients should NOT
> render 
>> and execute these objects (like javascript in HTML) in things like 
>> browsers but rather a edit mode (like HTML editor).  In this way, 
>> Javascript should not be executed by HTML Editors and the namespace
> will 
>> be protected from malicious code stored in the sheep's clothing of
> HTML.
> 
> That's basically the question the DAV:source property was supposed to 
> solve. It has been removed from the spec due to a complete lack of 
> implementation experience.
> 
> It's an interesting and important topic, but it was impossible to solve 
> within the time that has been allocated to us.
> 
>> Again I believe it important for Webdav to speak about these problems 
>> and try to give solutions.
>>
> 
> Best regards, Julian
> 
> 
> 
> 


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




From w3c-dist-auth-request@listhub.w3.org Tue Mar 21 15:59:05 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLnwX-0002dA-CP
	for webdav-archive@lists.ietf.org; Tue, 21 Mar 2006 15:59:05 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLnwW-00020m-0H
	for webdav-archive@lists.ietf.org; Tue, 21 Mar 2006 15:59:05 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLnvf-0001bq-6U
	for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Mar 2006 20:58:11 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLnvV-0001Ys-Lm
	for w3c-dist-auth@listhub.w3.org; Tue, 21 Mar 2006 20:58:01 +0000
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FLnvQ-0000oa-Vk
	for w3c-dist-auth@w3.org; Tue, 21 Mar 2006 20:58:00 +0000
Received: (qmail invoked by alias); 21 Mar 2006 20:57:55 -0000
Received: from p508FA27F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.162.127]
  by mail.gmx.net (mp026) with SMTP; 21 Mar 2006 21:57:55 +0100
X-Authenticated: #1915285
Message-ID: <4420687A.5060400@gmx.de>
Date: Tue, 21 Mar 2006 21:56:26 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To:  w3c-dist-auth@w3.org
CC: John Barone , 
 'Geoffrey M Clemm' ,
 'Kevin Wiggen' ,  w3c-dist-auth-request@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLnvQ-0000oa-Vk 5c1e5fe66114866a0f0ad007d583f0d0
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518
X-Archived-At: http://www.w3.org/mid/4420687A.5060400@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12264
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Tue, 21 Mar 2006 20:58:11 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172


OK,

trying to summarize:

- RFC2518 and RFC2518bis suggest best-effort behavior for COPY + MOVE

- John B says that most users (+ client implementors) would prefer 
atomic semantics, at least for MOVE

- many servers are not capable of implementing atomic behavior

- the BIND spec already defines an atomic version of MOVE, which is REBIND.

Questions:

1) Is there any reason to modify RFC2518bis' current language?

2) For implementors who want to use an atomic version of MOVE, is REBIND 
sufficient?


My p.o.v.:

re 1) Not convinced yet.

re 2) Yes.

While looking at this I noticed another editorial issue in 9.9, which 
currently starts with:

9.9.  MOVE Method

    The MOVE operation on a non-collection resource is the logical
    equivalent of a copy (COPY), followed by consistency maintenance
    processing, followed by a delete of the source, where all three
    actions are performed atomically.  The consistency maintenance step
    allows the server to perform updates caused by the move, such as
    updating all URLs other than the Request-URI which identify the
    source resource, to point to the new destination resource.
    Consequently, the Destination header MUST be present on all MOVE
    methods and MUST follow all COPY requirements for the COPY part of
    the MOVE method.  All WebDAV compliant resources MUST support the
    MOVE method.  However, support for the MOVE method does not guarantee
    the ability to move a resource to a particular destination.

    For example, separate programs may actually control different sets of
    resources on the same server.  Therefore, it may not be possible to
    move a resource within a namespace that appears to belong to the same
    server.

I think the first paragraph break is in the wrong position and should be 
two sentences earlier:

9.9.  MOVE Method

    The MOVE operation on a non-collection resource is the logical
    equivalent of a copy (COPY), followed by consistency maintenance
    processing, followed by a delete of the source, where all three
    actions are performed atomically.  The consistency maintenance step
    allows the server to perform updates caused by the move, such as
    updating all URLs other than the Request-URI which identify the
    source resource, to point to the new destination resource.
    Consequently, the Destination header MUST be present on all MOVE
    methods and MUST follow all COPY requirements for the COPY part of
    the MOVE method.

    All WebDAV compliant resources MUST support the
    MOVE method.  However, support for the MOVE method does not guarantee
    the ability to move a resource to a particular destination.
    For example, separate programs may actually control different sets of
    resources on the same server.  Therefore, it may not be possible to
    move a resource within a namespace that appears to belong to the same
    server.

(adding to 
)

Best regards, Julian


John Barone wrote:
> Well, I still don't see mixing and matching methods from various specs. as a
> coherent way of addressing the notion of atomicity (all-or-nothing behavior)
> in this spec. 2518-bis.  But, that's neither here nor there; the bottom line
> is that Xythos seems to be the only ones who feel that this is a useful
> addition to the spec., so I'll let this drop as well.
> 
> -John 
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Tuesday, March 14, 2006 10:42 AM
> To: John Barone
> Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
> w3c-dist-auth-request@w3.org
> Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518
> 
> John Barone wrote:
>>> Again, what's wrong with REBIND? You can implement REBIND without
>> implementing
>>> anything else in the BIND spec. For that matter, you'd probably want 
>>> to
>> implement
>>> UNBIND as well (as DELETE shares the non-atomic properties with MOVE).
>> I don't understand what's proposed here.
>>
>> Are you proposing that we leave the 2518-bis spec. silent on this 
>> matter, and simply implement pieces of the binding spec. to provide this
> capability?
> 
> Exactly.
> 
>> If so, that doesn't make any sense to me, since what we're really 
>> talking about is a different spec. with different requirements.  The 
>> way I see it, that has no bearing on this spec. or this discussion.
> 
> Well, both specs are discussed here, and both are supposed to be submitted
> to the IESG at roughly the same time.
> 
>> If instead you're proposing that we add a method REBIND to this spec., 
>> with an appropriate definition; my concern is that REBIND has a 
>> specific meaning that's fleshed out by the context provided in the 
>> binding spec., but that meaning doesn't translate to the 2518-bis 
>> spec., where we're talking about MOVEs, COPYs, and DELETEs, not BINDs,
> UNBINDs, and REBINDs.
> 
> That seems to be a very theoretical argument, unless you can show exactly
> how REBIND isn't what you need...
> 
> Best regards, Julian
> 
> 
> 


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




From kimegosnell@goodnplenty.com Wed Mar 22 02:02:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLxMu-00031o-Jr
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 02:02:56 -0500
Received: from [210.180.30.141] (helo=goodnplenty.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FLxMq-0001Dt-P6
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 02:02:56 -0500
Message-ID: <000001c64d7e$9da397c0$9adba8c0@cih50>
Reply-To: "Kimberleigh Gosnell" 
From: "Kimberleigh Gosnell" 
To: webdav-archive@ietf.org
Subject: Re: Ry2oT52 news
Date: Wed, 22 Mar 2006 02:02:43 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C64D54.B4CD8FC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.3 (++++)
X-Scan-Signature: f5932bfc8385127f631fc458a872feb1

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C64D54.B4CD8FC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Do you want to e O k V q E c R v P o A c Y for your n M m e u d q i m a
a c q t j i o o j n x s ?
=20
Nothing like you need it, m S f a l v o e over f 5 z 0 f % with
http://geocities.com/AliDoStilesrdne/
=20
w V p a c I r i x u e m $ z 105 30 Nq   n p h i m l n l w s
q C x i q a m I d i c s $9 s 9 1 oA 0  p p u i x l o l d s
z V q i n a y g z r c a $ i 69 1 WA 0  w p b i c l s l c s

------=_NextPart_000_0001_01C64D54.B4CD8FC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi,


 


Do you want to  e O k V q E c R v P o A c Y for your  n M m e u d q i m a a c q t j i o o j n x s ?


 



 


 w V p a c I r i x u e m $ z 105 30 Nq   n p h i m l n l w s


 q C x i q a m I d i c s $9 s 9 1 oA 0  p p u i x l o l d s


 z V q i n a y g z r c a $ i 69 1 WA 0  w p b i c l s l c s

------=_NextPart_000_0001_01C64D54.B4CD8FC0--






From w3c-dist-auth-request@listhub.w3.org Wed Mar 22 03:47:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLz09-0000az-N5
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 03:47:33 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FLz08-0005NG-EA
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 03:47:33 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FLyzo-00044g-0U
	for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Mar 2006 08:47:12 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FLyze-00042O-D9
	for w3c-dist-auth@listhub.w3.org; Wed, 22 Mar 2006 08:47:02 +0000
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FLyzc-0005YI-1F
	for w3c-dist-auth@w3.org; Wed, 22 Mar 2006 08:47:02 +0000
Received: (qmail invoked by alias); 22 Mar 2006 08:46:58 -0000
Received: from p508FA53C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.165.60]
  by mail.gmx.net (mp042) with SMTP; 22 Mar 2006 09:46:58 +0100
X-Authenticated: #1915285
Message-ID: <44210EB6.4080400@gmx.de>
Date: Wed, 22 Mar 2006 09:45:42 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Jason Crawford 
CC:  w3c-dist-auth@w3.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FLyzc-0005YI-1F de3ba567226d6f78affe172eeb0c4e14
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518 -- XSS
X-Archived-At: http://www.w3.org/mid/44210EB6.4080400@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12266
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Wed, 22 Mar 2006 08:47:12 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


Jason Crawford wrote:
> 
> On Tuesday, 03/21/2006 at 03:32 CET, Julian Reschke 
>  wrote:
>  > Hi,
>  >
>  > I think that Kevin is correct that this is a new type of attack not
>  > discussed before, although I think it's misleading to call it an XSS 
> attack.
>  >
>  > I have opened a BugZilla issue for it
>  > (). Once we
>  > have consensus that this is a real problem, we need to discuss what to
>  > say in the Security Considerations section.
> 
>  From viruses, to spam, to copyrighted art,
> to offensive material, this is a pervasive issue that
> people should already be aware of.
> I don't think WebDAV adds much new here and I don't think it's
> necesary for the webdav spec to take responsibility for warning
> people about letting people or zombies put inappropriate content
> in public places.  

Jason,

the big difference here is that the vulnerability is with HTML content 
even in the absence of any browser bug. I really think this is different 
from the other stuff.

Best regards, Julian







From XLQXUFNAQPGQHC@ericcompanies.com Wed Mar 22 07:01:44 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM224-00080a-Pe
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 07:01:44 -0500
Received: from [61.51.227.11] (helo=156.154.16.150)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FM21y-0003kU-E9
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 07:01:44 -0500
Received: from .anu..au ([231.124.240.234
 ] helo=anu..au)
	by smtp6..co with esmtp 
	id 1A5Ys6-781126-97
Message-ID: 
Sender: freeradius-devel-XLQXUFNAQPGQHC@ericcompanies.com
X-Mailman-Version: 2.0.1
Date: Wed, 22 Mar 2006 14:57:37 +0300
From: "Refugio Manuel" 
To: webdav-archive@ietf.org
Subject:  Invoice is Ready
X-Spam-Score: 4.2 (++++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

"Ci-iallis Sof-tabs" is better than Pfizer V-iiag`grra
and normal Ci-ialis because:

- Guarantes 36 hours lasting
- Safe to take, no side effectts at all
- Boost and increase se-xual perfoormance
- Haarder e-rectiiions and quick recharge
- Proven and c-ertified by e-xperts and d-octors
- only $1.98 per tabs
- Special offeer! These prices 
- are valid u-ntil 30th of March !
 
C-lick he`re: http://svezamobilne.info















         
        
          
       
       
       



From w3c-dist-auth-request@listhub.w3.org Wed Mar 22 12:04:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM6kc-0005Zh-9m
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 12:04:02 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FM6kb-0008Qa-0l
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 12:04:02 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FM6j9-0003kE-1P
	for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Mar 2006 17:02:31 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FM6j0-0003jS-Ec
	for w3c-dist-auth@listhub.w3.org; Wed, 22 Mar 2006 17:02:22 +0000
Received: from mail-out3.apple.com ([17.254.13.22])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FM6iq-0000UC-7m
	for w3c-dist-auth@w3.org; Wed, 22 Mar 2006 17:02:21 +0000
Received: from relay5.apple.com (relay5.apple.com [17.128.113.35])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k2MH2Aeg017304
	for ; Wed, 22 Mar 2006 09:02:10 -0800 (PST)
Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212])
	by relay5.apple.com (Apple SCV relay) with ESMTP id 38298324018
	for ; Wed, 22 Mar 2006 09:02:08 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v807)
In-Reply-To: <4420687A.5060400@gmx.de>
References:  <4420687A.5060400@gmx.de>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4C512FC1-5702-4995-9738-234FBCBE02CA@apple.com>
Content-Transfer-Encoding: 7bit
From: Jim Luther 
Date: Wed, 22 Mar 2006 09:02:11 -0800
To: w3c-dist-auth@w3.org
X-Mailer: Apple Mail (2.807)
X-Brightmail-Tracker: AAAAAA==
Received-SPF: pass (aji.w3.org: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1FM6iq-0000UC-7m da55759979675c954b87859e8f5976c5
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518
X-Archived-At: http://www.w3.org/mid/4C512FC1-5702-4995-9738-234FBCBE02CA@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12267
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Wed, 22 Mar 2006 17:02:31 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca


On Mar 21, 2006, at 12:56 PM, Julian Reschke wrote:

> OK,
>
> trying to summarize:
>
> - RFC2518 and RFC2518bis suggest best-effort behavior for COPY + MOVE

That is correct.

> - John B says that most users (+ client implementors) would prefer  
> atomic semantics, at least for MOVE

The Mac OS X WebDAV file system also prefers atomic semantics for MOVE.

Since many Mac OS X documents are packaged as bundles (bundles are  
well defined directory structures -- see http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Concepts/about.html) 
, a MOVE that isn't atomic can corrupt applications, frameworks, plug- 
ins, and documents that are bundles.

> - many servers are not capable of implementing atomic behavior

That is correct.

> - the BIND spec already defines an atomic version of MOVE, which is  
> REBIND.

That is correct. I only wish REBIND had been thought of when rfc2518  
was being written. Too late now...

> Questions:
>
> 1) Is there any reason to modify RFC2518bis' current language?

I don't believe so.

> 2) For implementors who want to use an atomic version of MOVE, is  
> REBIND sufficient?

For future servers and clients, I think REBIND is a good solution.

However, until all clients which need an atomic version of MOVE  
support REBIND, and until all servers those clients need to access  
support REBIND, there's going to be some interoperability problems.  
They are not problems with rfc2518bis -- they are problems in the way  
WebDAV is marketed by some as a protocol for a specific purpose (see http://www.apple.com/macosx/features/networking/ 
  for an example) when WebDAV is really a generic protocol that can be  
used for lots of purposes.

- Jim




From fulluferoze@pager.mels.ru Wed Mar 22 13:14:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FM7qu-0004kN-32
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 13:14:36 -0500
Received: from host128-177.pool8710.interbusiness.it ([87.10.177.128] helo=pager.mels.ru)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FM7qq-0002gC-A3
	for webdav-archive@ietf.org; Wed, 22 Mar 2006 13:14:36 -0500
Message-ID: <000001c64ddc$6deefac0$5ddea8c0@yvm75>
Reply-To: "Feroze Fullington" 
From: "Feroze Fullington" 
To: webdav-archive@ietf.org
Subject: Re: EapoJ21 news
Date: Wed, 22 Mar 2006 13:14:15 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C64DB2.8518F2C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C64DB2.8518F2C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
e C x I d A n L w I o S
v V i A e L k I j U p M
q V o I l A w G d R e A
=20
B ad uy your t M s e f d c i e c s a t t s i k o i n onlin um e at half
y p j r k i v c t e http://www.peresonitionz.com
=20

------=_NextPart_000_0001_01C64DB2.8518F2C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









 


 e C x I d A n L w I o S


 v V i A e L k I j U p M


 q V o I l A w G d R e A


 


B ad uy your  t M s e f d c i e c s a t t s i k o i n onlin um e at half  y p j r k i v c t e http://www.peresonitionz.com

------=_NextPart_000_0001_01C64DB2.8518F2C0--






From w3c-dist-auth-request@listhub.w3.org Wed Mar 22 17:18:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMBeW-0001kt-Pu
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 17:18:04 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMBeV-0005I1-I4
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 17:18:04 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FMBca-0002k2-I6
	for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Mar 2006 22:16:04 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FMBcS-0002ig-Pf
	for w3c-dist-auth@listhub.w3.org; Wed, 22 Mar 2006 22:15:57 +0000
Received: from mail-out3.apple.com ([17.254.13.22])
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FMBcL-0005mq-0l
	for w3c-dist-auth@w3.org; Wed, 22 Mar 2006 22:15:55 +0000
Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k2MMFcn8018065;
	Wed, 22 Mar 2006 14:15:38 -0800 (PST)
Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43])
	by relay6.apple.com (Apple SCV relay) with ESMTP id 4004422B;
	Wed, 22 Mar 2006 14:15:38 -0800 (PST)
In-Reply-To: <44183547.2070100@greenbytes.de>
References: <44183547.2070100@greenbytes.de>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Cc: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= 
Date: Wed, 22 Mar 2006 14:15:35 -0800
To: Manfred Baedke 
X-Mailer: Apple Mail (2.746.2)
X-Brightmail-Tracker: AAAAAA==
Received-SPF: pass (aji.w3.org: domain of wsanchez@apple.com designates 17.254.13.22 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1FMBcL-0005mq-0l ecee938e2485cc06d5c30b860c62f0f1
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: the term 'DAV-compliance'
X-Archived-At: http://www.w3.org/mid/F18FF973-BF9D-46C5-9679-21742A63B67F@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12268
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Wed, 22 Mar 2006 22:16:04 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


   Well, a resource can return a FORBIDDEN response to (just about?)  
any method and still comply, so implementing a method that you don't  
want people to invoke is pretty trivial, no?

	-wsv


On Mar 15, 2006, at 7:39 AM, Manfred Baedke wrote:

> A DAV-compliant resource has to support all methods defined in the  
> spec with the exception of LOCK and UNLOCK.





From w3c-dist-auth-request@listhub.w3.org Wed Mar 22 17:44:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMC40-0002Z0-3z
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 17:44:24 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMC3y-0006Iu-Sx
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 17:44:24 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FMC3c-0000Dv-VO
	for w3c-dist-auth-dist@listhub.w3.org; Wed, 22 Mar 2006 22:44:00 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FMC3V-0000DJ-CV
	for w3c-dist-auth@listhub.w3.org; Wed, 22 Mar 2006 22:43:53 +0000
Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de)
	by lisa.w3.org with esmtp (Exim 4.50)
	id 1FMC3T-0007U3-06
	for w3c-dist-auth@w3.org; Wed, 22 Mar 2006 22:43:53 +0000
Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id D728D4A3F7;
	Wed, 22 Mar 2006 23:43:48 +0100 (CET)
Message-ID: <4421D323.5050609@greenbytes.de>
Date: Wed, 22 Mar 2006 23:43:47 +0100
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= 
CC:  w3c-dist-auth@w3.org
References: <44183547.2070100@greenbytes.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Received-SPF: none (lisa.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FMC3T-0007U3-06 6aa314c8a8d7ec1f2d7fe2582f337086
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: the term 'DAV-compliance'
X-Archived-At: http://www.w3.org/mid/4421D323.5050609@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12269
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Wed, 22 Mar 2006 22:44:00 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007


Well, even if one did that, what is the point of telling the client that=20
the server actually supports a method, only the send FORBIDDEN in every=20
case?

Regards,
Manfred

Wilfredo S=E1nchez Vega wrote:
>
>   Well, a resource can return a FORBIDDEN response to (just about?)=20
> any method and still comply, so implementing a method that you don't=20
> want people to invoke is pretty trivial, no?
>
>     -wsv
>
>
> On Mar 15, 2006, at 7:39 AM, Manfred Baedke wrote:
>
>> A DAV-compliant resource has to support all methods defined in the=20
>> spec with the exception of LOCK and UNLOCK.
>
>




From w3c-dist-auth-request@listhub.w3.org Wed Mar 22 22:59:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMGyv-00050w-6K
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 22:59:29 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMGyt-0004GJ-I9
	for webdav-archive@lists.ietf.org; Wed, 22 Mar 2006 22:59:29 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FMGxv-0005s4-Oj
	for w3c-dist-auth-dist@listhub.w3.org; Thu, 23 Mar 2006 03:58:27 +0000
Received: from aji.w3.org ([133.27.228.225])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FMGxl-0005rP-KB
	for w3c-dist-auth@listhub.w3.org; Thu, 23 Mar 2006 03:58:18 +0000
Received: from [67.136.24.154] (helo=bandage.seagull.net)
	by aji.w3.org with esmtp (Exim 4.50)
	id 1FMGxc-0000Ep-RB
	for w3c-dist-auth@w3.org; Thu, 23 Mar 2006 03:58:16 +0000
Received: (mail@localhost) by bandage.seagull.net (8.13.3) id k2N3w4oF000575 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 22 Mar 2006 19:58:04 -0800
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by bandage.seagull.net (8.13.3) with ESMTP id k2N3w2VX000391 sender obsfucated@us.ibm.com; Wed, 22 Mar 2006 19:58:03 -0800
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2N3vnUI020247; Wed, 22 Mar 2006 22:57:49 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2N3vn8q255304; Wed, 22 Mar 2006 22:57:49 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2N3vnAS007879; Wed, 22 Mar 2006 22:57:49 -0500
Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2N3vnxB007876; Wed, 22 Mar 2006 22:57:49 -0500
To: Julian Reschke 
Cc: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Jason Crawford 
Message-ID: 
Date: Wed, 22 Mar 2006 22:57:38 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF18 | February 28, 2006) at 03/22/2006 22:57:48, Serialize complete at 03/22/2006 22:57:48
Content-Type: multipart/alternative; boundary="=_alternative 0014A62F8525713A_="
Received-SPF: none (aji.w3.org: domain of nn683849@smallcue.com does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=0.0
X-W3C-Scan-Sig: aji.w3.org 1FMGxc-0000Ep-RB 6e0215d561885cf9ae0243fcc8d59748
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518 -- XSS
X-Archived-At: http://www.w3.org/mid/OFF9178914.CD78BDDE-ON8525713A.001462F3-8525713A.0015C214@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12270
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Thu, 23 Mar 2006 03:58:27 +0000
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d


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

> the big difference here is that the vulnerability is with HTML content
> even in the absence of any browser bug. I really think this is different
> from the other stuff.

I've reread the entry in bugzilla and withdraw my comment.

J.

--=_alternative 0014A62F8525713A_=
Content-Type: text/html; charset="US-ASCII"



> the big difference here is that
the vulnerability is with HTML content

> even in the absence of any browser bug. I really think this is different

> from the other stuff.



I've reread the entry in bugzilla and
withdraw my comment.



J.


--=_alternative 0014A62F8525713A_=--




From shauna@ingrid.org Sun Mar 26 20:34:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNgdC-0008MB-9Z
	for webdav-archive@ietf.org; Sun, 26 Mar 2006 20:34:54 -0500
Received: from [218.8.100.246] (helo=ingrid.org)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FNgdA-00037m-63
	for webdav-archive@ietf.org; Sun, 26 Mar 2006 20:34:54 -0500
Message-ID: <000001c6513e$9af4bb30$0875a8c0@ncn96>
Reply-To: "Shauna Heuer" 
From: "Shauna Heuer" 
To: webdav-archive@ietf.org
Subject: Re: new
Date: Sun, 26 Mar 2006 20:34:35 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C65114.B21EB330"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.2 (++++)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C65114.B21EB330
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Do you want to e O i V z E y R b P o A s Y for your h M y e o d u i u c
b a m t p i z o l n b s?
=20
I don't think you need it, i S v A f V w E b 5 e 0 y % with
http://muri25.kapermet.com

------=_NextPart_000_0001_01C65114.B21EB330
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi,


 


Do you want to  e O i V z E y R b P o A s Y for your  h M y e o d u i u c b a m t p i z o l n b s?


 


I don't think you need it,  i S v A f V w E  b 5 e 0 y % with http://muri25.kapermet.com
<=
/BODY>
------=_NextPart_000_0001_01C65114.B21EB330--






From w3c-dist-auth-request@listhub.w3.org Mon Mar 27 20:32:30 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO34Q-00079z-BO
	for webdav-archive@lists.ietf.org; Mon, 27 Mar 2006 20:32:30 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FO34P-0007mT-3D
	for webdav-archive@lists.ietf.org; Mon, 27 Mar 2006 20:32:30 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FO339-0002DO-Gf
	for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Mar 2006 01:31:11 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FO32y-0002Bp-JI
	for w3c-dist-auth@listhub.w3.org; Tue, 28 Mar 2006 01:31:00 +0000
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FO32v-0006YN-QC
	for w3c-dist-auth@w3.org; Tue, 28 Mar 2006 01:31:00 +0000
Received: from localhost (localhost [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 54D611422CB
	for ; Mon, 27 Mar 2006 17:30:56 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 23769-05 for ;
	Mon, 27 Mar 2006 17:30:54 -0800 (PST)
Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id EB16E1422CA
	for ; Mon, 27 Mar 2006 17:30:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <17496C8C-A063-4632-8780-E78B42CD1161@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: webdav WG 
From: Lisa Dusseault 
Date: Mon, 27 Mar 2006 17:30:43 -0800
X-Mailer: Apple Mail (2.746.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received-SPF: none (maggie.w3.org: domain of lisa@osafoundation.org does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FO32v-0006YN-QC 62b725c599811ea555783ae7c2dd7fbc
X-Original-To: w3c-dist-auth@w3.org
Subject: Next steps -- WG last call issues on RFC2518bis
X-Archived-At: http://www.w3.org/mid/17496C8C-A063-4632-8780-E78B42CD1161@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12271
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Tue, 28 Mar 2006 01:31:11 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126



I've been reading the issues that have come up during WG last call,  
but I haven't yet got any proposals how to deal with them.  Proposals  
from others are welcome (I believe Julian already made one).  I'm  
expecting we'll need to schedule more phone calls to agree how to  
deal with the issues.

I'm going to be on vacation from tomorrow through Monday, but I can  
make a call again at our regular time next week -- Wednesday, April  
5, or Friday, April 7.  By that time I assume we can all prepare for  
a list of issues to start with, if somebody wants to suggest such a  
list.  Perhaps we can even recommend approaches for some of them and  
discuss the proposal more than the issues.

Cullen? Elias?

Lisa




From w3c-dist-auth-request@listhub.w3.org Tue Mar 28 05:14:19 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOBDP-0005gG-GH
	for webdav-archive@lists.ietf.org; Tue, 28 Mar 2006 05:14:19 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOBDO-0002zI-8V
	for webdav-archive@lists.ietf.org; Tue, 28 Mar 2006 05:14:19 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FOBBv-0006sD-W1
	for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Mar 2006 10:12:47 +0000
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FOBBm-0006rS-UA
	for w3c-dist-auth@listhub.w3.org; Tue, 28 Mar 2006 10:12:38 +0000
Received: from mail.gmx.net ([213.165.64.20])
	by lisa.w3.org with smtp (Exim 4.50)
	id 1FOBBj-0000pV-MQ
	for w3c-dist-auth@w3.org; Tue, 28 Mar 2006 10:12:38 +0000
Received: (qmail invoked by alias); 28 Mar 2006 10:05:53 -0000
Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233]
  by mail.gmx.net (mp042) with SMTP; 28 Mar 2006 12:05:53 +0200
X-Authenticated: #1915285
Message-ID: <44290A2D.9050508@gmx.de>
Date: Tue, 28 Mar 2006 12:04:29 +0200
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Lisa Dusseault 
CC: webdav WG 
References: <17496C8C-A063-4632-8780-E78B42CD1161@osafoundation.org>
In-Reply-To: <17496C8C-A063-4632-8780-E78B42CD1161@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: lisa.w3.org 1FOBBj-0000pV-MQ 042aa28a73d095c501b98ec87add0133
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Next steps -- WG last call issues on RFC2518bis
X-Archived-At: http://www.w3.org/mid/44290A2D.9050508@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12272
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Tue, 28 Mar 2006 10:12:47 +0000
X-Spam-Score: 1.8 (+)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


Lisa Dusseault wrote:
> 
> 
> I've been reading the issues that have come up during WG last call, but 
> I haven't yet got any proposals how to deal with them.  Proposals from 
> others are welcome (I believe Julian already made one).  I'm expecting 
> we'll need to schedule more phone calls to agree how to deal with the 
> issues.
> 
> I'm going to be on vacation from tomorrow through Monday, but I can make 
> a call again at our regular time next week -- Wednesday, April 5, or 
> Friday, April 7.  By that time I assume we can all prepare for a list of 
> issues to start with, if somebody wants to suggest such a list.  Perhaps 
> we can even recommend approaches for some of them and discuss the 
> proposal more than the issues.
> 
> Cullen? Elias?

I believe it would be good to start with the actual work ASAP. While you 
are absent, the best thing we can do is probably start going through the 
issues that have been raised and discuss them here on the mailing list.

Furthermore, I haven't seen any last-call comments from 
Elias/Jim/Cullen/Geoff -- I'd love to think this means you all read the 
document start-to-end and didn't have any, but somehow I'm not convinced 
that this is true :-).

Best regards, Julian




From huseilinfor@atlasdesign.se Tue Mar 28 08:02:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FODqE-0007RG-Ko
	for webdav-archive@ietf.org; Tue, 28 Mar 2006 08:02:34 -0500
Received: from [85.105.51.164] (helo=atlasdesign.se)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FODqD-0001Xz-09
	for webdav-archive@ietf.org; Tue, 28 Mar 2006 08:02:34 -0500
Message-ID: <000001c65267$d89e4d00$efdaa8c0@iuy44>
Reply-To: "Linford Huse" 
From: "Linford Huse" 
To: webdav-archive@ietf.org
Subject: great news
Date: Tue, 28 Mar 2006 08:02:19 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C6523D.EFC84500"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6523D.EFC84500
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Do you want to overp ay for your M e d s?
Nothing like you need it,
=20
V is it our site http://deae87.valanderasil.com and S A V E up to 50%

------=_NextPart_000_0001_01C6523D.EFC84500
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Hi,


 


Do you want to overp ay for your M e d =
s?


Nothing like you need it,


 


------=_NextPart_000_0001_01C6523D.EFC84500--






From ajones@1-jobs.com Tue Mar 28 10:45:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOGNt-0004lO-HM
	for webdav-archive@ietf.org; Tue, 28 Mar 2006 10:45:29 -0500
Received: from [85.99.102.57] (helo=jlia72rvvo085s7)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOGNq-00084A-1J
	for webdav-archive@ietf.org; Tue, 28 Mar 2006 10:45:29 -0500
Date: Two, 28 Mar 2006 15:45:25  -0120
From: "Carrie Root" 
X-Mailer: The Bat! (v3.6.07) CD5BF9353B3B7091
Reply-To: "Carrie Root" 
X-Priority: 3 (Normal)
Message-ID: <9282950650.20060328154525@1-jobs.com>
To: webdav-archive@ietf.org
Subject: [re:] Biggest pick
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

There is a Big PR Campaign running  ALL Weekend!
Get PIFR First Thing Monday, This Is Going To Explode!

Check out  HOT NEWS!!!

PREMIER INFORMATION (PIFR)

Current Price: $.69
Up .22 in last 2 days!
Up .10 more Today 
Already Starting to move!

Before we start with the profile of PIFR we would like to mention something very important: There is a Big PR Campaign started  today. We are already seeing movement it will go all week so it would be best to get in NOW

PREMIER INFORMATION (PIFR) 

Climbs 100% plus since its IPO, just signing an agreement with TOP 10 in-surancee company in US (AccuQuote). 
The company is pleased and proud to be working with a wide range of clients that includes in-surancee industry leaders Transamerica In-surancee and John Hancock In-surancee, as well as leading online in-surancee br0ker AccuQuote. 
We Do Not See this slowing down, watch out this st0ck go crazy tomorrow. 
This is a Must Watch.. 

PREMIER INFORMATION (PIFR) 
A U.S. based company offers specialized information management serices to both the In surancee and Healthcare Industries. The services we provide are specific to each industry and designed for quick response and maximum security. 







From affiliates@01com.com Thu Mar 30 09:04:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOxks-00007J-Q5
	for webdav-archive@ietf.org; Thu, 30 Mar 2006 09:04:06 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOxks-00050F-Ol
	for webdav-archive@ietf.org; Thu, 30 Mar 2006 09:04:06 -0500
Received: from pl186.nas983.p-aichi.nttpc.ne.jp ([219.102.206.186])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FOxks-00030u-5v
	for webdav-archive@ietf.org; Thu, 30 Mar 2006 09:04:06 -0500
Date: Thu, 30 Mar 2006 14: 4:13  -0540
From: "Chauncey Small" 
X-Mailer: The Bat! (v3.51.10) CD5BF9353B3B7091
Reply-To: "Chauncey Small" 
X-Priority: 3 (Normal)
Message-ID: <2313139555.20060330140413@01com.com>
To: webdav-archive@ietf.org
Subject: fw: Make sure you see this
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

There is a Big PR Campaign running  ALL Week!
Get KKPT First Thing, This Is Going To Explode!

Check out  HOT NEWS!!!

KOKO PETROLEUM (KKPT) - This is our #1 pick this week
Our last pick gained $2.16 in 4 days of trading.
 
Current Price: $1.09
5 day expected price $2.10
This is been a great producer in our last PR Campaign

KOKO Petroleum, Inc. (PKKPT - News) announced today that it has revised its Letter of Intent with JMT Resources, Ltd. Fort Worth Texas regarding the Development of JMT's polymer flood pilot program on its leasehold located in Corsicana, Texas.

The previous agreement focused only on the pilot program for the polymer flood in a specific area of JMT's acreage. The revised agreement gives KOKO the right, via a master joint venture, to participate in all of JMT's acreage in the Corsicana Field which totals 7,838 acres. As mentioned in previous releases, this leasehold is the oldest oil field in Texas and was discovered in the 1890's by a company that eventually became Mobil Oil.

Recent geological analyses indicated there are several zones under the Nacatoch zone (where the polymer flood is being developed) which are oil bearing and have an excellent possibility for commercial production. These zones include the Pecan Gap, Austin Chalk and Wolf City. The joint venture plans on shooting 3D seismic over portions of the Field to better understand the potential of these zones and corresponding reserves. Subsequently, an aggressive horizontal and vertical drilling plan will be implemented to capitalize on the seismic findings.



From naugle@tonine.de Thu Mar 30 12:50:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP1Hc-00010b-6F
	for webdav-archive@ietf.org; Thu, 30 Mar 2006 12:50:08 -0500
Received: from host86-137-186-255.range86-137.btcentralplus.com ([86.137.186.255] helo=tonine.de)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FP1HZ-00086L-FJ
	for webdav-archive@ietf.org; Thu, 30 Mar 2006 12:50:08 -0500
Message-ID: <000001c65417$ec8fdcf0$86b1a8c0@czu66>
Reply-To: "Hiroko Naugle" 
From: "Hiroko Naugle" 
To: webdav-archive@ietf.org
Subject: news day
Date: Thu, 30 Mar 2006 11:35:15 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C653EE.03B9D4F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C653EE.03B9D4F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

D 6 ear Home O 1 wner ,=20
 =20
Your cr 3 edi E t doesn't matter to us !=20
 =20
Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at
2 e=20
and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply
wish=20
to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the
d h eaI B s=20
we have T G ODA k Y :=20
 =20
$ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e=20
$ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te=20
$ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y=20
$ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e=20
$ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e=20
 =20
H 1 urry, when these d N eaI Q s are gone, they are gone !
 =20
Don't worry about a d pproval, your cred q it will not di p squ 0 alify
you !=20
 =20
V 7 is T it our s F ite =20
 =20
Sincerely, Hiroko Naugle
 =20
Ap 9 prova A l Manager


------=_NextPart_000_0001_01C653EE.03B9D4F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









------=_NextPart_000_0001_01C653EE.03B9D4F0--






From bauer@hunnysoft.com Fri Mar 31 03:43:33 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPFED-0003DD-Al
	for webdav-archive@ietf.org; Fri, 31 Mar 2006 03:43:33 -0500
Received: from 154.red-83-43-107.dynamicip.rima-tde.net ([83.43.107.154] helo=hunnysoft.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FPFEA-0005E3-LA
	for webdav-archive@ietf.org; Fri, 31 Mar 2006 03:43:33 -0500
Message-ID: <000001c65417$ec8fdcf0$86b1a8c0@czu66>
Reply-To: "Barbro Bauer" 
From: "Barbro Bauer" 
To: webdav-archive@ietf.org
Subject: news day
Date: Thu, 30 Mar 2006 11:35:15 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C653EE.03B9D4F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C653EE.03B9D4F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

D 6 ear Home O 1 wner ,=20
 =20
Your cr 3 edi E t doesn't matter to us !=20
 =20
Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at
2 e=20
and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply
wish=20
to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the
d h eaI B s=20
we have T G ODA k Y :=20
 =20
$ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e=20
$ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te=20
$ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y=20
$ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e=20
$ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e=20
 =20
H 1 urry, when these d N eaI Q s are gone, they are gone !
 =20
Don't worry about a d pproval, your cred q it will not di p squ 0 alify
you !=20
 =20
V 7 is T it our s F ite =20
 =20
Sincerely, Barbro Bauer
 =20
Ap 9 prova A l Manager


------=_NextPart_000_0001_01C653EE.03B9D4F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









D 6 ear Home O 1 wner , 

  

Your cr 3 edi E t doesn't matter to us ! 

  

Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at 2 e 

and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply wish 

to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the d h eaI B s 

we have T G ODA k Y : 

  

$ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e 

$ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te 

$ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y 

$ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e 

$ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e 

  

H 1 urry, when these d N eaI Q s are gone, they are gone !

  

Don't worry about a d pproval, your cred q it will not di p squ 0 alify you ! 

  

V 7 is T it our s F ite

  

Sincerely, Barbro Bauer

  

Ap 9 prova A l Manager

------=_NextPart_000_0001_01C653EE.03B9D4F0--






From w3c-dist-auth-request@listhub.w3.org Fri Mar 31 10:08:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPLEf-0000SM-C6
	for webdav-archive@lists.ietf.org; Fri, 31 Mar 2006 10:08:25 -0500
Received: from frink.w3.org ([128.30.52.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPLEe-0006Sz-VM
	for webdav-archive@lists.ietf.org; Fri, 31 Mar 2006 10:08:25 -0500
Received: from lists by frink.w3.org with local (Exim 4.50)
	id 1FPLCV-0003Jq-MV
	for w3c-dist-auth-dist@listhub.w3.org; Fri, 31 Mar 2006 15:06:11 +0000
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1FPLCN-0003JF-LM
	for w3c-dist-auth@listhub.w3.org; Fri, 31 Mar 2006 15:06:03 +0000
Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de)
	by maggie.w3.org with esmtp (Exim 4.50)
	id 1FPLCE-00017U-Pa
	for w3c-dist-auth@w3.org; Fri, 31 Mar 2006 15:06:02 +0000
Received: from [192.168.1.80] (farnsworth.greenbytes.de [192.168.1.80])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id C2BE54A47D
	for ; Fri, 31 Mar 2006 17:05:53 +0200 (CEST)
Message-ID: <442D454E.6030207@greenbytes.de>
Date: Fri, 31 Mar 2006 17:05:50 +0200
From: Manfred Baedke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: webdav WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: none (maggie.w3.org: domain of manfred.baedke@greenbytes.de does not designate permitted sender hosts)
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: maggie.w3.org 1FPLCE-00017U-Pa 881b05797dbbf9b835e0bbf9e025ee64
X-Original-To: w3c-dist-auth@w3.org
Subject: feedback on rfc2518bis-14: locking
X-Archived-At: http://www.w3.org/mid/442D454E.6030207@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/12273
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: 
List-Help: 
List-Unsubscribe: 
Resent-Message-Id: 
Resent-Date: Fri, 31 Mar 2006 15:06:11 +0000
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff


Since I criticized the sections 6 and 7 in previous mails, I think I 
should make a proposal for the normative parts of them (which should
of course be completed by examples and, possibly, some non-normative
explanations). Note that almost all subsections of sections 7 are 
removed, which is really meant this way.


6.  Locking

    The ability to lock a resource provides a mechanism for serializing
    access to that resource.  Using a lock, an authoring client can
    provide a reasonable guarantee that another principal will not modify
    a resource while it is being edited.  In this way, a client can
    prevent the "lost update" problem.

    This specification allows locks to vary over two client-specified
    parameters, the number of principals involved (exclusive vs. shared)
    and the type of access to be granted.  This document defines locking
    for only one access type, write.  However, the syntax is extensible,
    and permits the eventual specification of locking for other access
    types.

6.1.  Lock Model

   This section provides a concise model for how locking behaves.  Later
   sections will provide more detail on some of the concepts and refer
   back to these model statements.  Normative statements related to LOCK
   and UNLOCK handling can be found in the sections on those methods,
   whereas normative statements that cover any method are gathered here.

   1.  A lock either directly or indirectly locks a resource.

   2.  A resource becomes directly locked when a LOCK request to an URL
       of that resource creates a new lock.  The "lock-root" of the new
       lock is that URL.  If at the time of the request, the URL is not
       mapped to a resource, a new empty resource is created and
       directly locked.

   3.  A lock is either exclusive or shared. An exclusive lock conflicts
       with any other kind of lock on the same resource, whether either
       lock is direct or indirect.  A server MUST NOT create conflicting
       locks on a resource.

   4.  If a collection C is locked with an infinite depth lock L, the set
       of resources that are indirectly locked by L is exactly the set 

       of member resources of C:

       *  If a new element is added to the set of member resources of
          the collection, then the new member resource MUST become
          indirectly locked by L.

       *  If a recource is removed from the set of member resources of
          the collection, then the resource MUST no longer be indirectly
          locked by L.

   5.  Each lock is identified by a single unique lock token
       (Section 6.3).

   6.  An UNLOCK request deletes the lock with the specified lock token.
       After a lock is deleted, no resource is locked by that lock.

   7.  A lock token is "submitted" in a request when it appears in an If
       header (the Write Lock section (Section 7) discusses when token
       submission is required for write locks).

   8.  Any operation which causes the lock-root of a lock to become an
       unmapped URL MUST delete the lock.

6.2.  Lock Creator

   The lock creator is the authenticated principal who issued the request
   that created the lock.

   When submission of a lock token is required to perform an operation,
   a server MUST check that the authenticated principal matches the lock
   creator.

6.3.  Lock Tokens

   A lock token is a type of state token which identifies a particular
   lock.  Each lock has exactly one unique lock token generated by the
   server.  Clients MUST NOT attempt to interpret lock tokens in any
   way.

   Lock token URIs MUST be unique across all resources for all time.

   Servers MAY make lock tokens publicly readable (e.g. in the DAV:
   lockdiscovery property).  One use case for making lock tokens
   readable is so that a long-lived lock can be deleted by the resource
   owner (the client that issued the lock request might have crashed or
   disconnected before deleting the lock).  Except for the case of
   using UNLOCK (Section 9.11) under user guidance, a client SHOULD NOT
   use a lock token created by another client instance.

   This specification encourages servers to create UUIDs for lock
   tokens, and to use the URI form defined by "A Universally Unique
   Identifier (UUID) URN Namespace" ([RFC4122]).  However servers are
   free to use any URI (e.g. from another scheme) so long as it meets
   the uniqueness requirements.  For example, a valid lock token might
   be constructed using the "opaquelocktoken" scheme defined in
   Appendix C.

   Example: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

6.4.  Lock Timeout

   A lock MAY have a limited lifetime.  The lifetime is suggested by the
   client when creating or refreshing the lock, but the server
   ultimately chooses the timeout value. Timeout is measured in seconds
   remaining until lock expiration.

   The timeout counter MUST be restarted if a refresh LOCK request is
   successful (see Section 9.10.2).  The timeout counter SHOULD NOT be
   restarted at any other time.

   If the timeout expires then the lock SHOULD be deleted. In this case
   the server SHOULD act as if an UNLOCK request (Section 9.11) was
   successfully performed with the lock token of the timed-out
   lock being submitted.

   A client MUST NOT assume that just because the time-out has expired
   the lock has immediately been deleted.

   Clients MUST assume that locks can arbitrarily disappear at any time,
   regardless of the value given in the Timeout header.
   For example, a sufficiently privileged user may delete a lock at any
   time or the system may crash in such a way that it loses the record
   of the lock's existence.

6.5.  Lock Capability Discovery

   Since server lock support is optional, a client trying to lock a
   resource on a server can either try the lock and hope for the best,
   or perform some form of discovery to determine what lock capabilities
   the server supports.  This is known as lock capability discovery. A
   client can determine what lock types the server supports by
   retrieving the DAV:supportedlock property.

   Any resource that supports the LOCK method MUST support the
   DAV:supportedlock property.

6.8.  Active Lock Discovery

   If another principal locks a resource that a principal wishes to
   access, it is useful for the second principal to be able to find out
   who the first principal is.  For this purpose the DAV:lockdiscovery
   property is provided.  This property contains a (not necessarily
   complete) list of locks that lock the given resource, describes
   their types, and MAY even provide the lock tokens.

   Any resource that supports the LOCK method MUST support the
   DAV:lockdiscovery property.


7.  Write Lock

   This section describes the semantics specific to the write lock type.
   The write lock is a specific instance of a lock type, and is the only
   lock type described in this specification.


7.1 Write Locks and the Lockable State of a Resource

   The lockable state of a resource consists of

    * the content of the resource

    * a set of name-value pairs, containing the names and values of the
      unprotected properties of a resource (the notion of a protected
      property is defined in section 15)

    * the set of internal members of the resource

   If a resource is locked by a write lock L, a request that would change
   the lockable state of this resource MUST fail if the lock token of
   L has not been submitted with the request or if the request was not
   issued by the lock creator of L.






"My main point here is the =
use of=20
undefined terminology, though I indeed think that section 6.1 will be =
perfectly=20
clear on the distinction between a depth 0 and a depth infinity lock as =
soon as=20
6.1.4 uses the term 'member' instead of 'internal member'. 7.4 contains =
nothing=20
new, and a list of special cases can never be as concise as the general=20
principle itself. "