From w3c-dist-auth-request@w3.org Sat Apr 5 15:45:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14464 for ; Sat, 5 Apr 2003 15:45:18 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h35Kl5Z4008870; Sat, 5 Apr 2003 15:47:05 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h35Kks8A008863; Sat, 5 Apr 2003 15:46:54 -0500 (EST) Resent-Date: Sat, 5 Apr 2003 15:46:54 -0500 (EST) Resent-Message-Id: <200304052046.h35Kks8A008863@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h35KkrZ4008831 for ; Sat, 5 Apr 2003 15:46:53 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h35Kkqsi025952 for ; Sat, 5 Apr 2003 15:46:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 191uYp-0007x5-00 for w3c-dist-auth@w3c.org; Sat, 05 Apr 2003 20:46:47 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 191uYo-0007wu-00 for w3c-dist-auth@w3c.org; Sat, 05 Apr 2003 20:46:46 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 5 Apr 2003 12:46:52 -0800 Message-ID: <014e01c2fbb4$7d27f190$7501a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/014e01c2fbb4$7d27f190$7501a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7553 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: Content-Transfer-Encoding: 7bit It seems from draft-ietf-webdav-ordering-protocol-07 that only version-controlled resources are part of the ordering of version-controlled collections (Section 9: "for compatibility with RFC3253, only the ordering of version-controlled members needs to be maintained") Does that mean there's no way to order versioned and unversioned resources together within a version-controlled collection? Lisa From w3c-dist-auth-request@w3.org Sat Apr 5 21:39:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20376 for ; Sat, 5 Apr 2003 21:39:11 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h362fCZ4025037; Sat, 5 Apr 2003 21:41:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h362eoFe024951; Sat, 5 Apr 2003 21:40:50 -0500 (EST) Resent-Date: Sat, 5 Apr 2003 21:40:50 -0500 (EST) Resent-Message-Id: <200304060240.h362eoFe024951@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h362enZ4024916 for ; Sat, 5 Apr 2003 21:40:49 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h362ensi007753 for ; Sat, 5 Apr 2003 21:40:49 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 05 Apr 2003 21:23:29 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sat, 5 Apr 2003 21:40:42 -0500 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Sat, 5 Apr 2003 21:40:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE20260E5C8@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7554 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: From: Lisa Dusseault [mailto:lisa@xythos.com] It seems from draft-ietf-webdav-ordering-protocol-07 that only version-controlled resources are part of the ordering of version-controlled collections (Section 9: "for compatibility with RFC3253, only the ordering of version-controlled members needs to be maintained") Does that mean there's no way to order versioned and unversioned resources together within a version-controlled collection? That is correct. The issue is that when you UPDATE a version-controlled collection with a new version, it can change the set of version-controlled members, and there would not be a way to define what the ordering of the existing non-version-controlled members should be wrt the new version-controlled members. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Apr 6 03:28:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23632 for ; Sun, 6 Apr 2003 03:28:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h367UqZ4009211; Sun, 6 Apr 2003 03:30:53 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h367URAP009187; Sun, 6 Apr 2003 03:30:27 -0400 (EDT) Resent-Date: Sun, 6 Apr 2003 03:30:27 -0400 (EDT) Resent-Message-Id: <200304060730.h367URAP009187@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h367UPZ4009155 for ; Sun, 6 Apr 2003 03:30:25 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h367UPsi013710 for ; Sun, 6 Apr 2003 03:30:25 -0400 Received: (qmail 26365 invoked by uid 65534); 6 Apr 2003 07:30:20 -0000 Received: from p3EE24740.dip.t-dialin.net (HELO lisa) (62.226.71.64) by mail.gmx.net (mp021-rz3) with SMTP; 06 Apr 2003 09:30:20 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Sun, 6 Apr 2003 09:30:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-reply-to: <014e01c2fbb4$7d27f190$7501a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEHLGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7555 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, April 05, 2003 10:47 PM > To: Webdav WG > Subject: Ordered collections and versioned collections > > > > > It seems from draft-ietf-webdav-ordering-protocol-07 that only > version-controlled resources are part of the ordering of > version-controlled collections (Section 9: "for compatibility with > RFC3253, only the ordering of version-controlled members needs to be > maintained") The full context being: "This specification considers both the ordering type (DAV:ordering-type property) and the ordering of collection members to be part of the state of a collection. Therefore both MUST be recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with RFC3253, only the ordering of version-controlled members needs to be maintained)." > Does that mean there's no way to order versioned and unversioned > resources together within a version-controlled collection? Nope. It's supposed to mean that you *can* order both types of resources within a versioned-controlled collection, but collection *versions* will only keep ordering information for those members that were version-controlled. Do I need to rephrase the text to make this clearer? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Apr 6 03:37:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23758 for ; Sun, 6 Apr 2003 03:37:49 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h367duZ4010574; Sun, 6 Apr 2003 03:39:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h367dtVb010555; Sun, 6 Apr 2003 03:39:55 -0400 (EDT) Resent-Date: Sun, 6 Apr 2003 03:39:55 -0400 (EDT) Resent-Message-Id: <200304060739.h367dtVb010555@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h367dtZ4010523 for ; Sun, 6 Apr 2003 03:39:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h367drsi014815 for ; Sun, 6 Apr 2003 03:39:54 -0400 Received: (qmail 28449 invoked by uid 65534); 6 Apr 2003 07:39:47 -0000 Received: from p3EE24740.dip.t-dialin.net (HELO lisa) (62.226.71.64) by mail.gmx.net (mp018-rz3) with SMTP; 06 Apr 2003 09:39:47 +0200 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG" Date: Sun, 6 Apr 2003 09:39:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEHLGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7556 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, April 06, 2003 4:41 AM > To: Webdav WG > Subject: RE: Ordered collections and versioned collections > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > It seems from draft-ietf-webdav-ordering-protocol-07 that only > version-controlled resources are part of the ordering of > version-controlled collections (Section 9: "for compatibility with > RFC3253, only the ordering of version-controlled members needs to > be maintained") > > Does that mean there's no way to order versioned and unversioned > resources together within a version-controlled collection? > > That is correct. The issue is that when you UPDATE a > version-controlled collection with a new version, it can change the > set of version-controlled members, and there would not be a way to > define what the ordering of the existing non-version-controlled > members should be wrt the new version-controlled members. Wait-a-minute :-) For instance, we can define that the UPDATE operation does not define the ordering of those members (that is, the server (a) may insert them in arbitrary places or (b) must insert them at the end). Currently the postcondition is: "(DAV:update-version-controlled-collection-members-ordered): If the request modified the DAV:checked-in version of a version-controlled collection and the DAV:ordering-type for the checked-in version is not unordered ("DAV:unordered"), the version-controlled members MUST be ordered according to the checked-in version's DAV:version-controlled-binding-set property." How about adding: "Members that are not version-controlled MUST be moved to the end of the ordering (in no particular order)." This behaviour would be consistent with section 6.1 (setting the position when no ordering information was specified). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Apr 6 15:15:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04346 for ; Sun, 6 Apr 2003 15:15:30 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h36JHYZ4009655; Sun, 6 Apr 2003 15:17:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h36JHFDQ009626; Sun, 6 Apr 2003 15:17:15 -0400 (EDT) Resent-Date: Sun, 6 Apr 2003 15:17:15 -0400 (EDT) Resent-Message-Id: <200304061917.h36JHFDQ009626@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h36JHEZ4009593 for ; Sun, 6 Apr 2003 15:17:14 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h36JHEsi013531 for ; Sun, 6 Apr 2003 15:17:14 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 06 Apr 2003 14:59:54 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 6 Apr 2003 15:17:08 -0400 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Sun, 6 Apr 2003 15:17:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE20260E5E3@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7557 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: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > It seems from draft-ietf-webdav-ordering-protocol-07 that only > version-controlled resources are part of the ordering of > version-controlled collections (Section 9: "for compatibility with > RFC3253, only the ordering of version-controlled members needs to > be maintained") > > Does that mean there's no way to order versioned and unversioned > resources together within a version-controlled collection? > > That is correct. The issue is that when you UPDATE a > version-controlled collection with a new version, it can change the > set of version-controlled members, and there would not be a way to > define what the ordering of the existing non-version-controlled > members should be wrt the new version-controlled members. For instance, we can define that the UPDATE operation does not define the ordering of those members (that is, the server (a) may insert them in arbitrary places or (b) must insert them at the end). Currently the postcondition is: "(DAV:update-version-controlled-collection-members-ordered): If the request modified the DAV:checked-in version of a version-controlled collection and the DAV:ordering-type for the checked-in version is not unordered ("DAV:unordered"), the version-controlled members MUST be ordered according to the checked-in version's DAV:version-controlled-binding-set property." How about adding: "Members that are not version-controlled MUST be moved to the end of the ordering (in no particular order)." This behaviour would be consistent with section 6.1 (setting the position when no ordering information was specified). That would be fine with me, or just saying that the order of the non-version-controlled members is server-defined following the UPDATE. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Apr 6 16:06:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05077 for ; Sun, 6 Apr 2003 16:06:49 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h36K8sZ4017835; Sun, 6 Apr 2003 16:08:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h36K8bGx017798; Sun, 6 Apr 2003 16:08:37 -0400 (EDT) Resent-Date: Sun, 6 Apr 2003 16:08:37 -0400 (EDT) Resent-Message-Id: <200304062008.h36K8bGx017798@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h36K8aZ4017763 for ; Sun, 6 Apr 2003 16:08:36 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h36K8Zsi021752 for ; Sun, 6 Apr 2003 16:08:36 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 192GRO-0003EZ-00; Sun, 06 Apr 2003 20:08:34 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 192GRN-0003EO-00; Sun, 06 Apr 2003 20:08:34 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Sun, 6 Apr 2003 13:08:34 -0700 Message-ID: <000d01c2fc78$501feda0$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Subject: More on ordered collections X-Archived-At: http://www.w3.org/mid/000d01c2fc78$501feda0$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7558 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: Content-Transfer-Encoding: 7bit Is the position of a newly-defined resource in an ordered collection treated the same way by all servers? It would be nice to be specific about how new resources are added to an ordered collection. I assume that sub-collections are orderable as well? That is, if I have an ordered collection containing several sub-collections, I assume I can define an ordering that includes all sub-collections along with all other children. I believe this is already clear through the term "member" even though none of the examples show a sub-collection. Other questions - If I MOVE a resource within the same collection, must the server preserve its ordering position wrt other resources? - If I COPY a resource within the same collection, where is the new resource placed in the ordering -- next to the old resource (closely preserving its ordering semantics), or at the end, or arbitrary? - If I MOVE or COPY a resource into a collection, overwriting a resource that has an ordering position, is that ordering position (of the destination) preserved? - If I DELETE a resource, must the server preserve the ordering other than that deleted resource? Section 4 could be more explicit that if resource C is after B is after A, then the deletion of B means that C must be after A rather than destroying the ordering relationship. This is worth making explicit because server implementors must either maintain their orderings in a format that is irrelevant to what resources exist (absolute), or relative orderings must be fixed up when a resource is deleted. Note that the answers to the MOVE/COPY questions are particularly important if WebDAV clients do "Safe-save" operations -- e.g. a client that PUTs an new resource then uses COPY to overwrite the existing resource after finding that the PUT worked. There are many other variations in safe-save algorithms, some using MOVE. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Sunday, April 06, 2003 12:17 PM > To: Webdav WG > Subject: RE: Ordered collections and versioned collections > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > > It seems from draft-ietf-webdav-ordering-protocol-07 that only > > version-controlled resources are part of the ordering of > > version-controlled collections (Section 9: "for > compatibility with > > RFC3253, only the ordering of version-controlled > members needs to > > be maintained") > > > > Does that mean there's no way to order versioned and > unversioned > > resources together within a version-controlled collection? > > > > That is correct. The issue is that when you UPDATE a > > version-controlled collection with a new version, it can > change the > > set of version-controlled members, and there would not > be a way to > > define what the ordering of the existing non-version-controlled > > members should be wrt the new version-controlled members. > > For instance, we can define that the UPDATE operation does not > define the ordering of those members (that is, the server (a) may > insert them in arbitrary places or (b) must insert them at the > end). Currently the postcondition is: > > "(DAV:update-version-controlled-collection-members-ordered): If the > request modified the DAV:checked-in version of a version-controlled > collection and the DAV:ordering-type for the checked-in version is > not unordered ("DAV:unordered"), the version-controlled members > MUST be ordered according to the checked-in version's > DAV:version-controlled-binding-set property." > > How about adding: > > "Members that are not version-controlled MUST be moved to > the end of the > ordering (in no particular order)." > > This behaviour would be consistent with section 6.1 > (setting the position > when no ordering information was specified). > > That would be fine with me, or just saying that the order of the > non-version-controlled members is server-defined following the UPDATE. > > Cheers, > Geoff > > From w3c-dist-auth-request@w3.org Mon Apr 7 08:10:24 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18077 for ; Mon, 7 Apr 2003 08:10:24 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37CCGZ4022282; Mon, 7 Apr 2003 08:12:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37CBiRg022213; Mon, 7 Apr 2003 08:11:44 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 08:11:44 -0400 (EDT) Resent-Message-Id: <200304071211.h37CBiRg022213@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37CBdZ4022181 for ; Mon, 7 Apr 2003 08:11:39 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37CBcsi003401 for ; Mon, 7 Apr 2003 08:11:39 -0400 Received: (qmail 26575 invoked by uid 65534); 7 Apr 2003 12:11:32 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp018-rz3) with SMTP; 07 Apr 2003 14:11:32 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Mon, 7 Apr 2003 14:11:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <000d01c2fc78$501feda0$f8cb90c6@xythoslap> Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEINGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7559 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, April 06, 2003 10:09 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: More on ordered collections > > > > Is the position of a newly-defined resource in an ordered collection > treated the same way by all servers? It would be nice to be specific > about how new resources are added to an ordered collection. Yes. > I assume that sub-collections are orderable as well? That is, if I have > an ordered collection containing several sub-collections, I assume I can > define an ordering that includes all sub-collections along with all Nope. Ordering is a property of the internal (!) members of a collection, so it doesn't automatically affect child collections: > other children. I believe this is already clear through the term > "member" even though none of the examples show a sub-collection. > > Other questions > - If I MOVE a resource within the same collection, must the server > preserve its ordering position wrt other resources? That depends on the Position header: > - If I COPY a resource within the same collection, where is the new > resource placed in the ordering -- next to the old resource (closely > preserving its ordering semantics), or at the end, or arbitrary? Same: > - If I MOVE or COPY a resource into a collection, overwriting a > resource that has an ordering position, is that ordering position (of > the destination) preserved? Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE the target. > - If I DELETE a resource, must the server preserve the ordering other > than that deleted resource? Section 4 could be more explicit that if > resource C is after B is after A, then the deletion of B means that C > must be after A rather than destroying the ordering relationship. This > is worth making explicit because server implementors must either > maintain their orderings in a format that is irrelevant to what > resources exist (absolute), or relative orderings must be fixed up when > a resource is deleted. I think this follows from the definition of "ordering" (repeatability of PROPFIND result element ordering). > Note that the answers to the MOVE/COPY questions are particularly > important if WebDAV clients do "Safe-save" operations -- e.g. a client > that PUTs an new resource then uses COPY to overwrite the existing > resource after finding that the PUT worked. There are many other > variations in safe-save algorithms, some using MOVE. Those servers will need to set the Position header accordingly if they want the resulting resource to be in the "original" position. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 13:03:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27587 for ; Mon, 7 Apr 2003 13:03:19 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37H5CZ4021575; Mon, 7 Apr 2003 13:05:12 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37H55Od021477; Mon, 7 Apr 2003 13:05:05 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 13:05:05 -0400 (EDT) Resent-Message-Id: <200304071705.h37H55Od021477@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37H54Z4021445 for ; Mon, 7 Apr 2003 13:05:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37H53si004769 for ; Mon, 7 Apr 2003 13:05:03 -0400 Received: (qmail 31856 invoked by uid 65534); 7 Apr 2003 17:04:57 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 07 Apr 2003 19:04:57 +0200 From: "Julian Reschke" To: "Clemm, Geoff" , "Webdav WG" Date: Mon, 7 Apr 2003 19:04:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: Importance: Normal Subject: RE: Ordered collections and versioned collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEJGGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7560 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, April 06, 2003 9:17 PM > To: Webdav WG > Subject: RE: Ordered collections and versioned collections > > > ... > > How about adding: > > "Members that are not version-controlled MUST be moved to the > end of the > ordering (in no particular order)." > > This behaviour would be consistent with section 6.1 (setting > the position > when no ordering information was specified). > > That would be fine with me, or just saying that the order of the > non-version-controlled members is server-defined following the UPDATE. Agreed (resolved as "server-defined"): -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 13:38:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28765 for ; Mon, 7 Apr 2003 13:38:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37HeUZ4002527; Mon, 7 Apr 2003 13:40:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37HeOhc002454; Mon, 7 Apr 2003 13:40:24 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 13:40:24 -0400 (EDT) Resent-Message-Id: <200304071740.h37HeOhc002454@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37HeNZ4002422 for ; Mon, 7 Apr 2003 13:40:23 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h37HeMsi014240 for ; Mon, 7 Apr 2003 13:40:22 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 192abR-0002Vx-00; Mon, 07 Apr 2003 17:40:17 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 192abR-0002Vm-00; Mon, 07 Apr 2003 17:40:17 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Mon, 7 Apr 2003 10:40:19 -0700 Message-ID: <001401c2fd2c$c3e4b810$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/001401c2fd2c$c3e4b810$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7561 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: Content-Transfer-Encoding: 7bit Sorry, I must not have been sufficiently clear in my questions. I'm mostly discussing operations without the Position header -- operations with clients that aren't aware of ordering. > > Is the position of a newly-defined resource in an ordered collection > > treated the same way by all servers? It would be nice to > be specific > > about how new resources are added to an ordered collection. So this meant, how are resources added to a client-ordered collection when the Position header is missing? Must servers add them to the end of the ordering or can they be put at the beginning or anywhere? > > I assume that sub-collections are orderable as well? That > is, if I have > > an ordered collection containing several sub-collections, I > assume I can > > define an ordering that includes all sub-collections along with all > > Nope. Ordering is a property of the internal (!) members of a > collection, so > it doesn't automatically affect child collections: Again I was unclear. I meant direct sub-collections, or collections which are direct children of the ordered collection. These are ordered together with regular child resources, correct? There are no examples of this but I believe this is what the spec says. > > Other questions > > - If I MOVE a resource within the same collection, must the server > > preserve its ordering position wrt other resources? > > That depends on the Position header: What happens if the Position header is not present? Must servers preserve the ordering or lose it? > > - If I COPY a resource within the same collection, where is the new > > resource placed in the ordering -- next to the old resource (closely > > preserving its ordering semantics), or at the end, or arbitrary? And here, what happens if the COPY method has no Position header? > - If I MOVE or COPY a resource into a collection, overwriting a > resource that has an ordering position, is that ordering position (of > the destination) preserved? > Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE the > target. No, I disagree with this. Overwriting a regular resource does not reset all the live properties. For example, it would be pretty disastrous for the ACL property to be reset every time a resource is overwritten. Besides, the ordering is a property of the parent, not the resource being overwritten. I would expect that ordering would be preserved, but the spec ought to say one way or another. > > - If I DELETE a resource, must the server preserve the ordering other > > than that deleted resource? Section 4 could be more explicit that if > > resource C is after B is after A, then the deletion of B means that C > > must be after A rather than destroying the ordering relationship. This > > is worth making explicit because server implementors must either > > maintain their orderings in a format that is irrelevant to what > > resources exist (absolute), or relative orderings must be fixed up when > > a resource is deleted. > I think this follows from the definition of "ordering" (repeatability of > PROPFIND result element ordering). Then why not make it explicit in the specification? > > Note that the answers to the MOVE/COPY questions are particularly > > important if WebDAV clients do "Safe-save" operations -- e.g. a client > > that PUTs an new resource then uses COPY to overwrite the existing > > resource after finding that the PUT worked. There are many other > > variations in safe-save algorithms, some using MOVE. > Those servers will need to set the Position header accordingly if they want > the resulting resource to be in the "original" position. It is not the servers doing "safe save" operation, it's the clients, and these may be clients that are unaware of ordering or choose not to set the Position header. It's important to consider how a server with an ordered collection interacts with ordinary clients (ones that do not use the Position header). Otherwise, an author that tries to keep their collection ordered may frequently find the ordering unecessarily "messed up" after resources are added, deleted, renamed, or overwritten by non-ordering client software (e.g. Office). Lisa From w3c-dist-auth-request@w3.org Mon Apr 7 14:18:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29714 for ; Mon, 7 Apr 2003 14:18:51 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IH1Z4012304; Mon, 7 Apr 2003 14:17:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37IGrtC012264; Mon, 7 Apr 2003 14:16:53 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 14:16:53 -0400 (EDT) Resent-Message-Id: <200304071816.h37IGrtC012264@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IGpZ4012228 for ; Mon, 7 Apr 2003 14:16:51 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37IGpsi024956 for ; Mon, 7 Apr 2003 14:16:51 -0400 Received: (qmail 21110 invoked by uid 65534); 7 Apr 2003 18:16:44 -0000 Received: from pD950C3B8.dip.t-dialin.net (HELO lisa) (217.80.195.184) by mail.gmx.net (mp017-rz3) with SMTP; 07 Apr 2003 20:16:44 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Webdav WG'" Date: Mon, 7 Apr 2003 20:16:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001401c2fd2c$c3e4b810$f8cb90c6@xythoslap> Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEJMGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7562 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, April 07, 2003 7:40 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: More on ordered collections > > > > Sorry, I must not have been sufficiently clear in my questions. I'm > mostly discussing operations without the Position header -- operations > with clients that aren't aware of ordering. > > > > Is the position of a newly-defined resource in an ordered collection > > > treated the same way by all servers? It would be nice to > be specific > > > about how new resources are added to an ordered collection. > > So this meant, how are resources added to a client-ordered collection > when the Position header is missing? Must servers add them to the end of > the ordering or can they be put at the beginning or anywhere? At the end. See: > > > I assume that sub-collections are orderable as well? That is, if I have > > > an ordered collection containing several sub-collections, I assume I can > > > define an ordering that includes all sub-collections along with all > > > > Nope. Ordering is a property of the internal (!) members of a collection, so > > it doesn't automatically affect child collections: > > Again I was unclear. I meant direct sub-collections, or collections > which are direct children of the ordered collection. These are ordered > together with regular child resources, correct? There are no examples > of this but I believe this is what the spec says. Sure. Collections are resources. If a collection appears as a direct member of an ordered collection, it behaves (ordering-wise) just like a plain resource. > > > Other questions > > > - If I MOVE a resource within the same collection, must the server > > > preserve its ordering position wrt other resources? > > > > That depends on the Position header: > > What happens if the Position header is not present? Must servers > preserve the ordering or lose it? It must order it at the end. See above. > > > - If I COPY a resource within the same collection, where is the new > > > resource placed in the ordering -- next to the old resource (closely > > > preserving its ordering semantics), or at the end, or arbitrary? > > And here, what happens if the COPY method has no Position header? See above. > > - If I MOVE or COPY a resource into a collection, overwriting a > > resource that has an ordering position, is that ordering position (of > > the destination) preserved? > > Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE the > > target. > > No, I disagree with this. Overwriting a regular resource does not reset > all the live properties. For example, it would be pretty disastrous for > the ACL property to be reset every time a resource is overwritten. If you do that using a MOVE? I *really strongly* disagree. ACLs are properties of a resource, not of it's binding/URL. MOVEing a resource MUST move it's ACL with it, overwriting the target resource's ACLs. Please take this to the ACL list if you feel this needs to be discussed. > Besides, the ordering is a property of the parent, not the resource > being overwritten. I would expect that ordering would be preserved, but > the spec ought to say one way or another. It says: "If the request is replacing an existing resource, the server MUST preserve the present ordering. If the request is adding a new internal member URI to the collection, the server MUST append the new member to the end of the ordering." So the ordering spec basically delegates the decision to the server implementor (it depends how overwrite operations are implemented internally) -- I'm not sure we can be more precise here because it might be impossible or very expensive to implement in some cases. > > > - If I DELETE a resource, must the server preserve the ordering other > > > than that deleted resource? Section 4 could be more explicit that if > > > resource C is after B is after A, then the deletion of B means that C > > > must be after A rather than destroying the ordering relationship. This > > > is worth making explicit because server implementors must either > > > maintain their orderings in a format that is irrelevant to what > > > resources exist (absolute), or relative orderings must be fixed up when > > > a resource is deleted. > > > I think this follows from the definition of "ordering" (repeatability of > > PROPFIND result element ordering). > > Then why not make it explicit in the specification? I think it *is* explicit (by definition). > > > Note that the answers to the MOVE/COPY questions are particularly > > > important if WebDAV clients do "Safe-save" operations -- e.g. a client > > > that PUTs an new resource then uses COPY to overwrite the existing > > > resource after finding that the PUT worked. There are many other > > > variations in safe-save algorithms, some using MOVE. > > > Those servers will need to set the Position header accordingly if they want > > the resulting resource to be in the "original" position. > > It is not the servers doing "safe save" operation, it's the clients, and > these may be clients that are unaware of ordering or choose not to set > the Position header. Correct. This means that these clients will lose the original order position. > It's important to consider how a server with an ordered collection > interacts with ordinary clients (ones that do not use the Position > header). Otherwise, an author that tries to keep their collection > ordered may frequently find the ordering unecessarily "messed up" after > resources are added, deleted, renamed, or overwritten by non-ordering > client software (e.g. Office). I agree that this is the case, but it's unclear how we can prevent this. A server usually doesn't have the required context to decide what the intent of a sequence of operations is. Note that Office isn't an issue here because it indeed edits (LOCK/GET/PUT/UNLOCK) a single URL. Also note that a similar problem exists with RFC3253-style autoversioning. The best way to avoid these issues is to use a client which behaves properly (by consistently using the same URL). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 14:36:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00200 for ; Mon, 7 Apr 2003 14:36:00 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37Ic8Z4018130; Mon, 7 Apr 2003 14:38:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37Ic790018111; Mon, 7 Apr 2003 14:38:07 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 14:38:07 -0400 (EDT) Resent-Message-Id: <200304071838.h37Ic790018111@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37Ic5Z4018078 for ; Mon, 7 Apr 2003 14:38:05 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h37Ic5si030058 for ; Mon, 7 Apr 2003 14:38:05 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h37Ibuks005676; Mon, 7 Apr 2003 11:37:56 -0700 (PDT) Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h37IbrLq027453; Mon, 7 Apr 2003 11:37:54 -0700 (PDT) Date: Mon, 7 Apr 2003 11:37:58 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Lisa Dusseault" , "'Webdav WG'" To: "Julian Reschke" From: Ted Hardie In-Reply-To: Message-Id: <0DB49A77-6928-11D7-A412-000393CB0816@qualcomm.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: More on ordered collections X-Archived-At: http://www.w3.org/mid/0DB49A77-6928-11D7-A412-000393CB0816@qualcomm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7563 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: Content-Transfer-Encoding: 7bit Process question: what is the ACL list, and why is conversation on a decision to be made by the working group moving to it? If this is a design team, pleae note the IESG's statement on the work of design teams at: http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt Thanks for filling me in, regards, Ted Hardie > >>> - If I MOVE or COPY a resource into a collection, overwriting a >>> resource that has an ordering position, is that ordering position (of >>> the destination) preserved? >>> Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE >>> the >>> target. >> >> No, I disagree with this. Overwriting a regular resource does not >> reset >> all the live properties. For example, it would be pretty disastrous >> for >> the ACL property to be reset every time a resource is overwritten. > > If you do that using a MOVE? I *really strongly* disagree. ACLs are > properties of a resource, not of it's binding/URL. MOVEing a resource > MUST > move it's ACL with it, overwriting the target resource's ACLs. Please > take > this to the ACL list if you feel this needs to be discussed. From w3c-dist-auth-request@w3.org Mon Apr 7 14:46:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00513 for ; Mon, 7 Apr 2003 14:46:11 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IlnZ4026764; Mon, 7 Apr 2003 14:47:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37IlKO2026623; Mon, 7 Apr 2003 14:47:20 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 14:47:20 -0400 (EDT) Resent-Message-Id: <200304071847.h37IlKO2026623@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IlFZ4026519 for ; Mon, 7 Apr 2003 14:47:15 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37IlEsi000850 for ; Mon, 7 Apr 2003 14:47:15 -0400 Received: (qmail 22854 invoked by uid 65534); 7 Apr 2003 18:47:08 -0000 Received: from pD950C3B8.dip.t-dialin.net (HELO lisa) (217.80.195.184) by mail.gmx.net (mp022-rz3) with SMTP; 07 Apr 2003 20:47:08 +0200 From: "Julian Reschke" To: "Ted Hardie" , "Julian Reschke" Cc: "Lisa Dusseault" , "'Webdav WG'" Date: Mon, 7 Apr 2003 20:47:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <0DB49A77-6928-11D7-A412-000393CB0816@qualcomm.com> Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEJOGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7564 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ted Hardie > Sent: Monday, April 07, 2003 8:38 PM > To: Julian Reschke > Cc: Lisa Dusseault; 'Webdav WG' > Subject: Re: More on ordered collections > > > > Process question: what is the ACL list, and why is conversation See info at: > on a decision to be made by the working group moving to it? > If this is a design team, pleae note the IESG's statement > on the work of design teams at: > > http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > > Thanks for filling me in, I was suggesting to take the question to the ACL mailing list, because it affects mainly the WebDAV ACL spec, not the ordering spec (which is discussed here on the "generic" WebDAV mailing list) -- the WebDAV ACL mailing list simply is a better place to resolve open issues regarding the behaviour of ACLs upon COPY/MOVE. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 14:50:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00619 for ; Mon, 7 Apr 2003 14:50:57 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IqpZ4028422; Mon, 7 Apr 2003 14:52:51 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37IqUtR028106; Mon, 7 Apr 2003 14:52:30 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 14:52:30 -0400 (EDT) Resent-Message-Id: <200304071852.h37IqUtR028106@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37IqSZ4028023 for ; Mon, 7 Apr 2003 14:52:28 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h37IqRsi002239 for ; Mon, 7 Apr 2003 14:52:27 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 192bjB-00041I-00; Mon, 07 Apr 2003 18:52:21 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 192bjA-000417-00; Mon, 07 Apr 2003 18:52:20 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 7 Apr 2003 11:52:20 -0700 Message-ID: <002801c2fd36$d1ade110$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/002801c2fd36$d1ade110$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7565 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: Content-Transfer-Encoding: 7bit OK, this answers a lot of my questions. > > > > - If I MOVE a resource within the same collection, > must the server > > > > preserve its ordering position wrt other resources? > > > > > > That depends on the Position header: > > > > What happens if the Position header is not present? Must servers > > preserve the ordering or lose it? > > It must order it at the end. See above. I think this is the wrong behavior. A MOVE within a collection is simply a rename. A server ought at least to be able to preserve the ordering if Office/Web Folders does a rename. Otherwise this unnecessarily disturbs the author's ordering. If we don't say "a server MUST retain the relative position of a member when it is moved within the same ordered collection without an explicit Position header", then it should at least be a SHOULD. > > > - If I MOVE or COPY a resource into a collection, overwriting a > > > resource that has an ordering position, is that ordering > position (of > > > the destination) preserved? > > > Usually not, as RFC2518 defines an Overwrite to be > implicitly DELETE the > > > target. > > > > No, I disagree with this. Overwriting a regular resource > does not reset > > all the live properties. For example, it would be pretty > disastrous for > > the ACL property to be reset every time a resource is overwritten. > > If you do that using a MOVE? I *really strongly* disagree. ACLs are > properties of a resource, not of it's binding/URL. MOVEing a > resource MUST > move it's ACL with it, overwriting the target resource's > ACLs. Please take > this to the ACL list if you feel this needs to be discussed. ACL isn't the issue -- it was just an illustration. If you COPY some content into an ordered collection, overwriting an existing resource, what is the right thing to do? I think the right thing to do is to preserve the target resource's position. Suggested language: "When COPY is used to overwrite a member of an ordered collection without an explicit Position header, the server MUST maintain the original members position, just as when PUT is used." If you MOVE some content this is a little more difficult. Perhaps you could say "When a resource is moved from outside the ordered collection into the ordered collection and overwriting a pre-existing member (without an explicit Position header), the server SHOULD preserve the pre-existing member's position. When a resource is moved within the ordered collection and overwites another internal member (without an explicit Position header) the server MAY preserve either the source or the destination's position but MUST NOT arbitrarily reorder the moved resource to the end of the order." > > > > - If I DELETE a resource, must the server preserve the > ordering other > > > > than that deleted resource? Section 4 could be more > explicit that if > > > > resource C is after B is after A, then the deletion of > B means that C > > > > must be after A rather than destroying the ordering > relationship. This > > > > is worth making explicit because server implementors must either > > > > maintain their orderings in a format that is irrelevant to what > > > > resources exist (absolute), or relative orderings must > be fixed up > when > > > > a resource is deleted. > > > > > I think this follows from the definition of "ordering" > (repeatability of > > > PROPFIND result element ordering). > > > > Then why not make it explicit in the specification? > > I think it *is* explicit (by definition). Sorry, how can this possibly be explicit in the definition of the PROPFIND response? Unless the spec is clear, what's to stop the server from arbitrarily reordering the collection (losing some or all of the ordering information) when a resource is deleted? After all, any other write operation in an ordered collection may change the ordering, so the definition which mentions the PROPFIND response obviously is dependent on the behavior of write operations in between. Lisa > > > > > Note that the answers to the MOVE/COPY questions are > particularly > > > > important if WebDAV clients do "Safe-save" operations > -- e.g. a client > > > > that PUTs an new resource then uses COPY to overwrite > the existing > > > > resource after finding that the PUT worked. There are > many other > > > > variations in safe-save algorithms, some using MOVE. > > > > > Those servers will need to set the Position header > accordingly if they > want > > > the resulting resource to be in the "original" position. > > > > It is not the servers doing "safe save" operation, it's the > clients, and > > these may be clients that are unaware of ordering or choose > not to set > > the Position header. > > Correct. This means that these clients will lose the original order > position. > > > It's important to consider how a server with an ordered collection > > interacts with ordinary clients (ones that do not use the Position > > header). Otherwise, an author that tries to keep their collection > > ordered may frequently find the ordering unecessarily > "messed up" after > > resources are added, deleted, renamed, or overwritten by > non-ordering > > client software (e.g. Office). > > I agree that this is the case, but it's unclear how we can > prevent this. A > server usually doesn't have the required context to decide > what the intent > of a sequence of operations is. > > Note that Office isn't an issue here because it indeed edits > (LOCK/GET/PUT/UNLOCK) a single URL. Also note that a similar > problem exists > with RFC3253-style autoversioning. The best way to avoid > these issues is to > use a client which behaves properly (by consistently using > the same URL). > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Mon Apr 7 15:25:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03000 for ; Mon, 7 Apr 2003 15:25:25 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37JRVZ4006513; Mon, 7 Apr 2003 15:27:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37JRR9N006489; Mon, 7 Apr 2003 15:27:27 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 15:27:27 -0400 (EDT) Resent-Message-Id: <200304071927.h37JRR9N006489@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37JRQZ4006455 for ; Mon, 7 Apr 2003 15:27:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37JRPsi011432 for ; Mon, 7 Apr 2003 15:27:25 -0400 Received: (qmail 21715 invoked by uid 65534); 7 Apr 2003 19:27:19 -0000 Received: from pD950C3B8.dip.t-dialin.net (HELO lisa) (217.80.195.184) by mail.gmx.net (mp017-rz3) with SMTP; 07 Apr 2003 21:27:19 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 7 Apr 2003 21:27:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <002801c2fd36$d1ade110$f8cb90c6@xythoslap> Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEKBGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7566 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: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Monday, April 07, 2003 8:52 PM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: More on ordered collections > > > OK, this answers a lot of my questions. > > > > > > > - If I MOVE a resource within the same collection, must the server > > > > > preserve its ordering position wrt other resources? > > > > > > > > That depends on the Position header: > > > > > > What happens if the Position header is not present? Must servers > > > preserve the ordering or lose it? > > > > It must order it at the end. See above. OK, you got me there :-) The default of "end-of-ordering" in the absence of the Position header is specified for the case where a new collection member is *added*. A MOVE can be seen both as 1) removing a binding and adding a new binding or 2) renaming a binding. Depending on which point of view you take, you are or you aren't adding a new collection member. The ordering spec currently is silent on how a collection-internal MOVE needs to work, and I'm not sure that it would be a good idea to get into the business of defining this > I think this is the wrong behavior. A MOVE within a collection is > simply a rename. A server ought at least to be able to preserve the I disagree here -- a MOVE within a collection *can* be implemented as a simple rename, but no spec currently forces servers to behave that way. RFC2518 defines COPY/DELETE semantics, the binding spec (I think) sees it as BIND/UNBIND. > ordering if Office/Web Folders does a rename. Otherwise this > unnecessarily disturbs the author's ordering. If we don't say "a server > MUST retain the relative position of a member when it is moved within > the same ordered collection without an explicit Position header", then > it should at least be a SHOULD. This would definitively be useful for the average client. Does anybody have a problem with making this a SHOULD? > > > No, I disagree with this. Overwriting a regular resource does not reset > > > all the live properties. For example, it would be pretty disastrous for > > > the ACL property to be reset every time a resource is overwritten. > > > > If you do that using a MOVE? I *really strongly* disagree. ACLs are > > properties of a resource, not of it's binding/URL. MOVEing a resource MUST > > move it's ACL with it, overwriting the target resource's ACLs. Please take > > this to the ACL list if you feel this needs to be discussed. > > ACL isn't the issue -- it was just an illustration. It was a *good* illustration. This is a very important issue where I think you are wrong (because the ACL spec clearly says that MOVEing a resource must preserve it's access rights). You really should raise this on the ACL list. > If you COPY some content into an ordered collection, overwriting an > existing resource, what is the right thing to do? I think the right > thing to do is to preserve the target resource's position. Suggested > language: > > "When COPY is used to overwrite a member of an ordered collection > without an explicit Position header, the server MUST maintain the > original members position, just as when PUT is used." It depends on the same question as above: is a new collection member added or not? I don't think the ordering spec should get into the business of defining this (RFC2518bis possibly should). > If you MOVE some content this is a little more difficult. Perhaps you > could say "When a resource is moved from outside the ordered collection > into the ordered collection and overwriting a pre-existing member > (without an explicit Position header), the server SHOULD preserve the > pre-existing member's position. When a resource is moved within the > ordered collection and overwites another internal member (without an > explicit Position header) the server MAY preserve either the source or > the destination's position but MUST NOT arbitrarily reorder the moved > resource to the end of the order." Again, the ordering spec defines the behaviour based on the condition of whether new internal members are added or not. I think it's consistent in this regard. Mandating a specific behaviour here won't fly -- if we really want to make this consistent between specific implementations, we should try to clarify this in RFC2518bis (the behaviour for ordered collections will then follow automatically). > > > > > - If I DELETE a resource, must the server preserve the ordering other > > > > > than that deleted resource? Section 4 could be more explicit that if > > > > > resource C is after B is after A, then the deletion of B means that C > > > > > must be after A rather than destroying the ordering relationship. This > > > > > is worth making explicit because server implementors must either > > > > > maintain their orderings in a format that is irrelevant to what > > > > > resources exist (absolute), or relative orderings must be fixed up when > > > > > a resource is deleted. > > > > > > > I think this follows from the definition of "ordering" (repeatability of > > > > PROPFIND result element ordering). > > > > > > Then why not make it explicit in the specification? > > > > I think it *is* explicit (by definition). > > Sorry, how can this possibly be explicit in the definition of the > PROPFIND response? Unless the spec is clear, what's to stop the server > from arbitrarily reordering the collection (losing some or all of the > ordering information) when a resource is deleted? After all, any other It follows from the definition of ordering. Removing an element from a fully ordered set doesn't affect the ordering of the remaining elements. If "a" was "before" "c" before the DELETE of "b", it still will be before it after the operation. > write operation in an ordered collection may change the ordering, so the > definition which mentions the PROPFIND response obviously is dependent > on the behavior of write operations in between. No, that is not the case. No write operation will have side-effects to the ordering of existing members. A newly added member is simply inserted at a specific position in the ordering, but the ordering of the previously present elements will still be the same. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 18:19:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08985 for ; Mon, 7 Apr 2003 18:19:59 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37MJaZ4000470; Mon, 7 Apr 2003 18:19:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37MJG2K000444; Mon, 7 Apr 2003 18:19:16 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 18:19:16 -0400 (EDT) Resent-Message-Id: <200304072219.h37MJG2K000444@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37MJFZ4000411 for ; Mon, 7 Apr 2003 18:19:15 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h37MJFsi004810 for ; Mon, 7 Apr 2003 18:19:15 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Apr 2003 18:01:53 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Apr 2003 18:19:09 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Apr 2003 18:19:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED75E@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7567 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: One thing that I would suggest is to never try to define semantics for both COPY and MOVE at the same time (they have radically different semantics, in spite of what 2518 incorrectly implies, as acknowledged by the authors of 2518 :-). In particular, in the following discussion, what Lisa says is true for COPY while what Julian says is true for MOVE. In particular: > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > If I MOVE or COPY a resource into a collection, overwriting > > a resource that has an ordering position, is that ordering > > position (of the destination) preserved? Usually not, as > > RFC2518 defines an Overwrite to be implicitly DELETE the > > target. I believe that we have consensus that 2518 is wrong here (this is explicitly pointed out in 3253) and that Overwrite is only a DELETE for MOVE, not for COPY. > From: Lisa Dusseault > > No, I disagree with this. Overwriting a regular resource does > not reset all the live properties. For example, it would be > pretty disastrous for the ACL property to be reset every time a > resource is overwritten. Here Lisa is talking about COPY behavior. From: Julian Reschke [mailto:julian.reschke@gmx.de] If you do that using a MOVE? I *really strongly* disagree. ACLs are properties of a resource, not of it's binding/URL. MOVEing a resource MUST move it's ACL with it, overwriting the target resource's ACLs. And here Julian is responding with MOVE behavior. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Apr 7 18:50:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09779 for ; Mon, 7 Apr 2003 18:50:39 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37MqmZ4006598; Mon, 7 Apr 2003 18:52:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h37Mqk9R006577; Mon, 7 Apr 2003 18:52:46 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 18:52:46 -0400 (EDT) Resent-Message-Id: <200304072252.h37Mqk9R006577@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h37MqjZ4006524 for ; Mon, 7 Apr 2003 18:52:45 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h37Mqisi011585 for ; Mon, 7 Apr 2003 18:52:44 -0400 Received: (qmail 809 invoked by uid 65534); 7 Apr 2003 22:52:38 -0000 Received: from p3EE24771.dip.t-dialin.net (HELO lisa) (62.226.71.113) by mail.gmx.net (mp011-rz3) with SMTP; 08 Apr 2003 00:52:38 +0200 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Tue, 8 Apr 2003 00:52:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEKKGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7568 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, April 08, 2003 12:19 AM > To: 'Webdav WG' > Subject: RE: More on ordered collections > > > > One thing that I would suggest is to never try to define semantics for > both COPY and MOVE at the same time (they have radically different > semantics, in spite of what 2518 incorrectly implies, as acknowledged > by the authors of 2518 :-). In particular, in the following > discussion, what Lisa says is true for COPY while what Julian says is > true for MOVE. In particular: > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > > If I MOVE or COPY a resource into a collection, overwriting > > > a resource that has an ordering position, is that ordering > > > position (of the destination) preserved? Usually not, as > > > RFC2518 defines an Overwrite to be implicitly DELETE the > > > target. That's why I wrote *usually* here. > I believe that we have consensus that 2518 is wrong here > (this is explicitly pointed out in 3253) and that Overwrite is > only a DELETE for MOVE, not for COPY. That would be good. Do we? Anyway, this should be clarified in RFC2518bis. > > From: Lisa Dusseault > > > > No, I disagree with this. Overwriting a regular resource does > > not reset all the live properties. For example, it would be > > pretty disastrous for the ACL property to be reset every time a > > resource is overwritten. > > Here Lisa is talking about COPY behavior. > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > If you do that using a MOVE? I *really strongly* disagree. ACLs are > properties of a resource, not of it's binding/URL. MOVEing a > resource MUST move it's ACL with it, overwriting the target > resource's ACLs. > > And here Julian is responding with MOVE behavior. That *may* be the source for the confusion. However I've got the impression that Lisa would like servers to better support the following request chain ("safe delete"): GET A PUT A.bak MOVE A.bak -> A or similarily GET A MOVE A -> A.bak PUT A DELETE A.bak Under this scenario, a resource would usually lose it's ordering position. However, it would also lose it's version history and it's ACL, so I fail to see why this would be a specific problem with the ordering spec. However, if the client would issue these requests: GET A PUT A.bak COPY A.bak A DELETE A.bak and the server conforms to the RFC3253 COPY semantics, there wouldn't be any problem with ordering, ACLs or version history (the ordering spec just "inherits" from the server's view of what COPY/Overwrite means). So if at the end of the day we agree that COPY should always have RFC3253 sematics, I'm all for it :-) I just didn't want the ordering spec to require a specific model. Julian P.S.: these "safe delete" scenarios obviously can become problematic if the client doesn't properly handle dead properties. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Apr 7 20:27:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11818 for ; Mon, 7 Apr 2003 20:27:28 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h380TTZ4004099; Mon, 7 Apr 2003 20:29:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h380TLMd004070; Mon, 7 Apr 2003 20:29:21 -0400 (EDT) Resent-Date: Mon, 7 Apr 2003 20:29:21 -0400 (EDT) Resent-Message-Id: <200304080029.h380TLMd004070@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h380TKZ4004038 for ; Mon, 7 Apr 2003 20:29:20 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h380TJsi032143 for ; Mon, 7 Apr 2003 20:29:20 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 192gzG-0000rz-00; Tue, 08 Apr 2003 00:29:18 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 192gzG-0000rn-00; Tue, 08 Apr 2003 00:29:18 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Mon, 7 Apr 2003 17:29:17 -0700 Message-ID: <006101c2fd65$e3f03650$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/006101c2fd65$e3f03650$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7569 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: Content-Transfer-Encoding: 7bit I agree there's little we can do about the safe-save algorithms that use MOVE, sadly. In fact, the correctest behavior for MOVE is probably, as with version histories, to retain the source resource's ordering position if a destination is overwritten. However, if a destination is not being overwritten, then shouldn't the MOVE (the rename) preserve ordering? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Monday, April 07, 2003 3:53 PM > To: Clemm, Geoff; 'Webdav WG' > Subject: RE: More on ordered collections > > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Tuesday, April 08, 2003 12:19 AM > > To: 'Webdav WG' > > Subject: RE: More on ordered collections > > > > > > > > One thing that I would suggest is to never try to define > semantics for > > both COPY and MOVE at the same time (they have radically different > > semantics, in spite of what 2518 incorrectly implies, as > acknowledged > > by the authors of 2518 :-). In particular, in the following > > discussion, what Lisa says is true for COPY while what > Julian says is > > true for MOVE. In particular: > > > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > > > > If I MOVE or COPY a resource into a collection, overwriting > > > > a resource that has an ordering position, is that ordering > > > > position (of the destination) preserved? Usually not, as > > > > RFC2518 defines an Overwrite to be implicitly DELETE the > > > > target. > > That's why I wrote *usually* here. > > > I believe that we have consensus that 2518 is wrong here > > (this is explicitly pointed out in 3253) and that Overwrite is > > only a DELETE for MOVE, not for COPY. > > That would be good. Do we? Anyway, this should be clarified > in RFC2518bis. > > > > From: Lisa Dusseault > > > > > > No, I disagree with this. Overwriting a regular resource does > > > not reset all the live properties. For example, it would be > > > pretty disastrous for the ACL property to be reset every time a > > > resource is overwritten. > > > > Here Lisa is talking about COPY behavior. > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > If you do that using a MOVE? I *really strongly* > disagree. ACLs are > > properties of a resource, not of it's binding/URL. MOVEing a > > resource MUST move it's ACL with it, overwriting the target > > resource's ACLs. > > > > And here Julian is responding with MOVE behavior. > > That *may* be the source for the confusion. > > However I've got the impression that Lisa would like servers to better > support the following request chain ("safe delete"): > > GET A > PUT A.bak > MOVE A.bak -> A > > or similarily > > GET A > MOVE A -> A.bak > PUT A > DELETE A.bak > > Under this scenario, a resource would usually lose it's > ordering position. > However, it would also lose it's version history and it's > ACL, so I fail to > see why this would be a specific problem with the ordering spec. > > However, if the client would issue these requests: > > GET A > PUT A.bak > COPY A.bak A > DELETE A.bak > > and the server conforms to the RFC3253 COPY semantics, there > wouldn't be any > problem with ordering, ACLs or version history (the ordering spec just > "inherits" from the server's view of what COPY/Overwrite means). > > So if at the end of the day we agree that COPY should always > have RFC3253 > sematics, I'm all for it :-) I just didn't want the ordering > spec to require > a specific model. > > > Julian > > > P.S.: these "safe delete" scenarios obviously can become > problematic if the > client doesn't properly handle dead properties. > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Tue Apr 8 03:07:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01064 for ; Tue, 8 Apr 2003 03:07:47 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h38779Z4012509; Tue, 8 Apr 2003 03:07:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3875wnM012411; Tue, 8 Apr 2003 03:05:58 -0400 (EDT) Resent-Date: Tue, 8 Apr 2003 03:05:58 -0400 (EDT) Resent-Message-Id: <200304080705.h3875wnM012411@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h3875uZ4012379 for ; Tue, 8 Apr 2003 03:05:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3875tsi008094 for ; Tue, 8 Apr 2003 03:05:55 -0400 Received: (qmail 19443 invoked by uid 65534); 8 Apr 2003 07:05:49 -0000 Received: from p3EE24771.dip.t-dialin.net (HELO lisa) (62.226.71.113) by mail.gmx.net (mp006-rz3) with SMTP; 08 Apr 2003 09:05:49 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Tue, 8 Apr 2003 09:05:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <006101c2fd65$e3f03650$f8cb90c6@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOELAGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7570 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, April 08, 2003 2:29 AM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: More on ordered collections > > > > I agree there's little we can do about the safe-save algorithms that use > MOVE, sadly. In fact, the correctest behavior for MOVE is probably, as > with version histories, to retain the source resource's ordering > position if a destination is overwritten. > > However, if a destination is not being overwritten, then shouldn't the > MOVE (the rename) preserve ordering? From a client's point of view: almost certainly. The spec currently lets this depend on whether the server implements this as a single rename or a bind/unbind (in which a new binding is created and the previous is removed). Before I add some language about this, I'd like to get some more additional opinions. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Apr 8 13:27:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23011 for ; Tue, 8 Apr 2003 13:27:48 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h38HTFZ4026561; Tue, 8 Apr 2003 13:29:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h38HSgtI026495; Tue, 8 Apr 2003 13:28:42 -0400 (EDT) Resent-Date: Tue, 8 Apr 2003 13:28:42 -0400 (EDT) Resent-Message-Id: <200304081728.h38HSgtI026495@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h38HSfZ4026463 for ; Tue, 8 Apr 2003 13:28:41 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h38HSesi015298 for ; Tue, 8 Apr 2003 13:28:40 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h38HJZi09770; Tue, 8 Apr 2003 10:19:36 -0700 (PDT) From: "Jim Whitehead" To: "Ted Hardie" , "WebDAV" Date: Tue, 8 Apr 2003 10:16:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0DB49A77-6928-11D7-A412-000393CB0816@qualcomm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGENMGOAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7571 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: Content-Transfer-Encoding: 7bit The ACL list can be loosely viewed as a design team. I say loosely, since design teams are normally small and closed, and this list is open and free for all to subscribe. It emerged as a way to prevent the main DAV list from being occasionally swamped by ACL discussion. Operationally, actively working members of the DAV WG are subscribed to both the main DAV list and the ACL list, and so the ACL list serves as a convenient partitioning and filtering mechanism for ACL discussions. Of course, all drafts discussed on the ACL list are brought to the main DAV list for WG last call, and for official decisions on consensus. See for example: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0313.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0088.html - Jim > Process question: what is the ACL list, and why is conversation > on a decision to be made by the working group moving to it? > If this is a design team, pleae note the IESG's statement > on the work of design teams at: > > http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt > > Thanks for filling me in, > regards, > Ted Hardie From w3c-dist-auth-request@w3.org Wed Apr 9 13:07:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06524 for ; Wed, 9 Apr 2003 13:07:08 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h39H8xZ4002843; Wed, 9 Apr 2003 13:08:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h39H8jwr002767; Wed, 9 Apr 2003 13:08:45 -0400 (EDT) Resent-Date: Wed, 9 Apr 2003 13:08:45 -0400 (EDT) Resent-Message-Id: <200304091708.h39H8jwr002767@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h39H8hZ4002611 for ; Wed, 9 Apr 2003 13:08:43 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h39H8hsi015926 for ; Wed, 9 Apr 2003 13:08:43 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 193J3y-0005hd-00; Wed, 09 Apr 2003 17:08:42 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 193J3x-0005hL-00; Wed, 09 Apr 2003 17:08:41 +0000 From: "Lisa Dusseault" To: "Webdav WG" , "DeltaV" Date: Wed, 9 Apr 2003 10:08:36 -0700 Message-ID: <023801c2feba$ab768a80$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Low X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Subject: New client supporting DeltaV... X-Archived-At: http://www.w3.org/mid/023801c2feba$ab768a80$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7572 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: Content-Transfer-Encoding: 7bit Stumbled across this recent press release: "To meet the needs of enterprise developers, XMLSPY 5 builds on the success of previous award winning versions through the addition of several key new features: Enhanced WebDAV Support -- Web-based Distributed Authoring and Versioning (WebDAV) is a standardized set of extensions to the HTTP (web) protocol, which allows users to collaboratively edit and manage XML files located on remote web-servers. XMLSPY 5 and AUTHENTIC 5 now support Delta-V (http://www.webdav.org/deltav/), an extension to the WebDAV protocol which enables check-in/check-out functionality when used in conjunction with a WebDAV server, thus supporting XML content editing in a truly collaborative, distributed environment, such as the Web." http://biz.yahoo.com/prnews/030407/nem030_1.html From w3c-dist-auth-request@w3.org Wed Apr 9 14:22:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08541 for ; Wed, 9 Apr 2003 14:22:29 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h39IOOZ4022046; Wed, 9 Apr 2003 14:24:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h39IOAQl021741; Wed, 9 Apr 2003 14:24:10 -0400 (EDT) Resent-Date: Wed, 9 Apr 2003 14:24:10 -0400 (EDT) Resent-Message-Id: <200304091824.h39IOAQl021741@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h39IO7Z4021652 for ; Wed, 9 Apr 2003 14:24:08 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h39IO6si010224 for ; Wed, 9 Apr 2003 14:24:07 -0400 Received: (qmail 32659 invoked by uid 65534); 9 Apr 2003 18:24:00 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 09 Apr 2003 20:24:00 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" , "DeltaV" Date: Wed, 9 Apr 2003 20:24:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <023801c2feba$ab768a80$f8cb90c6@xythoslap> Importance: Normal Subject: RE: New client supporting DeltaV... X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEONGPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7573 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, April 09, 2003 7:09 PM > To: Webdav WG; DeltaV > Subject: New client supporting DeltaV... > Importance: Low > > > > > Stumbled across this recent press release: > > "To meet the needs of enterprise developers, XMLSPY 5 builds on the > success of previous award winning versions through the addition of > several key new features: > > Enhanced WebDAV Support -- Web-based Distributed Authoring and > Versioning (WebDAV) is a standardized set of extensions to the HTTP > (web) protocol, which allows users to collaboratively edit and manage > XML files located on remote web-servers. XMLSPY 5 and AUTHENTIC 5 now > support Delta-V (http://www.webdav.org/deltav/), an extension to the > WebDAV protocol which enables check-in/check-out functionality when used > in conjunction with a WebDAV server, thus supporting XML content editing > in a truly collaborative, distributed environment, such as the Web." > > > http://biz.yahoo.com/prnews/030407/nem030_1.html Interesting. A trace reveals that it does indeed PROPFIND some DeltaV properties, but it's unclear what it does with them. After switching off autoversioning on our server, I wasn't able to PUT resources anymore. No Checkin/Checkout menu item in sight. Did anybody else have more success? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Apr 12 16:23:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04222 for ; Sat, 12 Apr 2003 16:23:45 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h3CKPgZ4013593; Sat, 12 Apr 2003 16:25:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3CKPJXk013493; Sat, 12 Apr 2003 16:25:19 -0400 (EDT) Resent-Date: Sat, 12 Apr 2003 16:25:19 -0400 (EDT) Resent-Message-Id: <200304122025.h3CKPJXk013493@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h3CKPIZ4013458 for ; Sat, 12 Apr 2003 16:25:18 -0400 (EDT) Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3CKPIsi011115 for ; Sat, 12 Apr 2003 16:25:18 -0400 Received: from x.oberon.ethz.ch (dialin-212-144-129-105.arcor-ip.net [212.144.129.105]) by post.webmailer.de (8.12.8/8.8.7) with SMTP id h3CKPEHb019581; Sat, 12 Apr 2003 22:25:15 +0200 (MEST) Date: Sat, 12 Apr 2003 22:25:14 +0200 (MEST) Message-Id: <200304122025.h3CKPEHb019581@post.webmailer.de> From: Edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 13.08.2002 To: w3c-dist-auth@w3c.org Cc: Edgar@edgarschwarz.de Subject: PROPPATCH only for complete value X-Archived-At: http://www.w3.org/mid/200304122025.h3CKPEHb019581@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7574 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: Hi, I recently had a look at PROPPATCH. It seems it only allows to set the complete value of a property. Is this correct ? For the subbaseline-set I would have liked to be able to add or remove a single subbaseline. Cheers, Edgar -- edgar@edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein From w3c-dist-auth-request@w3.org Sat Apr 12 22:11:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09723 for ; Sat, 12 Apr 2003 22:11:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h3D205Z4014156; Sat, 12 Apr 2003 22:00:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3D1xfVG014052; Sat, 12 Apr 2003 21:59:41 -0400 (EDT) Resent-Date: Sat, 12 Apr 2003 21:59:41 -0400 (EDT) Resent-Message-Id: <200304130159.h3D1xfVG014052@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.8) with ESMTP id h3D1xeZ4014020 for ; Sat, 12 Apr 2003 21:59:40 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3D1xdsi028432 for ; Sat, 12 Apr 2003 21:59:40 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 194WmQ-0006ZH-00; Sun, 13 Apr 2003 01:59:38 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 194WmQ-0006Z6-00; Sun, 13 Apr 2003 01:59:38 +0000 From: "Lisa Dusseault" To: , Date: Sat, 12 Apr 2003 18:59:38 -0700 Message-ID: <004101c30160$572cfc40$7501a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200304122025.h3CKPEHb019581@post.webmailer.de> Old-X-Envelope-To: Edgar@EdgarSchwarz.de, w3c-dist-auth@w3c.org Subject: RE: PROPPATCH only for complete value X-Archived-At: http://www.w3.org/mid/004101c30160$572cfc40$7501a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7575 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: Content-Transfer-Encoding: 7bit This is correct. To reliably set a value like this one with PROPPATCH, a client ought to LOCK the resource, PROPFIND the property, add or remove the single baseline, PROPPATCH and UNLOCK. Otherwise a change by another client might result in a mini "lost-update" problem. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of > Edgar@EdgarSchwarz.de > Sent: Saturday, April 12, 2003 1:25 PM > To: w3c-dist-auth@w3c.org > Cc: Edgar@EdgarSchwarz.de > Subject: PROPPATCH only for complete value > > > > Hi, > I recently had a look at PROPPATCH. It seems it only allows > to set the complete > value of a property. Is this correct ? > For the subbaseline-set I would have liked to be able to add > or remove a single > subbaseline. > > Cheers, Edgar > > > -- > edgar@edgarschwarz.de "http://www.edgarschwarz.de" > "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon > Make it as simple as possible, but not simpler. Albert Einstein > > From w3c-dist-auth-request@w3.org Wed Apr 16 16:25:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15676 for ; Wed, 16 Apr 2003 16:25:22 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3GKR5WM022476; Wed, 16 Apr 2003 16:27:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3GKQpri022435; Wed, 16 Apr 2003 16:26:51 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 16:26:51 -0400 (EDT) Resent-Message-Id: <200304162026.h3GKQpri022435@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3GKQoWM022403 for ; Wed, 16 Apr 2003 16:26:50 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3GKQnsi018323 for ; Wed, 16 Apr 2003 16:26:50 -0400 Received: (qmail 4888 invoked by uid 65534); 16 Apr 2003 20:26:43 -0000 Received: from p3EE2474A.dip.t-dialin.net (HELO lisa) (62.226.71.74) by mail.gmx.net (mp011-rz3) with SMTP; 16 Apr 2003 22:26:43 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Wed, 16 Apr 2003 22:26:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEPFHAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7576 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: Content-Transfer-Encoding: 7bit Trying to summarize the issues raised by Lisa: 1) Concerns that ordering information will be lost when clients not aware of ordering do "safe updates" (such as writing to a temp file, then moving it to the original file): I agree that this is less than optimal, but the very same issues exist with versioning (version history lost) or ACLs. Therefore I'd say that the ordering spec should not try to fix something that is inherently broken. The right way to fix this is to have clients that take advantage of WebDAV properly (for instance doing in-place editing using LOCKs). 2) More specific language about when ordering information is supposed to be preserved. Right now, the ordering spec is mainly silent on this issue -- it only defines specific behaviour for the case when new collection members are added. In particular, Lisa mentioned DELETE which should not affect the ordering of other members in the collection. I think this is obvious and doesn't need to specified separately, but I'm willing to add a few sentences if others feel this should be addressed (my point being: removing one member from an ordered set doesn't affect the ordering of the remaining members). 3) The spec currently avoids to completely specify about *when* a new collection member is added. Obviously this is the case for MKCOL and PUT/COPY [when not updating an existing resource] (as stated in section 6.1), but what about MOVE? I can imagine servers that implement MOVE as a sequence of LINK and UNLINK, in which case clearly a new binding is being created and an old one is destroyed. On the other hand, it would be useful for clients if they could rely on MOVE inside a collection (-> rename) not to change the ordering. So do we want to mandate a specific server behaviour (making it harder for server implementors), or leave it as it is (making it harder for clients)? Feedback appreciated. Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 16 17:55:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18188 for ; Wed, 16 Apr 2003 17:55:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3GLvkWM010957; Wed, 16 Apr 2003 17:57:46 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3GLvgqu010933; Wed, 16 Apr 2003 17:57:42 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 17:57:42 -0400 (EDT) Resent-Message-Id: <200304162157.h3GLvgqu010933@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3GLvfWM010901 for ; Wed, 16 Apr 2003 17:57:41 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3GLvfsi009150 for ; Wed, 16 Apr 2003 17:57:41 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 16 Apr 2003 17:40:01 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 16 Apr 2003 17:57:35 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 16 Apr 2003 17:57:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED774@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7577 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: I agree with (1). For (2), I agree that it is obvious, but I have nothing against adding a sentence or two to make the obvious explicit (:-). For (3), I don't think making a special case for "move within a collection" vs. "move outside of the collection" is worth optimizing, since it makes the spec more complicated and is likely to be enough of a problem to some servers to make it likely to not be followed anyway. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, April 16, 2003 4:27 PM To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG' Subject: RE: More on ordered collections Trying to summarize the issues raised by Lisa: 1) Concerns that ordering information will be lost when clients not aware of ordering do "safe updates" (such as writing to a temp file, then moving it to the original file): I agree that this is less than optimal, but the very same issues exist with versioning (version history lost) or ACLs. Therefore I'd say that the ordering spec should not try to fix something that is inherently broken. The right way to fix this is to have clients that take advantage of WebDAV properly (for instance doing in-place editing using LOCKs). 2) More specific language about when ordering information is supposed to be preserved. Right now, the ordering spec is mainly silent on this issue -- it only defines specific behaviour for the case when new collection members are added. In particular, Lisa mentioned DELETE which should not affect the ordering of other members in the collection. I think this is obvious and doesn't need to specified separately, but I'm willing to add a few sentences if others feel this should be addressed (my point being: removing one member from an ordered set doesn't affect the ordering of the remaining members). 3) The spec currently avoids to completely specify about *when* a new collection member is added. Obviously this is the case for MKCOL and PUT/COPY [when not updating an existing resource] (as stated in section 6.1), but what about MOVE? I can imagine servers that implement MOVE as a sequence of LINK and UNLINK, in which case clearly a new binding is being created and an old one is destroyed. On the other hand, it would be useful for clients if they could rely on MOVE inside a collection (-> rename) not to change the ordering. So do we want to mandate a specific server behaviour (making it harder for server implementors), or leave it as it is (making it harder for clients)? Feedback appreciated. Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Apr 17 12:08:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26821 for ; Thu, 17 Apr 2003 12:08:59 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3HGBDWM007788; Thu, 17 Apr 2003 12:11:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3HGB13f007735; Thu, 17 Apr 2003 12:11:01 -0400 (EDT) Resent-Date: Thu, 17 Apr 2003 12:11:01 -0400 (EDT) Resent-Message-Id: <200304171611.h3HGB13f007735@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3HGB0WM007700 for ; Thu, 17 Apr 2003 12:11:00 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3HGAwsi003514 for ; Thu, 17 Apr 2003 12:10:59 -0400 Received: (qmail 20598 invoked by uid 65534); 17 Apr 2003 16:10:53 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp022-rz3) with SMTP; 17 Apr 2003 18:10:53 +0200 From: "Julian Reschke" To: "'Webdav WG'" Date: Thu, 17 Apr 2003 18:10:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: More on ordered collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEBNHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7578 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: Content-Transfer-Encoding: 7bit OK...: 1) noted and closed. 2) noted and added a sentence clarifying that DELETE MUST NOT affect the ordering of the remaining members. 3) noted as open issue [1] -- suggest not to do anything about it unless more people speak up in favor of requiring a specific server behaviour. Regards, Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, April 16, 2003 11:58 PM > To: 'Webdav WG' > Subject: RE: More on ordered collections > > > > I agree with (1). > > For (2), I agree that it is obvious, but I have nothing against adding a > sentence or two to make the obvious explicit (:-). > > For (3), I don't think making a special case for "move within a > collection" > vs. "move outside of the collection" is worth optimizing, since > it makes the > spec more complicated and is likely to be enough of a problem to some > servers to make it likely to not be followed anyway. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, April 16, 2003 4:27 PM > To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: More on ordered collections > > > Trying to summarize the issues raised by Lisa: > > 1) Concerns that ordering information will be lost when clients > not aware of > ordering do "safe updates" (such as writing to a temp file, then moving it > to the original file): I agree that this is less than optimal, > but the very > same issues exist with versioning (version history lost) or ACLs. > Therefore > I'd say that the ordering spec should not try to fix something that is > inherently broken. The right way to fix this is to have clients that take > advantage of WebDAV properly (for instance doing in-place editing using > LOCKs). > > 2) More specific language about when ordering information is > supposed to be > preserved. Right now, the ordering spec is mainly silent on this > issue -- it > only defines specific behaviour for the case when new collection > members are > added. In particular, Lisa mentioned DELETE which should not affect the > ordering of other members in the collection. I think this is obvious and > doesn't need to specified separately, but I'm willing to add a > few sentences > if others feel this should be addressed (my point being: removing > one member > from an ordered set doesn't affect the ordering of the remaining members). > > 3) The spec currently avoids to completely specify about *when* a new > collection member is added. Obviously this is the case for MKCOL and > PUT/COPY [when not updating an existing resource] (as stated in section > 6.1), but what about MOVE? I can imagine servers that implement MOVE as a > sequence of LINK and UNLINK, in which case clearly a new binding is being > created and an old one is destroyed. On the other hand, it would be useful > for clients if they could rely on MOVE inside a collection (-> rename) not > to change the ordering. So do we want to mandate a specific > server behaviour > (making it harder for server implementors), or leave it as it is > (making it > harder for clients)? > > Feedback appreciated. > > Julian > > [1] > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Apr 19 03:17:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19829 for ; Sat, 19 Apr 2003 03:17:47 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3J7JhWM020049; Sat, 19 Apr 2003 03:19:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3J7JNFZ020019; Sat, 19 Apr 2003 03:19:23 -0400 (EDT) Resent-Date: Sat, 19 Apr 2003 03:19:23 -0400 (EDT) Resent-Message-Id: <200304190719.h3J7JNFZ020019@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3J7JKWM019952 for ; Sat, 19 Apr 2003 03:19:20 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3J7JJsi023210 for ; Sat, 19 Apr 2003 03:19:20 -0400 Received: from lisa ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Sat, 19 Apr 2003 09:18:38 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" , "DeltaV" Date: Sat, 19 Apr 2003 09:18:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <023801c2feba$ab768a80$f8cb90c6@xythoslap> Importance: Normal X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: New client supporting DeltaV... X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEFOHBAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7579 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: Content-Transfer-Encoding: 7bit > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, April 09, 2003 7:09 PM > To: Webdav WG; DeltaV > Subject: New client supporting DeltaV... > Importance: Low > > > > > Stumbled across this recent press release: > > "To meet the needs of enterprise developers, XMLSPY 5 builds on the > success of previous award winning versions through the addition of > several key new features: > > Enhanced WebDAV Support -- Web-based Distributed Authoring and > Versioning (WebDAV) is a standardized set of extensions to the HTTP > (web) protocol, which allows users to collaboratively edit and manage > XML files located on remote web-servers. XMLSPY 5 and AUTHENTIC 5 now > support Delta-V (http://www.webdav.org/deltav/), an extension to the > WebDAV protocol which enables check-in/check-out functionality when used > in conjunction with a WebDAV server, thus supporting XML content editing > in a truly collaborative, distributed environment, such as the Web." > > > http://biz.yahoo.com/prnews/030407/nem030_1.html OK, I finally got feedback from Altova. The Home Edition doesn't seem to do DeltaV, but the Enterprise Edition does. Once an external web folder is added to a project, version-controlled resources can be checked-in and checked-out. Checkin even prompts for DAV:comment (I think this is the first client doing this :-). I haven't managed to enable version-control using XML-Spy, though. Some more info is at: http://www.altova.com/manual/sourcecontrol.htm Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Apr 22 15:46:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23164 for ; Tue, 22 Apr 2003 15:46:24 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3MJmSWM013626; Tue, 22 Apr 2003 15:48:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3MJm0Vp013581; Tue, 22 Apr 2003 15:48:00 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 15:48:00 -0400 (EDT) Resent-Message-Id: <200304221948.h3MJm0Vp013581@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3MJlxWM013548 for ; Tue, 22 Apr 2003 15:47:59 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3MJlwsi015427 for ; Tue, 22 Apr 2003 15:47:58 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h3MJl0i22069 for ; Tue, 22 Apr 2003 12:47:00 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 22 Apr 2003 12:44:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIENBHBAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7580 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: Content-Transfer-Encoding: 7bit Just a brief reminder that we're in the final days of a working group last call for comments period on the WebDAV Ordered Collections protocol, draft-ietf-webdav-ordering-protocol-07. From the abstract of the -07 specification This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. This last call for comments period ends Sunday, April 27, 2003, at midnight, US Pacific time. The specification can be accessed at: Text (this is the normative version) http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-07.t xt HTML: http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. html XML: http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. xml Based on comments received so far, there will likely be another draft produced, but there will not be another WG last call period. I am currently anticipating that the -08 specification will be sent immediately to the IESG for approval. As a result, if you are planning on reviewing this specification, please do so immediately. - Jim From w3c-dist-auth-request@w3.org Tue Apr 22 16:21:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24739 for ; Tue, 22 Apr 2003 16:21:17 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3MKNWWM019231; Tue, 22 Apr 2003 16:23:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3MKNVHV019212; Tue, 22 Apr 2003 16:23:31 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 16:23:31 -0400 (EDT) Resent-Message-Id: <200304222023.h3MKNVHV019212@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3MKNTWM019180 for ; Tue, 22 Apr 2003 16:23:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3MKNTsi027072 for ; Tue, 22 Apr 2003 16:23:29 -0400 Received: (qmail 12960 invoked by uid 65534); 22 Apr 2003 20:23:22 -0000 Received: from p3EE2472F.dip.t-dialin.net (HELO lisa) (62.226.71.47) by mail.gmx.net (mp003-rz3) with SMTP; 22 Apr 2003 22:23:22 +0200 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Tue, 22 Apr 2003 22:23:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEMBHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7581 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: Content-Transfer-Encoding: 7bit Thans Jim, the current edits are this URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest. html There's currently one unresolved issue for which I am looking for feedback: http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest. html#rfc.issue.6.1-when-are-members-added In case that there's no additional feedback, the plan is to close it as "no change". Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 23 11:16:46 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22920 for ; Wed, 23 Apr 2003 11:16:46 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFJ3WM013664; Wed, 23 Apr 2003 11:19:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NFIUU3013639; Wed, 23 Apr 2003 11:18:30 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 11:18:30 -0400 (EDT) Resent-Message-Id: <200304231518.h3NFIUU3013639@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFITWM013603 for ; Wed, 23 Apr 2003 11:18:29 -0400 (EDT) Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3NFISsi025878 for ; Wed, 23 Apr 2003 11:18:28 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 23 Apr 2003 16:18:20 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id QAA18547; Wed, 23 Apr 2003 16:17:18 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id QAA29582; Wed, 23 Apr 2003 16:17:17 +0100 (BST) Message-ID: <3EA6AE7C.630FCE1A@cs.bris.ac.uk> Date: Wed, 23 Apr 2003 16:17:17 +0100 From: "B. Shadgar" Organization: Bristol University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jim Whitehead CC: WebDAV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/3EA6AE7C.630FCE1A@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7582 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: Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Just a brief reminder that we're in the final days of a working group last > call for comments period on the WebDAV Ordered Collections protocol, > draft-ietf-webdav-ordering-protocol-07. > > >From the abstract of the -07 specification > > This specification extends the WebDAV Distributed Authoring Protocol > to support server-side ordering of collection members. Of particular > interest are orderings that are not based on property values, and so > cannot be achieved using a search protocol's ordering option and > cannot be maintained automatically by the server. Protocol elements > are defined to let clients specify the position in the ordering of > each collection member, as well as the semantics governing the > ordering. > > This last call for comments period ends Sunday, April 27, 2003, at midnight, > US Pacific time. > > The specification can be accessed at: > > Text (this is the normative version) > http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-07.t > xt > > HTML: > http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. > html > > XML: > http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. > xml > > Based on comments received so far, there will likely be another draft > produced, but there will not be another WG last call period. I am currently > anticipating that the -08 specification will be sent immediately to the IESG > for approval. As a result, if you are planning on reviewing this > specification, please do so immediately. > > - Jim May I ask about practical example or cases about WebDAV Ordered Collections protocol. It is not clear to me why we define new protocol when we have the search protocol's ordering option. In other words, which aspects of ordering can not be covered by the search protocol's ordering option. Thanks in advance, Bita From w3c-dist-auth-request@w3.org Wed Apr 23 11:26:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23205 for ; Wed, 23 Apr 2003 11:26:42 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFStWM017726; Wed, 23 Apr 2003 11:28:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NFSsbG017709; Wed, 23 Apr 2003 11:28:54 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 11:28:54 -0400 (EDT) Resent-Message-Id: <200304231528.h3NFSsbG017709@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFSrWM017677 for ; Wed, 23 Apr 2003 11:28:53 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3NFSqsi029420 for ; Wed, 23 Apr 2003 11:28:53 -0400 Received: (qmail 15972 invoked by uid 65534); 23 Apr 2003 15:28:46 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023-rz3) with SMTP; 23 Apr 2003 17:28:46 +0200 From: "Julian Reschke" To: "B. Shadgar" , "WebDAV" Date: Wed, 23 Apr 2003 17:28:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3EA6AE7C.630FCE1A@cs.bris.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEOAHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7583 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > Sent: Wednesday, April 23, 2003 5:17 PM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: Reminder: WG Last Call on Ordered Collections > > ... > > May I ask about practical example or cases about WebDAV Ordered > Collections > protocol. It is not clear to me why we define new protocol when > we have the > search protocol's ordering option. In other words, which aspects > of ordering > can not be covered by the search protocol's ordering option. See: -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 23 11:42:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23808 for ; Wed, 23 Apr 2003 11:42:19 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFiUWM021621; Wed, 23 Apr 2003 11:44:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NFiTGv021600; Wed, 23 Apr 2003 11:44:29 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 11:44:29 -0400 (EDT) Resent-Message-Id: <200304231544.h3NFiTGv021600@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NFiSWM021545 for ; Wed, 23 Apr 2003 11:44:28 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3NFiRsi002448 for ; Wed, 23 Apr 2003 11:44:27 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 23 Apr 2003 16:44:20 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id QAA21111 for ; Wed, 23 Apr 2003 16:44:10 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id QAA29641; Wed, 23 Apr 2003 16:44:10 +0100 (BST) Message-ID: <3EA6B4C9.B823607E@cs.bris.ac.uk> Date: Wed, 23 Apr 2003 16:44:09 +0100 From: "B. Shadgar" Organization: Bristol University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: WebDAV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/3EA6B4C9.B823607E@cs.bris.ac.uk To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7584 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: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > > Sent: Wednesday, April 23, 2003 5:17 PM > > To: Jim Whitehead > > Cc: WebDAV > > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > ... > > > > May I ask about practical example or cases about WebDAV Ordered > > Collections > > protocol. It is not clear to me why we define new protocol when > > we have the > > search protocol's ordering option. In other words, which aspects > > of ordering > > can not be covered by the search protocol's ordering option. > > See: > .html#rfc.section.2.p.2> > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Thanks Julian. But can't we use the properties instead. For example in case of having a book, just define a property called page, or if there is no proper property, just create a proper one for them. I read the documentation, it is saying "The ordering protocol defined here focuses on support for such human-maintained orderings." What does it mean by human-maintained ordering? Sorry if it is very basic question. Bita. From w3c-dist-auth-request@w3.org Wed Apr 23 12:37:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25463 for ; Wed, 23 Apr 2003 12:37:27 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NGdhWM012627; Wed, 23 Apr 2003 12:39:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NGddq2012556; Wed, 23 Apr 2003 12:39:39 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 12:39:39 -0400 (EDT) Resent-Message-Id: <200304231639.h3NGddq2012556@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NGdcWM012508 for ; Wed, 23 Apr 2003 12:39:38 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3NGdbsi030202 for ; Wed, 23 Apr 2003 12:39:37 -0400 Received: (qmail 21555 invoked by uid 65534); 23 Apr 2003 16:39:29 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 23 Apr 2003 18:39:29 +0200 From: "Julian Reschke" To: "B. Shadgar" , Cc: "WebDAV" Date: Wed, 23 Apr 2003 18:39:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3EA6B4C9.B823607E@cs.bris.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEOEHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7585 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: Content-Transfer-Encoding: 7bit Hi, some more thoughts: Properties are attached to resources. Ordering is a property of the collection that contains internal member names identifying resources. For instance, you might have several collections containing bindings to the same set of resources, but with different orderings. There's no way to simulate this with DASL (which -- by the way -- is not nearly done...) and returning ordered results. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > Sent: Wednesday, April 23, 2003 5:44 PM > To: w3c-dist-auth@w3.org > Cc: WebDAV > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > Julian Reschke wrote: > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > > > Sent: Wednesday, April 23, 2003 5:17 PM > > > To: Jim Whitehead > > > Cc: WebDAV > > > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > > > ... > > > > > > May I ask about practical example or cases about WebDAV Ordered > > > Collections > > > protocol. It is not clear to me why we define new protocol when > > > we have the > > > search protocol's ordering option. In other words, which aspects > > > of ordering > > > can not be covered by the search protocol's ordering option. > > > > See: > > > .html#rfc.section.2.p.2> > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Thanks Julian. But can't we use the properties instead. For example in case of having a book, just define a property called page, or if there is no proper property, just create a proper one for them. I read the documentation, it is saying "The ordering protocol defined here focuses on support for such human-maintained orderings." What does it mean by human-maintained ordering? Sorry if it is very basic question. Bita. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 23 13:00:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26376 for ; Wed, 23 Apr 2003 13:00:21 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NH2eWM021843; Wed, 23 Apr 2003 13:02:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NH2d98021824; Wed, 23 Apr 2003 13:02:39 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 13:02:39 -0400 (EDT) Resent-Message-Id: <200304231702.h3NH2d98021824@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NH2cWM021781 for ; Wed, 23 Apr 2003 13:02:38 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3NH2bsi007151 for ; Wed, 23 Apr 2003 13:02:38 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 23 Apr 2003 18:02:24 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id SAA27138; Wed, 23 Apr 2003 18:02:14 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id SAA29778; Wed, 23 Apr 2003 18:02:13 +0100 (BST) Message-ID: <3EA6C714.2368BFA0@cs.bris.ac.uk> Date: Wed, 23 Apr 2003 18:02:12 +0100 From: "B. Shadgar" Organization: Bristol University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/3EA6C714.2368BFA0@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7586 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: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Hi, > > some more thoughts: > > Properties are attached to resources. Ordering is a property of the > collection that contains internal member names identifying resources. For > instance, you might have several collections containing bindings to the same > set of resources, but with different orderings. There's no way to simulate > this with DASL (which -- by the way -- is not nearly done...) and returning > ordered results. > > Julian > Ok, what if we define a live property called resource-name which is representing the name of a resource? Bita. From w3c-dist-auth-request@w3.org Wed Apr 23 13:33:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27468 for ; Wed, 23 Apr 2003 13:33:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NHa1WM001879; Wed, 23 Apr 2003 13:36:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NHZwrQ001854; Wed, 23 Apr 2003 13:35:58 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 13:35:58 -0400 (EDT) Resent-Message-Id: <200304231735.h3NHZwrQ001854@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NHZuWM001821 for ; Wed, 23 Apr 2003 13:35:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3NHZtsi024146 for ; Wed, 23 Apr 2003 13:35:55 -0400 Received: (qmail 13464 invoked by uid 65534); 23 Apr 2003 17:35:49 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp017-rz3) with SMTP; 23 Apr 2003 19:35:49 +0200 From: "Julian Reschke" To: "B. Shadgar" , "Julian Reschke" Cc: "w3c-dist-auth" Date: Wed, 23 Apr 2003 19:35:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3EA6C714.2368BFA0@cs.bris.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEOGHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7587 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > Sent: Wednesday, April 23, 2003 7:02 PM > To: Julian Reschke > Cc: w3c-dist-auth > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > Julian Reschke wrote: > > > Hi, > > > > some more thoughts: > > > > Properties are attached to resources. Ordering is a property of the > > collection that contains internal member names identifying > resources. For > > instance, you might have several collections containing > bindings to the same > > set of resources, but with different orderings. There's no way > to simulate > > this with DASL (which -- by the way -- is not nearly done...) > and returning > > ordered results. > > > > Julian > > > > Ok, what if we define a live property called resource-name which is > representing the name of a resource? We can't, because the name isn't a property of the resource. It's a property of the binding *to* the resource (of which there can be many), and which belongs to the state of the parent collection. BTW: how would that help? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 23 13:54:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28031 for ; Wed, 23 Apr 2003 13:54:56 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NHuaWM007663; Wed, 23 Apr 2003 13:56:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NHuXgD007637; Wed, 23 Apr 2003 13:56:33 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 13:56:33 -0400 (EDT) Resent-Message-Id: <200304231756.h3NHuXgD007637@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NHuWWM007602 for ; Wed, 23 Apr 2003 13:56:32 -0400 (EDT) Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3NHuVsi031328 for ; Wed, 23 Apr 2003 13:56:32 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 23 Apr 2003 18:56:21 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id SAA01067 for ; Wed, 23 Apr 2003 18:55:00 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id SAA29873; Wed, 23 Apr 2003 18:54:59 +0100 (BST) Message-ID: <3EA6D373.B52AD992@cs.bris.ac.uk> Date: Wed, 23 Apr 2003 18:54:59 +0100 From: "B. Shadgar" Organization: Bristol University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: w3c-dist-auth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/3EA6D373.B52AD992@cs.bris.ac.uk To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7588 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: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > > Sent: Wednesday, April 23, 2003 7:02 PM > > To: Julian Reschke > > Cc: w3c-dist-auth > > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > > > > > Julian Reschke wrote: > > > > > Hi, > > > > > > some more thoughts: > > > > > > Properties are attached to resources. Ordering is a property of the > > > collection that contains internal member names identifying > > resources. For > > > instance, you might have several collections containing > > bindings to the same > > > set of resources, but with different orderings. There's no way > > to simulate > > > this with DASL (which -- by the way -- is not nearly done...) > > and returning > > > ordered results. > > > > > > Julian > > > > > > > Ok, what if we define a live property called resource-name which is > > representing the name of a resource? > > We can't, because the name isn't a property of the resource. It's a property > of the binding *to* the resource (of which there can be many), and which > belongs to the state of the parent collection. > > BTW: how would that help? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 Well, I was thinking that maybe the best use case of the Ordering protocol was regarded to the versioning of resources. In this case, I though if every time that a revision is created, a live property containing the name of resource was attached to the resource, maybe we didn't need to the new Ordered protocol. Does it make sense? Bita. From w3c-dist-auth-request@w3.org Wed Apr 23 14:35:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29668 for ; Wed, 23 Apr 2003 14:35:22 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NIbhWM018970; Wed, 23 Apr 2003 14:37:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3NIbUwH018890; Wed, 23 Apr 2003 14:37:30 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 14:37:30 -0400 (EDT) Resent-Message-Id: <200304231837.h3NIbUwH018890@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3NIbTWM018840 for ; Wed, 23 Apr 2003 14:37:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3NIbSsi011042 for ; Wed, 23 Apr 2003 14:37:28 -0400 Received: (qmail 29209 invoked by uid 65534); 23 Apr 2003 18:37:21 -0000 Received: from pD950C272.dip.t-dialin.net (HELO lisa) (217.80.194.114) by mail.gmx.net (mp018-rz3) with SMTP; 23 Apr 2003 20:37:21 +0200 From: "Julian Reschke" To: "B. Shadgar" , Date: Wed, 23 Apr 2003 20:37:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3EA6D373.B52AD992@cs.bris.ac.uk> Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEOJHBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7589 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > Sent: Wednesday, April 23, 2003 7:55 PM > To: w3c-dist-auth@w3.org > Cc: w3c-dist-auth > Subject: Re: Reminder: WG Last Call on Ordered Collections > .. > > Well, I was thinking that maybe the best use case of the Ordering > protocol was > regarded to the versioning of resources. In this case, I though > if every time > that a revision is created, a live property containing the name > of resource was > > attached to the resource, maybe we didn't need to the new Ordered > protocol. > > Does it make sense? Now you got me confused :-) What's the relation of (1) resource names and (2) versioning to ordering collection members? Julian From w3c-dist-auth-request@w3.org Thu Apr 24 05:58:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09834 for ; Thu, 24 Apr 2003 05:58:37 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3OA0oWM018093; Thu, 24 Apr 2003 06:00:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3OA0biu018067; Thu, 24 Apr 2003 06:00:37 -0400 (EDT) Resent-Date: Thu, 24 Apr 2003 06:00:37 -0400 (EDT) Resent-Message-Id: <200304241000.h3OA0biu018067@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3OA0aWM018035 for ; Thu, 24 Apr 2003 06:00:36 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3OA0asi013186 for ; Thu, 24 Apr 2003 06:00:36 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 24 Apr 2003 11:00:27 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA04495; Thu, 24 Apr 2003 11:00:06 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id LAA00622; Thu, 24 Apr 2003 11:00:06 +0100 (BST) Message-ID: <3EA7B5A6.8C0D1807@cs.bris.ac.uk> Date: Thu, 24 Apr 2003 11:00:06 +0100 From: "B. Shadgar" Organization: Bristol University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Reschke CC: "B. Shadgar" , w3c-dist-auth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/3EA7B5A6.8C0D1807@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7590 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: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > > Sent: Wednesday, April 23, 2003 7:55 PM > > To: w3c-dist-auth@w3.org > > Cc: w3c-dist-auth > > Subject: Re: Reminder: WG Last Call on Ordered Collections > > .. > > > > Well, I was thinking that maybe the best use case of the Ordering > > protocol was > > regarded to the versioning of resources. In this case, I though > > if every time > > that a revision is created, a live property containing the name > > of resource was > > > > attached to the resource, maybe we didn't need to the new Ordered > > protocol. > > > > Does it make sense? > > Now you got me confused :-) What's the relation of (1) resource names and > (2) versioning to ordering collection members? > > Julian Dear Julian Sorry. I may be wrong, it is just some thought. 1) the resource names to ordering collection: By my undrestanding, what is suggested in the ordering collection, is a way to change the order of resources and put them the at the beginning or end of the list, after or before a given resource. Also this is true that in the Real numbers you can always find a number less or a number greater than a given number. Consider, you have a live property called resource-name which is made by the name of resource followed by a Real number. Now every time you would like to have a new order, system can change the resource- name based on your order (by changing the Real part of resource-names) . Then by using the order option on the resource-name in the Search protocol we can have the desired order. 2) Versioning to ordering collection: The tree in the section 8 of the orderd-collections-protocol reminds me of the situation in the Versioning. This reminding and some other thoughts (maybe silly) caused to say so. I hope I didn't make you more confused. If so, I apologize again. Regards, Bita. From w3c-dist-auth-request@w3.org Thu Apr 24 13:25:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24293 for ; Thu, 24 Apr 2003 13:25:30 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3OHRXWM027001; Thu, 24 Apr 2003 13:27:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3OHRNxa026904; Thu, 24 Apr 2003 13:27:23 -0400 (EDT) Resent-Date: Thu, 24 Apr 2003 13:27:23 -0400 (EDT) Resent-Message-Id: <200304241727.h3OHRNxa026904@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3OHRLWM026872 for ; Thu, 24 Apr 2003 13:27:21 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3OHRKsi026280 for ; Thu, 24 Apr 2003 13:27:21 -0400 Received: (qmail 21028 invoked by uid 65534); 24 Apr 2003 17:27:14 -0000 Received: from p3EE2481E.dip.t-dialin.net (HELO lisa) (62.226.72.30) by mail.gmx.net (mp013-rz3) with SMTP; 24 Apr 2003 19:27:14 +0200 From: "Julian Reschke" To: "B. Shadgar" , "Julian Reschke" Cc: "w3c-dist-auth" Date: Thu, 24 Apr 2003 19:27:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3EA7B5A6.8C0D1807@cs.bris.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEBHHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7591 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > Sent: Thursday, April 24, 2003 12:00 PM > To: Julian Reschke > Cc: B. Shadgar; w3c-dist-auth > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > > Julian Reschke wrote: > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar > > > Sent: Wednesday, April 23, 2003 7:55 PM > > > To: w3c-dist-auth@w3.org > > > Cc: w3c-dist-auth > > > Subject: Re: Reminder: WG Last Call on Ordered Collections > > > .. > > > > > > Well, I was thinking that maybe the best use case of the Ordering > > > protocol was > > > regarded to the versioning of resources. In this case, I though > > > if every time > > > that a revision is created, a live property containing the name > > > of resource was > > > > > > attached to the resource, maybe we didn't need to the new Ordered > > > protocol. > > > > > > Does it make sense? > > > > Now you got me confused :-) What's the relation of (1) resource > names and > > (2) versioning to ordering collection members? > > > > Julian > > Dear Julian > > Sorry. I may be wrong, it is just some thought. > 1) the resource names to ordering collection: > > By my undrestanding, what is suggested in the ordering > collection, is a way > to change the order of resources and put them the at the > beginning or end of > the list, after or before a given resource. Also this is true that in the > Real numbers you can always find a number less or a number greater than a > given number. > Consider, you have a live property called resource-name which is > made by the > name of resource followed by a Real number. Now every time you > would like to > have a new order, system can change the resource- name based on your order > (by changing the Real part of resource-names) . Then by using the order > option on the resource-name in the Search protocol we can have the desired > order. I understand that you're saying that using a combination of dead properties and DASL queries, similar results could be obtained. This is true. However, modelling collection ordering as property of the containing collection has the following advantages: - no need to modify resources - no need to come up with unique property names per containing collection - no dependendy on an unfinished spec - existing clients can take immediate advantage by just not sorting a PROPFIND result - ... > ... Hope this helps in understanding the motivation, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Apr 25 10:51:54 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11476 for ; Fri, 25 Apr 2003 10:51:54 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3PEqiWM023503; Fri, 25 Apr 2003 10:52:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3PEqBXr023179; Fri, 25 Apr 2003 10:52:11 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 10:52:11 -0400 (EDT) Resent-Message-Id: <200304251452.h3PEqBXr023179@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3PEq9WM023144 for ; Fri, 25 Apr 2003 10:52:10 -0400 (EDT) Received: from mta01-srv.alltel.net (mta01.alltel.net [166.102.165.143]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3PEq9si000912 for ; Fri, 25 Apr 2003 10:52:09 -0400 Received: from [162.40.242.16] ([162.40.240.195]) by mta01-srv.alltel.net with ESMTP id <20030425145208.LFQG14880.mta01-srv.alltel.net@[162.40.242.16]> for ; Fri, 25 Apr 2003 09:52:08 -0500 Mime-Version: 1.0 Message-Id: Date: Fri, 25 Apr 2003 10:51:54 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV for personal accounts X-Archived-At: http://www.w3.org/mid/p05210606bacefb40d8e7@[162.40.242.16] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7592 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: Hello all, Everyone tells me that it is not possible for WebDAV to be implemented in support of individual (personal) accounts on an Apache webserver. I am specifically interested in the Apache webserver that ships with both MacOS X and MacOS X Server but I'd suppose that this question and any answers to it would generalize to all other instances of Apache and mod_dav. The reason for my interest in this is that I want to offer my users (faculty and students) a high level of ease-of-use and avoid the use of FTP and Microsft FrontPage Server Extensions for security and resource conservation reasons. The reasons given for this "impossible" task all tend to focus on permissions. Apache web sites all have to be owned by the "www" user and this is hard wired into both Apache and mod_dav. OK, fine, but why must this always and forever be so? Why can't this ownership dimension be externalized such that it can be configured by editing the hpptd.conf or some other file? While I can understand the interest in supporting workgroups with all of the interesting challenges of protecting co-workers from one another, individuals and their work are important as well. In the larger context of the politics of open standards, it does not make sense to ignore the most numerous block of web workers and focus exclusively upon a small elite population of workgroups. The client side of things is in place to support both individuals and workgroups -- all that is needed is a complimentary server-side effort. Accordingly, I'd like to suggest that http://www.webdav.org/ maintain a list of webservers that can be used to extend WebDAV functionality to individuals whose web pages are addressed in the form of: http://www.myserver.edu/~username -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Sun Apr 27 01:51:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07380 for ; Sun, 27 Apr 2003 01:51:34 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3R5rhWM013291; Sun, 27 Apr 2003 01:53:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3R5rWiL013278; Sun, 27 Apr 2003 01:53:32 -0400 (EDT) Resent-Date: Sun, 27 Apr 2003 01:53:32 -0400 (EDT) Resent-Message-Id: <200304270553.h3R5rWiL013278@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3R5rSWM013246 for ; Sun, 27 Apr 2003 01:53:28 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3R5rRsi004895 for ; Sun, 27 Apr 2003 01:53:28 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA12510 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 26 Apr 2003 22:53:26 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA12487 sender obsfucated@us.ibm.com; Sat, 26 Apr 2003 22:53:24 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3R5qo9d135846; Sun, 27 Apr 2003 01:52:53 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h3R5qm2K027844; Sun, 27 Apr 2003 01:52:49 -0400 To: Frank Lowney Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Jason Crawford Message-ID: Date: Sun, 27 Apr 2003 01:52:47 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|April 23, 2003) at 04/27/2003 01:52:49, Serialize complete at 04/27/2003 01:52:49 Content-Type: text/plain; charset="us-ascii" Subject: Re: WebDAV for personal accounts X-Archived-At: http://www.w3.org/mid/OF0E7F31BD.6498549A-ON85256D15.001F185E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7593 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: On Friday, 04/25/2003 at 10:51 AST, Frank Lowney wrote: > Hello all, > > Everyone tells me that it is not possible for WebDAV to be > implemented in support of individual (personal) accounts on an Apache > webserver. That seems odd to me. I've not tried mod_dav in about 3 years, but what I know of Apache suggests that you can use it for whatever accounts you define. Perhaps I just misunderstand your statement though. So what specifically have you heard prevents one from using it in support of the accounts that you mention? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Apr 28 11:04:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03860 for ; Mon, 28 Apr 2003 11:04:56 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SF69WM024814; Mon, 28 Apr 2003 11:06:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3SF5eOT024537; Mon, 28 Apr 2003 11:05:40 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 11:05:40 -0400 (EDT) Resent-Message-Id: <200304281505.h3SF5eOT024537@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SF5dWM024502 for ; Mon, 28 Apr 2003 11:05:39 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3SF5csi020687 for ; Mon, 28 Apr 2003 11:05:39 -0400 Received: (qmail 24902 invoked by uid 65534); 28 Apr 2003 15:05:32 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 28 Apr 2003 17:05:32 +0200 From: "Julian Reschke" To: "WebDAV" Date: Mon, 28 Apr 2003 17:05:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEJGHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7594 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: Content-Transfer-Encoding: 7bit OK, now that the WG last call period has ended, let's decide how to proceed. There was one open issue, for which there was one vote for change (Lisa), and one vote for no change (Geoff). As acting editor I lean to no-change. If this is ok for everybody, I'll submit the draft located at http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest. html as version 08. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Tuesday, April 22, 2003 10:23 PM > To: Jim Whitehead; WebDAV > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > Thans Jim, > > the current edits are this URL: > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > ol-latest. > html > > There's currently one unresolved issue for which I am looking for > feedback: > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > ol-latest. > html#rfc.issue.6.1-when-are-members-added > > In case that there's no additional feedback, the plan is to close > it as "no > change". > > Regards, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Apr 28 15:04:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10512 for ; Mon, 28 Apr 2003 15:04:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SJ6PWM024365; Mon, 28 Apr 2003 15:06:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3SJ69W0024309; Mon, 28 Apr 2003 15:06:09 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 15:06:09 -0400 (EDT) Resent-Message-Id: <200304281906.h3SJ69W0024309@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SJ68WM024276 for ; Mon, 28 Apr 2003 15:06:08 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3SJ67si020792 for ; Mon, 28 Apr 2003 15:06:07 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19ADwv-0003iD-00; Mon, 28 Apr 2003 19:06:01 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19ADwt-0003i2-00; Mon, 28 Apr 2003 19:06:00 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'WebDAV'" Date: Mon, 28 Apr 2003 12:05:57 -0700 Message-ID: <024c01c30db9$3781f340$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/024c01c30db9$3781f340$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7595 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: Content-Transfer-Encoding: 7bit "No change" isn't acceptable when the comment is that something is not specified. My last issue was "if a destination is not being overwritten, then shouldn't the MOVE (the rename) preserve ordering?" The spec can say "When a resource is moved within a collection and the destination did not previously exist (the 'rename' case), its relative ordering MUST be preserved." Or the spec could say SHOULD or MAY. However, staying silent on an issue like this allows some implementors to assume MUST and others to assume MAY. That said, if a sentence like this is added to the draft we do not need to go through WG last call again for this issue. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Monday, April 28, 2003 8:06 AM > To: WebDAV > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > OK, > > now that the WG last call period has ended, let's decide how > to proceed. > > There was one open issue, for which there was one vote for > change (Lisa), > and one vote for no change (Geoff). As acting editor I lean > to no-change. If > this is ok for everybody, I'll submit the draft located at > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-lat est. html as version 08. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Tuesday, April 22, 2003 10:23 PM > To: Jim Whitehead; WebDAV > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > Thans Jim, > > the current edits are this URL: > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > ol-latest. > html > > There's currently one unresolved issue for which I am looking for > feedback: > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > ol-latest. > html#rfc.issue.6.1-when-are-members-added > > In case that there's no additional feedback, the plan is to close > it as "no > change". > > Regards, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Mon Apr 28 17:34:00 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15113 for ; Mon, 28 Apr 2003 17:33:59 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SLaHWM013215; Mon, 28 Apr 2003 17:36:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3SLaCvt013203; Mon, 28 Apr 2003 17:36:12 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 17:36:12 -0400 (EDT) Resent-Message-Id: <200304282136.h3SLaCvt013203@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3SLaBWM013171 for ; Mon, 28 Apr 2003 17:36:11 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3SLaAsi028962 for ; Mon, 28 Apr 2003 17:36:11 -0400 Received: (qmail 16065 invoked by uid 65534); 28 Apr 2003 21:36:04 -0000 Received: from pD950C24C.dip.t-dialin.net (HELO lisa) (217.80.194.76) by mail.gmx.net (mp018-rz3) with SMTP; 28 Apr 2003 23:36:04 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'WebDAV'" Date: Mon, 28 Apr 2003 23:36:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <024c01c30db9$3781f340$f8cb90c6@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEKFHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7596 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: Content-Transfer-Encoding: 7bit Lisa, > The spec can say "When a resource is moved within a collection and the > destination did not previously exist (the 'rename' case), its relative > ordering MUST be preserved." Or the spec could say SHOULD or MAY. > However, staying silent on an issue like this allows some implementors > to assume MUST and others to assume MAY. if the spec is silent on the issue simply means that it's undefined. So an implementor that assumes this mean "MUST" simply is wrong. The point being, we (Geoff and myself) feel that the spec shouldn't require any specific server behaviour, and thus not defining it at all seems to be absolutely reasonable. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, April 28, 2003 9:06 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > "No change" isn't acceptable when the comment is that something is not > specified. My last issue was "if a destination is not being > overwritten, then shouldn't the MOVE (the rename) preserve ordering?" > > The spec can say "When a resource is moved within a collection and the > destination did not previously exist (the 'rename' case), its relative > ordering MUST be preserved." Or the spec could say SHOULD or MAY. > However, staying silent on an issue like this allows some implementors > to assume MUST and others to assume MAY. > > That said, if a sentence like this is added to the draft we do not need > to go through WG last call again for this issue. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > Sent: Monday, April 28, 2003 8:06 AM > > To: WebDAV > > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > > > > > OK, > > > > now that the WG last call period has ended, let's decide how > > to proceed. > > > > There was one open issue, for which there was one vote for > > change (Lisa), > > and one vote for no change (Geoff). As acting editor I lean > > to no-change. If > > this is ok for everybody, I'll submit the draft located at > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-lat > est. > html > > as version 08. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Sent: Tuesday, April 22, 2003 10:23 PM > > To: Jim Whitehead; WebDAV > > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > > > > > Thans Jim, > > > > the current edits are this URL: > > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > > ol-latest. > > html > > > > There's currently one unresolved issue for which I am looking for > > feedback: > > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > > ol-latest. > > html#rfc.issue.6.1-when-are-members-added > > > > In case that there's no additional feedback, the plan is to close > > it as "no > > change". > > > > Regards, > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > From w3c-dist-auth-request@w3.org Tue Apr 29 12:26:32 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29960 for ; Tue, 29 Apr 2003 12:26:31 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TGSZWM002804; Tue, 29 Apr 2003 12:28:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3TGSFFX002739; Tue, 29 Apr 2003 12:28:15 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 12:28:15 -0400 (EDT) Resent-Message-Id: <200304291628.h3TGSFFX002739@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TGSEWM002706 for ; Tue, 29 Apr 2003 12:28:14 -0400 (EDT) Received: from mta02-srv.alltel.net (mta02.alltel.net [166.102.165.144]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3TGSEsi011852 for ; Tue, 29 Apr 2003 12:28:14 -0400 Received: from [192.168.1.100] ([162.40.243.106]) by mta02-srv.alltel.net with ESMTP id <20030429162812.XSOL28309.mta02-srv.alltel.net@[192.168.1.100]> for ; Tue, 29 Apr 2003 11:28:12 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 29 Apr 2003 12:28:10 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebCT WebDAV Claims X-Archived-At: http://www.w3.org/mid/p0521060dbad4538f6970@[192.168.1.100] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7597 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: Can anyone here confirm or disconfirm whether or not the following version of WebCT (which claims to be WebDAV-compliant) is, in fact, WebDAV-compliant? WebCT Vista 1.2 (based upon the BEA WebLogic webserver) See: http://www.webct.com/products/viewpage?name=products_vista From the user manual, the following claim is made: WebDAV (World Wide Web Distributed Authoring and Versioning) protocol is an Internet Engineering Task Force standard for collaborative authoring on the Web. WebCT is fully functional with the WebDAV file system. Users can set up a web folder connection to either an accessible learning context folder or their My Files folder. For more information, visit the WebDAV home page at http://www.webdav.org . Once set up, the WebCT folder appears as a typical folder on their local computer. Users can drag and drop files into that folder and, if connected to the internet, the web folder will synchronize automatically to the WebCT server. I am trying to track down why several WebDAV-compliant applications and clients are having difficulty with this server. If I can establish for a fact that it is basically compliant and that these apps/clients **should** be able to work with it, I can direct my attention elsewhere. Are there lists of servers that are WebDAV-compliant with ratings or notes on the degree of that compliance? Are there lists of applications and clients that are WebDAV-compliant with ratings or notes on the degree of that compliance? -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Tue Apr 29 13:12:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02063 for ; Tue, 29 Apr 2003 13:12:50 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3THF3WM015500; Tue, 29 Apr 2003 13:15:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3THF1LC015485; Tue, 29 Apr 2003 13:15:01 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 13:15:01 -0400 (EDT) Resent-Message-Id: <200304291715.h3THF1LC015485@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3THF0WM015411 for ; Tue, 29 Apr 2003 13:15:00 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3THExsi027273 for ; Tue, 29 Apr 2003 13:15:00 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19AYh0-00071V-00; Tue, 29 Apr 2003 17:14:58 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19AYh0-00071K-00; Tue, 29 Apr 2003 17:14:58 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'WebDAV'" Date: Tue, 29 Apr 2003 10:15:03 -0700 Message-ID: <034801c30e72$df477a50$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/034801c30e72$df477a50$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7598 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: Content-Transfer-Encoding: 7bit Why should the spec be silent when people have reasonable questions about whether an issue works one way or another? If no specific behavior is required, you must still say so. Otherwise readers *will* assume. Lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, April 28, 2003 2:36 PM > To: Lisa Dusseault; 'Julian Reschke'; 'WebDAV' > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > Lisa, > > > The spec can say "When a resource is moved within a > collection and the > > destination did not previously exist (the 'rename' case), > its relative > > ordering MUST be preserved." Or the spec could say SHOULD or MAY. > > However, staying silent on an issue like this allows some > implementors > > to assume MUST and others to assume MAY. > > if the spec is silent on the issue simply means that it's > undefined. So an > implementor that assumes this mean "MUST" simply is wrong. > The point being, > we (Geoff and myself) feel that the spec shouldn't require > any specific > server behaviour, and thus not defining it at all seems to be > absolutely > reasonable. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Monday, April 28, 2003 9:06 PM > > To: 'Julian Reschke'; 'WebDAV' > > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > > > > > "No change" isn't acceptable when the comment is that > something is not > > specified. My last issue was "if a destination is not being > > overwritten, then shouldn't the MOVE (the rename) preserve > ordering?" > > > > The spec can say "When a resource is moved within a > collection and the > > destination did not previously exist (the 'rename' case), > its relative > > ordering MUST be preserved." Or the spec could say SHOULD or MAY. > > However, staying silent on an issue like this allows some > implementors > > to assume MUST and others to assume MAY. > > > > That said, if a sentence like this is added to the draft we > do not need > > to go through WG last call again for this issue. > > > > Lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > > Sent: Monday, April 28, 2003 8:06 AM > > > To: WebDAV > > > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > > > > > > > > > OK, > > > > > > now that the WG last call period has ended, let's decide how > > > to proceed. > > > > > > There was one open issue, for which there was one vote for > > > change (Lisa), > > > and one vote for no change (Geoff). As acting editor I lean > > > to no-change. If > > > this is ok for everybody, I'll submit the draft located at > > > > > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-pr > otocol-lat > > est. > > html > > > > as version 08. > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > > Sent: Tuesday, April 22, 2003 10:23 PM > > > To: Jim Whitehead; WebDAV > > > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > > > > > > > > > Thans Jim, > > > > > > the current edits are this URL: > > > > > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > > > ol-latest. > > > html > > > > > > There's currently one unresolved issue for which I am looking for > > > feedback: > > > > > > > > > http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protoc > > > ol-latest. > > > html#rfc.issue.6.1-when-are-members-added > > > > > > In case that there's no additional feedback, the plan is to close > > > it as "no > > > change". > > > > > > Regards, > > > > > > Julian > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- > tel:+492512807760 > > > > > > > > > > > From w3c-dist-auth-request@w3.org Tue Apr 29 15:12:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06864 for ; Tue, 29 Apr 2003 15:12:27 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TJEfWM029267; Tue, 29 Apr 2003 15:14:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3TJEbkI029211; Tue, 29 Apr 2003 15:14:37 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 15:14:37 -0400 (EDT) Resent-Message-Id: <200304291914.h3TJEbkI029211@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TJEaWM029179 for ; Tue, 29 Apr 2003 15:14:36 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3TJEZsi024515 for ; Tue, 29 Apr 2003 15:14:36 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h3TJClb06649 for ; Tue, 29 Apr 2003 12:12:47 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 29 Apr 2003 12:10:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: End: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEGOHDAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7599 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: Content-Transfer-Encoding: 7bit The working group last call for comments period on the WebDAV Ordered Collections Protocol, draft-ietf-webdav-ordering-protocol-07, has ended. Issues raised during the WG Last Call for comments period are summarized in: http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest. html (See "Issues List" immediately after the Table of Contents). There is currently one open issue which is in the process of resolution on the WG mailing list (issue 6.1, when-are-members-added). Once the open issues have been resolved, the document editor, Julian Reschke, will issue a new Internet-Draft. Once this has been done, draft-ietf-webdav-ordering-protocol-08 will be sent to the IESG for approval as a Proposed Standard. - Jim Whitehead Co-Chair IETF WebDAV WG From w3c-dist-auth-request@w3.org Tue Apr 29 15:18:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07376 for ; Tue, 29 Apr 2003 15:18:34 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TJKOWM000531; Tue, 29 Apr 2003 15:20:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3TJJxqc000288; Tue, 29 Apr 2003 15:19:59 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 15:19:59 -0400 (EDT) Resent-Message-Id: <200304291919.h3TJJxqc000288@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TJJwWM000224 for ; Tue, 29 Apr 2003 15:19:58 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3TJJwsi027204 for ; Tue, 29 Apr 2003 15:19:58 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h3TJIDb08852 for ; Tue, 29 Apr 2003 12:18:13 -0700 (PDT) From: "Jim Whitehead" To: "'WebDAV'" Date: Tue, 29 Apr 2003 12:15:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <034801c30e72$df477a50$f8cb90c6@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEGOHDAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7600 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: Content-Transfer-Encoding: 7bit Lisa Dusseault writes: > Why should the spec be silent when people have reasonable questions > about whether an issue works one way or another? If no specific > behavior is required, you must still say so. Otherwise readers *will* > assume. Geoff Clemm writes: > For (3), I don't think making a special case for "move within a > collection" vs. "move outside of the collection" is worth optimizing, > since it makes the spec more complicated and is likely to be enough > of a problem to some servers to make it likely to not be followed anyway. I'm not sure I understand the objection the Geoff raises (i.e., I don't see what the potential problems might be). IMO, the principle of least astonishment applies here. If a resource has a given name (final path segment) in a collection, and then is given a new name (final path segment), a user would expect that resource to keep its current position, unless the ordering explicitly depends on the value of the final path segment. So, I'm with Lisa, I think some additional language here would be good (MUST preserve position for MOVEs that only change final path segment except when the order semantics explicitly depend on the URL or final path segment). - Jim From w3c-dist-auth-request@w3.org Tue Apr 29 16:04:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08727 for ; Tue, 29 Apr 2003 16:04:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TK6sWM008909; Tue, 29 Apr 2003 16:06:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3TK6nmm008880; Tue, 29 Apr 2003 16:06:49 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 16:06:49 -0400 (EDT) Resent-Message-Id: <200304292006.h3TK6nmm008880@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TK6mWM008847 for ; Tue, 29 Apr 2003 16:06:48 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3TK6lsi013017 for ; Tue, 29 Apr 2003 16:06:47 -0400 Received: (qmail 19857 invoked by uid 65534); 29 Apr 2003 20:06:41 -0000 Received: from p3EE24757.dip.t-dialin.net (HELO lisa) (62.226.71.87) by mail.gmx.net (mp006-rz3) with SMTP; 29 Apr 2003 22:06:41 +0200 From: "Julian Reschke" To: "Frank Lowney" , Date: Tue, 29 Apr 2003 22:06:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: WebCT WebDAV Claims X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMENBHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7601 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Frank Lowney > Sent: Tuesday, April 29, 2003 6:28 PM > To: w3c-dist-auth@w3.org > Subject: WebCT WebDAV Claims > > > > ... > > Are there lists of applications and clients that are WebDAV-compliant > with ratings or notes on the degree of that compliance? IHMO no. However, you may want to try the "litmus" test suite which checks WebDAV conformance of servers and IMHO currently is the best thing that we have to measure compliance: http://www.webdav.org/neon/litmus/ -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Apr 29 17:24:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11282 for ; Tue, 29 Apr 2003 17:24:56 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TLR7WM002512; Tue, 29 Apr 2003 17:27:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3TLR2Il002493; Tue, 29 Apr 2003 17:27:02 -0400 (EDT) Resent-Date: Tue, 29 Apr 2003 17:27:02 -0400 (EDT) Resent-Message-Id: <200304292127.h3TLR2Il002493@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3TLR1WM002458 for ; Tue, 29 Apr 2003 17:27:01 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3TLR1si018110 for ; Tue, 29 Apr 2003 17:27:01 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 29 Apr 2003 17:08:54 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 29 Apr 2003 17:26:54 -0400 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 29 Apr 2003 17:26:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED792@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7602 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: The "principle of regularity" states that if a moved resource is moved to the end of the ordering in some cases, it is more regular for it to be moved to the end of the ordering in all cases, and not make the behavior dependent on whether the destination collection is the same as the source collection. For folks that expect regularity, it will be "less astonishing" for the behavior to be regular, and not special-cased in the way you suggest. Note this just explains my rationale. I personally don't have a strong preference either way. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Tuesday, April 29, 2003 3:16 PM To: 'WebDAV' Subject: RE: Reminder: WG Last Call on Ordered Collections Lisa Dusseault writes: > Why should the spec be silent when people have reasonable questions > about whether an issue works one way or another? If no specific > behavior is required, you must still say so. Otherwise readers *will* > assume. Geoff Clemm writes: > For (3), I don't think making a special case for "move within a > collection" vs. "move outside of the collection" is worth optimizing, > since it makes the spec more complicated and is likely to be enough > of a problem to some servers to make it likely to not be followed anyway. I'm not sure I understand the objection the Geoff raises (i.e., I don't see what the potential problems might be). IMO, the principle of least astonishment applies here. If a resource has a given name (final path segment) in a collection, and then is given a new name (final path segment), a user would expect that resource to keep its current position, unless the ordering explicitly depends on the value of the final path segment. So, I'm with Lisa, I think some additional language here would be good (MUST preserve position for MOVEs that only change final path segment except when the order semantics explicitly depend on the URL or final path segment). - Jim From w3c-dist-auth-request@w3.org Wed Apr 30 12:53:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11605 for ; Wed, 30 Apr 2003 12:53:40 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3UGtZWM023511; Wed, 30 Apr 2003 12:55:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3UGt72M023398; Wed, 30 Apr 2003 12:55:07 -0400 (EDT) Resent-Date: Wed, 30 Apr 2003 12:55:07 -0400 (EDT) Resent-Message-Id: <200304301655.h3UGt72M023398@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3UGt5WM023366 for ; Wed, 30 Apr 2003 12:55:05 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3UGt4si026501 for ; Wed, 30 Apr 2003 12:55:05 -0400 Received: (qmail 31372 invoked by uid 65534); 30 Apr 2003 16:54:58 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 30 Apr 2003 18:54:58 +0200 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Wed, 30 Apr 2003 18:54:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPHHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7603 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, April 29, 2003 11:27 PM > To: 'WebDAV' > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > The "principle of regularity" states that if a moved resource is moved to > the end of the ordering in some cases, it is more regular for it > to be moved > to the end of the ordering in all cases, and not make the > behavior dependent > on whether the destination collection is the same as the source > collection. > > For folks that expect regularity, it will be "less astonishing" for the > behavior to be regular, and not special-cased in the way you suggest. > > Note this just explains my rationale. I personally don't have a strong > preference either way. Yes. To summarize the possible variations: 1) specify that a MOVE inside a collection does not add a new member -> in this case a "rename" operation won't change ordering, but will be completely inconsistent with the cross-collection MOVE (where a new member *is* added and thus the Position header semantics apply) 2) specify that a MOVE inside a collection removes the old and adds a new member -> consistency with cross-collection MOVE operation, but ordering will be lost when done by a client that isn't aware of ordering semantics 3) do not mandate a specific behaviour (the current wording) -- in which case we'd still need to decide whether spec needs to be more specific about this being server-defined behaviour. I think in doubt we should consider simplicity of the spec as well, therefore leave things as they are and possibly make that more explicit. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Apr 30 12:56:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11866 for ; Wed, 30 Apr 2003 12:56:29 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3UGwEWM024157; Wed, 30 Apr 2003 12:58:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h3UGwEFs024145; Wed, 30 Apr 2003 12:58:14 -0400 (EDT) Resent-Date: Wed, 30 Apr 2003 12:58:14 -0400 (EDT) Resent-Message-Id: <200304301658.h3UGwEFs024145@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h3UGwDWM024110 for ; Wed, 30 Apr 2003 12:58:13 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h3UGwCsi028034 for ; Wed, 30 Apr 2003 12:58:12 -0400 Received: (qmail 7502 invoked by uid 65534); 30 Apr 2003 16:58:06 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp022-rz3) with SMTP; 30 Apr 2003 18:58:06 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'WebDAV'" Date: Wed, 30 Apr 2003 18:58:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <034801c30e72$df477a50$f8cb90c6@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Reminder: WG Last Call on Ordered Collections X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEPIHCAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7604 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: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, April 29, 2003 7:15 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: Reminder: WG Last Call on Ordered Collections > > > > Why should the spec be silent when people have reasonable questions > about whether an issue works one way or another? If no specific > behavior is required, you must still say so. Otherwise readers *will* > assume. Lisa, I disagree. It's simply impractical to list all the things a spec doesn't specify. If it's unspecified, readers MUST NOT assume. That being said, if the WG thinks that there's a real risk that this particular part may be misinterpreted, we surely can try to clarify (in case we decide that we want this to stay server-defined). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760