From w3c-dist-auth-request@w3.org Tue Jul 1 07:24: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 HAA07517 for ; Tue, 1 Jul 2003 07:24: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 h61BOMSn016683; Tue, 1 Jul 2003 07:24:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h61BOERe016593; Tue, 1 Jul 2003 07:24:14 -0400 (EDT) Resent-Date: Tue, 1 Jul 2003 07:24:14 -0400 (EDT) Resent-Message-Id: <200307011124.h61BOERe016593@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h61BODSn016560 for ; Tue, 1 Jul 2003 07:24:13 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h61BOCvx014075 for ; Tue, 1 Jul 2003 07:24:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07468; Tue, 1 Jul 2003 07:24:09 -0400 (EDT) Message-Id: <200307011124.HAA07468@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Jul 2003 07:24:09 -0400 Subject: I-D ACTION:draft-ietf-webdav-bind-02.txt X-Archived-At: http://www.w3.org/mid/200307011124.HAA07468@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7707 X-Loop: 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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to WebDAV Author(s) : G. Clemm, J. Crawford Filename : draft-ietf-webdav-bind-02.txt Pages : 19 Date : 2003-6-30 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-bind-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-bind-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151627.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jul 1 08:12:41 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 HAA07516 for ; Tue, 1 Jul 2003 07:24:20 -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 h61BOMSn016679; Tue, 1 Jul 2003 07:24:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h61BOICi016647; Tue, 1 Jul 2003 07:24:18 -0400 (EDT) Resent-Date: Tue, 1 Jul 2003 07:24:18 -0400 (EDT) Resent-Message-Id: <200307011124.h61BOICi016647@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h61BOHSn016611 for ; Tue, 1 Jul 2003 07:24:17 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h61BOHvx014084 for ; Tue, 1 Jul 2003 07:24:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07504; Tue, 1 Jul 2003 07:24:14 -0400 (EDT) Message-Id: <200307011124.HAA07504@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Jul 2003 07:24:14 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-10.txt X-Archived-At: http://www.w3.org/mid/200307011124.HAA07504@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7708 X-Loop: 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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Access Control Protocol Author(s) : G. Clemm et al. Filename : draft-ietf-webdav-acl-10.txt Pages : 66 Date : 2003-6-30 This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the acl@webdav.org mailing list. Other related documents can be found at http://www.example.com/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-acl-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30151637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151637.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Jul 2 06:59: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 GAA03746 for ; Wed, 2 Jul 2003 06:59: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 h62AwRSn000567; Wed, 2 Jul 2003 06:58:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h62Avvd4000514; Wed, 2 Jul 2003 06:57:57 -0400 (EDT) Resent-Date: Wed, 2 Jul 2003 06:57:57 -0400 (EDT) Resent-Message-Id: <200307021057.h62Avvd4000514@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h62AvuSn000479 for ; Wed, 2 Jul 2003 06:57:56 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h62Avpvx019461 for ; Wed, 2 Jul 2003 06:57:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03387; Wed, 2 Jul 2003 06:57:50 -0400 (EDT) Message-Id: <200307021057.GAA03387@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 06:57:50 -0400 Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-04.txt X-Archived-At: http://www.w3.org/mid/200307021057.GAA03387@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7709 X-Loop: 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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis Author(s) : L. Dusseault, J. Crawford Filename : draft-ietf-webdav-rfc2518bis-04.txt Pages : 96 Date : 2003-7-1 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-rfc2518bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1135108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135108.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jul 8 08:15:55 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 IAA18793 for ; Tue, 8 Jul 2003 08:15:55 -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 h68CFuSn028967; Tue, 8 Jul 2003 08:15:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h68CFehY028929; Tue, 8 Jul 2003 08:15:40 -0400 (EDT) Resent-Date: Tue, 8 Jul 2003 08:15:40 -0400 (EDT) Resent-Message-Id: <200307081215.h68CFehY028929@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h68CFeSn028894 for ; Tue, 8 Jul 2003 08:15:40 -0400 (EDT) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h68CFcvx022082 for ; Tue, 8 Jul 2003 08:15:39 -0400 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.11.6/8.9.3) id h68CFZh30324; Tue, 8 Jul 2003 14:15:36 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id <3GBM704W>; Tue, 8 Jul 2003 14:15:35 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Tue, 8 Jul 2003 14:15:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3454A.A2984350" Subject: BIND: precondition DAV:name-allowed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7710 X-Loop: 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: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3454A.A2984350 Content-Type: text/plain; charset="iso-8859-1" What exactly should be checked for the DAV:name-allowed precondition? Thanks, Peter ------_=_NextPart_001_01C3454A.A2984350 Content-Type: text/html; charset="iso-8859-1" BIND: precondition DAV:name-allowed

What exactly should be checked for the DAV:name-allowed precondition?

Thanks,
Peter

------_=_NextPart_001_01C3454A.A2984350-- From w3c-dist-auth-request@w3.org Tue Jul 8 08:24:09 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 IAA18972 for ; Tue, 8 Jul 2003 08:24:09 -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 h68CO9Sn000024; Tue, 8 Jul 2003 08:24:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h68CO9pk000016; Tue, 8 Jul 2003 08:24:09 -0400 (EDT) Resent-Date: Tue, 8 Jul 2003 08:24:09 -0400 (EDT) Resent-Message-Id: <200307081224.h68CO9pk000016@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h68CO8Sn029987 for ; Tue, 8 Jul 2003 08:24:08 -0400 (EDT) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h68CO7vx023944 for ; Tue, 8 Jul 2003 08:24:07 -0400 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.11.6/8.9.3) id h68CO4h01208; Tue, 8 Jul 2003 14:24:04 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id <3GBM706X>; Tue, 8 Jul 2003 14:24:03 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Tue, 8 Jul 2003 14:24:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3454B.D0E6DB80" Subject: BIND: precondition DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7711 X-Loop: 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: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3454B.D0E6DB80 Content-Type: text/plain; charset="iso-8859-1" I didn't understand what the default is. If no Overwrite header is specified and the collection already contains a binding with the specified segment, does it overwrite or does it throw a precondition violation? Thanks, Peter ------_=_NextPart_001_01C3454B.D0E6DB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BIND: precondition DAV:can-overwrite

I didn't understand what the default is. If no = Overwrite header is specified and the collection already contains a = binding with the specified segment, does it overwrite or does it throw = a precondition violation?

Thanks,
Peter

------_=_NextPart_001_01C3454B.D0E6DB80-- From w3c-dist-auth-request@w3.org Tue Jul 8 09:11: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 JAA20498 for ; Tue, 8 Jul 2003 09:11:28 -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 h68DBTSn014454; Tue, 8 Jul 2003 09:11:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h68DBRmL014428; Tue, 8 Jul 2003 09:11:27 -0400 (EDT) Resent-Date: Tue, 8 Jul 2003 09:11:27 -0400 (EDT) Resent-Message-Id: <200307081311.h68DBRmL014428@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h68DBPSn014400 for ; Tue, 8 Jul 2003 09:11:25 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h68DBOvx003975 for ; Tue, 8 Jul 2003 09:11:25 -0400 Received: (qmail 23143 invoked by uid 65534); 8 Jul 2003 13:11:18 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp022) with SMTP; 08 Jul 2003 15:11:18 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Tue, 8 Jul 2003 15:11:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C34563.2EB79D50" 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: BIND: precondition DAV:name-allowed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7712 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C34563.2EB79D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit BIND: precondition DAV:name-allowedThings like invalid segment names, for instance it may make sense to reject xyz%80 because this can't be UTF-8-decoded. -- 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 Nevermann, Dr., Peter Sent: Tuesday, July 08, 2003 2:16 PM To: 'w3c-dist-auth@w3.org' Subject: BIND: precondition DAV:name-allowed What exactly should be checked for the DAV:name-allowed precondition? Thanks, Peter ------=_NextPart_000_0024_01C34563.2EB79D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BIND: precondition DAV:name-allowed
Things=20 like invalid segment names, for instance it may make sense to=20 reject
 
    xyz%80
 
because this can't be UTF-8-decoded.
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, = Dr.,=20 Peter
Sent: Tuesday, July 08, 2003 2:16 PM
To:=20 'w3c-dist-auth@w3.org'
Subject: BIND: precondition=20 DAV:name-allowed

What exactly should be checked for the = DAV:name-allowed=20 precondition?

Thanks,
Peter=20

------=_NextPart_000_0024_01C34563.2EB79D50-- From w3c-dist-auth-request@w3.org Tue Jul 8 17:59:38 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 RAA12195 for ; Tue, 8 Jul 2003 17:59: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 h68LxeSn007412; Tue, 8 Jul 2003 17:59:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h68LxOVx007360; Tue, 8 Jul 2003 17:59:24 -0400 (EDT) Resent-Date: Tue, 8 Jul 2003 17:59:24 -0400 (EDT) Resent-Message-Id: <200307082159.h68LxOVx007360@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h68LxNSn007338 for ; Tue, 8 Jul 2003 17:59:23 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h68LxMvx014003 for ; Tue, 8 Jul 2003 17:59:22 -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 h68LviX11119 for ; Tue, 8 Jul 2003 14:57:44 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 8 Jul 2003 14:59:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C34561.7BB9E330" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: WebDAV .NET Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7713 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C34561.7BB9E330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageAccidentally caught by the spam filter. - Jim -----Original Message----- From: Rade Josovic [mailto:rade.josovic@t-online.de] Sent: Tuesday, July 08, 2003 8:55 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV .NET Dear Greg, We want to inform you that we just release WebDAV protocol API for Microsoft .NET Framework and Microsoft .NET Compact Framework. This is first full implemetation of WebDAV protocol ( RFC 2518 ) for .NET Framework. Please visit us at http://www.independentsoft.de . We ask you, if possible to put link to us on your web site www.webdav.org . Best regards, Rade Josovic Independentsoft ------=_NextPart_000_000F_01C34561.7BB9E330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Accidentally caught by the spam=20 filter.
 
-=20 Jim
 
-----Original Message-----
From: Rade Josovic=20 [mailto:rade.josovic@t-online.de]
Sent: Tuesday, July 08, 2003 = 8:55=20 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 WebDAV .NET

Dear=20 Greg,
 
We = want to inform=20 you that we just release WebDAV protocol API for Microsoft .NET = Framework and=20 Microsoft .NET Compact Framework.
 
This = is first full=20 implemetation of WebDAV protocol ( RFC 2518 ) for .NET=20 Framework.
Please = visit us at=20 http://www.independentsoft.de= =20 .
 
We ask = you, if=20 possible to put link to us on your web site www.webdav.org .
 
Best=20 regards,
Rade=20 Josovic
Independentsoft
 ------=_NextPart_000_000F_01C34561.7BB9E330-- From w3c-dist-auth-request@w3.org Wed Jul 9 11:05:33 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 LAA03934 for ; Wed, 9 Jul 2003 11:05:33 -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 h69F5YSn019923; Wed, 9 Jul 2003 11:05:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h69F5Ei6019840; Wed, 9 Jul 2003 11:05:14 -0400 (EDT) Resent-Date: Wed, 9 Jul 2003 11:05:14 -0400 (EDT) Resent-Message-Id: <200307091505.h69F5Ei6019840@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h69F5DSn019815 for ; Wed, 9 Jul 2003 11:05:13 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h69F5Dvx016471 for ; Wed, 9 Jul 2003 11:05:13 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h69F585U082546 for ; Wed, 9 Jul 2003 11:05:08 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h69F56xg031262 for ; Wed, 9 Jul 2003 11:05:07 -0400 In-Reply-To: To: "'w3c-dist-auth@w3.org'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 9 Jul 2003 11:05:05 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/09/2003 11:05:06, Serialize complete at 07/09/2003 11:05:06 Content-Type: multipart/alternative; boundary="=_alternative 000A684D85256D5E_=" Subject: Re: BIND: precondition DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7714 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 000A684D85256D5E_= Content-Type: text/plain; charset="US-ASCII" First sentence of last paragraph of Section 4: "By default, if there already is a binding for the specified segment in the collection, the new binding replaces the existing binding." So by default, it overwrites. Another way to reach this conclusion is to note that the DAV:can-overwrite precondition is not violated in this case, and therefore it would not throw a precondition violation. Cheers, Geoff Peter wrote on 07/08/2003 08:24:02 AM: > I didn't understand what the default is. If no Overwrite header is > specified and the collection already contains a binding with the > specified segment, does it overwrite or does it throw a preconditionviolation? > Thanks, > Peter --=_alternative 000A684D85256D5E_= Content-Type: text/html; charset="US-ASCII"
First sentence of last paragraph of Section 4:

"By default, if there already is a binding for the specified
 segment in the collection, the new binding replaces the
 existing binding."

So by default, it overwrites.

Another way to reach this conclusion is to note that the
DAV:can-overwrite precondition is not violated in this case,
and therefore it would not throw a precondition violation.

Cheers,
Geoff

Peter wrote on 07/08/2003 08:24:02 AM:

> I didn't understand what the default is. If no Overwrite header is
> specified and the collection already contains a binding with the
> specified segment, does it overwrite or does it throw a preconditionviolation?
> Thanks,
> Peter --=_alternative 000A684D85256D5E_=-- From w3c-dist-auth-request@w3.org Wed Jul 9 14:22: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 OAA12945 for ; Wed, 9 Jul 2003 14:22:57 -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 h69IMvSn020283; Wed, 9 Jul 2003 14:22:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h69IMmQP020252; Wed, 9 Jul 2003 14:22:48 -0400 (EDT) Resent-Date: Wed, 9 Jul 2003 14:22:48 -0400 (EDT) Resent-Message-Id: <200307091822.h69IMmQP020252@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h69IMkSn020222 for ; Wed, 9 Jul 2003 14:22:47 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h69IMkvx008928 for ; Wed, 9 Jul 2003 14:22:46 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19aJaY-0000bH-00 for w3c-dist-auth@w3c.org; Wed, 09 Jul 2003 18:22:46 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19aJaV-0000b6-00 for w3c-dist-auth@w3c.org; Wed, 09 Jul 2003 18:22:44 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 9 Jul 2003 11:22:39 -0700 Message-ID: <004a01c34647$1ca67840$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h69IMkSn020222 Subject: Vienna plans X-Archived-At: http://www.w3.org/mid/004a01c34647$1ca67840$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7715 X-Loop: 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: 8bit I'm putting together an agenda for Vienna. Is anybody going to be there who can lead a discussion on - bindings - ACL - search The agenda items we can cover so far are: - Interop plans – 15 min - when, where, etc. - ACL progress - RFC2518bis open issues Anything else I'm missing? Feedback would be appreciated ASAP as we're supposed to have an agenda already. Lisa From w3c-dist-auth-request@w3.org Thu Jul 10 04:14: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 EAA21984 for ; Thu, 10 Jul 2003 04:14: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 h6A8ELm1019484; Thu, 10 Jul 2003 04:14:21 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6A8E6BK019238; Thu, 10 Jul 2003 04:14:06 -0400 (EDT) Resent-Date: Thu, 10 Jul 2003 04:14:06 -0400 (EDT) Resent-Message-Id: <200307100814.h6A8E6BK019238@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6A8Dtm1019154 for ; Thu, 10 Jul 2003 04:13:55 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6A8Dsvx027468 for ; Thu, 10 Jul 2003 04:13:54 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h6A8Dqe22483; Thu, 10 Jul 2003 10:13:52 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id <3GBM9K5M>; Thu, 10 Jul 2003 10:13:52 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Thu, 10 Jul 2003 10:13:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C346BB.2EF40AC0" Subject: COPY and bindings X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47F57@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7718 X-Loop: 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: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C346BB.2EF40AC0 Content-Type: text/plain; charset="iso-8859-1" Suppose the following: - a resource R - a collection C1 with a binding x to R - a collection C2 with a binding y to R - a collection C mapped to URI-1 containing C1 and C2 i.e.: C / \ C1 C2 \ / R Now I issue a COPY on URI-1 with destination URI-2 and depth infinity. How many copies do I get for R, one or two? i.e.: C' / \ C1' C2' \ / R' or C' / \ C1' C2' | | R' R" ?? I suspect that 2 copies is correct ... or at least, the server is allowed to duplicate R at destination. Thanks, Peter ------_=_NextPart_001_01C346BB.2EF40AC0 Content-Type: text/html; charset="iso-8859-1" COPY and bindings

Suppose the following:
- a resource R
- a collection C1 with a binding x to R
- a collection C2 with a binding y to R
- a collection C mapped to URI-1 containing C1 and C2

i.e.:

    C
   / \
  C1 C2
   \ /
    R

Now I issue a COPY on URI-1 with destination URI-2 and depth infinity.

How many copies do I get for R, one or two?

i.e.:

    C'
   / \
 C1' C2'
   \ /
    R'

or

    C'
   / \
 C1' C2'
  |   |
  R'  R"

??

I suspect that 2 copies is correct ... or at least, the server is allowed to duplicate R at destination.

Thanks,
Peter

------_=_NextPart_001_01C346BB.2EF40AC0-- From w3c-dist-auth-request@w3.org Thu Jul 10 12:26: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 MAA10714 for ; Thu, 10 Jul 2003 12:26:55 -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 h6AGQvUi013304; Thu, 10 Jul 2003 12:26:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6AGQsPP013201; Thu, 10 Jul 2003 12:26:54 -0400 (EDT) Resent-Date: Thu, 10 Jul 2003 12:26:54 -0400 (EDT) Resent-Message-Id: <200307101626.h6AGQsPP013201@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6AGQ6Wo011636 for ; Thu, 10 Jul 2003 12:26:50 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AG99vx032349 for ; Thu, 10 Jul 2003 12:09:09 -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 h6AG8Pi20872; Thu, 10 Jul 2003 09:08:26 -0700 (PDT) From: "Jim Whitehead" To: "Nevermann, Dr., Peter" , Date: Thu, 10 Jul 2003 09:09:40 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: COPY and bindings X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEEDIDAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7720 X-Loop: 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 Excellent question. I'd say that the current language in bind-02 doesn't sufficiently cover this case, and we should clarify it. Another possible outcome for your scenario is that you get zero additional copies of R, that only C is duplicated, but all its bindings stay the same. I don't think these are the semantics we want (i.e., I'm not advocating them), but they are another possible reading of the current specification (and hence another reason why we need to clarify the semantics of copy for depth infinity). I have a slight leaning towards preserving the bind structure of the source at the destination, and hence in your scenario I'd choose: C' / \ C1' C2' \ / R' - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, Dr., Peter Sent: Thursday, July 10, 2003 1:14 AM To: 'w3c-dist-auth@w3.org' Subject: COPY and bindings Suppose the following: - a resource R - a collection C1 with a binding x to R - a collection C2 with a binding y to R - a collection C mapped to URI-1 containing C1 and C2 i.e.: C / \ C1 C2 \ / R Now I issue a COPY on URI-1 with destination URI-2 and depth infinity. How many copies do I get for R, one or two? i.e.: C' / \ C1' C2' \ / R' or C' / \ C1' C2' | | R' R" ?? I suspect that 2 copies is correct ... or at least, the server is allowed to duplicate R at destination. Thanks, Peter From w3c-dist-auth-request@w3.org Thu Jul 10 12:26: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 MAA10726 for ; Thu, 10 Jul 2003 12:26: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 h6AGQvUi013299; Thu, 10 Jul 2003 12:26:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6AGQcoJ012319; Thu, 10 Jul 2003 12:26:38 -0400 (EDT) Resent-Date: Thu, 10 Jul 2003 12:26:38 -0400 (EDT) Resent-Message-Id: <200307101626.h6AGQcoJ012319@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6AGQ6Vi011636 for ; Thu, 10 Jul 2003 12:26:33 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AGKsvx002819; Thu, 10 Jul 2003 12:20:54 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6AGKmxr144808; Thu, 10 Jul 2003 12:20:48 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6AGKkDQ057946; Thu, 10 Jul 2003 12:20:47 -0400 In-Reply-To: To: "Nevermann, Dr., Peter" Cc: "'w3c-dist-auth@w3.org'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 10 Jul 2003 12:20:25 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/10/2003 12:20:46, Serialize complete at 07/10/2003 12:20:46 Content-Type: text/plain; charset="US-ASCII" Subject: Re: COPY and bindings X-Archived-At: http://www.w3.org/mid/OFC43277AB.CB935ACE-ON85256D5F.005911D7-85256D5F.0059C926@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7719 X-Loop: 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: Good question. I would argue that 1 copy is the more desireable behavior, but 2 copies will be easier for many servers to implement (for example, that is what "cp -r" does on Unix). So my preferences would be (from high to low): 1- require 1 copy 2- leave it up to the server 3- require 2 copies. Any votes? Cheers, Geoff Peter wrote on 07/10/2003 04:13:45 AM: > Suppose the following: > - a resource R > - a collection C1 with a binding x to R > - a collection C2 with a binding y to R > - a collection C mapped to URI-1 containing C1 and C2 > i.e.: > C > / \ > C1 C2 > \ / > R > Now I issue a COPY on URI-1 with destination URI-2 and depth infinity. > How many copies do I get for R, one or two? > i.e.: > C' > / \ > C1' C2' > \ / > R' > or > C' > / \ > C1' C2' > | | > R' R" > ?? > I suspect that 2 copies is correct ... or at least, the server is > allowed to duplicate R at destination. > Thanks, > Peter From w3c-dist-auth-request@w3.org Thu Jul 10 13:18: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 NAA12951 for ; Thu, 10 Jul 2003 13:18: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 h6AHINUi007666; Thu, 10 Jul 2003 13:18:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6AHILvq007640; Thu, 10 Jul 2003 13:18:21 -0400 (EDT) Resent-Date: Thu, 10 Jul 2003 13:18:21 -0400 (EDT) Resent-Message-Id: <200307101718.h6AHILvq007640@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6AHIKUk007587 for ; Thu, 10 Jul 2003 13:18:20 -0400 (EDT) Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6AHIJvx019154; Thu, 10 Jul 2003 13:18:19 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by catbox.hotcat.org (8.12.6/8.12.6) with ESMTP id h6AHLXWZ013070; Thu, 10 Jul 2003 10:21:36 -0700 Message-ID: <3F0DA002.90106@nasa.gov> Date: Thu, 10 Jul 2003 10:18:58 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "Nevermann, Dr., Peter" , "'w3c-dist-auth@w3.org'" , w3c-dist-auth-request@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: COPY and bindings X-Archived-At: http://www.w3.org/mid/3F0DA002.90106@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7721 X-Loop: 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 Geoffrey M Clemm wrote: >Good question. I would argue that 1 copy is the more desireable >behavior, but 2 copies will be easier for many servers to implement >(for example, that is what "cp -r" does on Unix). > >So my preferences would be (from high to low): >1- require 1 copy >2- leave it up to the server >3- require 2 copies. > >Any votes? > I'd definitely go for 1 (maintaining bindings with a copy) but I understand the server implementation implications are a bit of a challenge, especially for fs-backed servers. I'd strongly discourage 2 (maybe make the behavior a SHOULD instead of a MUST.) Moreso, I'd vote that it should be encouraged to maintain consistent behavior from the server (for intra-server copies) and the client (for inter-server copies). Certainly 3 is easier for clients to perform *unless you have loops*. I'm currently researching some implementation implications (using an RDBMS-backed server) of looping binds and it's not perty. It should be possible for a client (using the DAV:resourceid property) to identify if it's encountered a loop...But it would have to do copies step-wise as a PROPFIND Depth: infinity would result in a 506 Loop Detected error and incomplete/no information. Actually, it'd have to do this anyways whether it recreated bindings or "split on copy". 8^O From w3c-dist-auth-request@w3.org Thu Jul 10 17:26: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 RAA22573 for ; Thu, 10 Jul 2003 17:26: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 h6ALQ2Ui009904; Thu, 10 Jul 2003 17:26:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6ALPtfS009870; Thu, 10 Jul 2003 17:25:55 -0400 (EDT) Resent-Date: Thu, 10 Jul 2003 17:25:55 -0400 (EDT) Resent-Message-Id: <200307102125.h6ALPtfS009870@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6ALPrUi009834 for ; Thu, 10 Jul 2003 17:25:53 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6ALPqvx019332 for ; Thu, 10 Jul 2003 17:25:52 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA16198 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 10 Jul 2003 14:25:51 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id OAA16163 sender obsfucated@us.ibm.com; Thu, 10 Jul 2003 14:25:49 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6ALPH5U048960; Thu, 10 Jul 2003 17:25:17 -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 h6ALPGh5225420; Thu, 10 Jul 2003 17:25:16 -0400 To: Chris Knight Cc: Geoffrey M Clemm , "Nevermann, Dr., Peter" , "'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: Thu, 10 Jul 2003 17:25:11 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/10/2003 17:25:16, Serialize complete at 07/10/2003 17:25:16 Content-Type: multipart/alternative; boundary="=_alternative 007502C985256D5F_=" Subject: Re: COPY and bindings X-Archived-At: http://www.w3.org/mid/OF39B897D4.4F57D5E7-ON85256D5F.0074892F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7722 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 007502C985256D5F_= Content-Type: text/plain; charset="us-ascii" I recommend that we specify that the server SHOULD create a single copy of the resource. To encourage this we can also point out that this can improve the performance of the operation because it can prevent the recopying/xmitting of identical subtrees. The server probably has to do loop detection anyway to avoid infinite loops, so this shouldn't be difficult to do. J. --=_alternative 007502C985256D5F_= Content-Type: text/html; charset="us-ascii"
I recommend that we specify that the server SHOULD create a single copy of the resource.  To encourage this we can also point out that this can improve the performance of the operation because it can prevent the recopying/xmitting of identical subtrees.  The server probably has to do loop detection anyway to avoid infinite loops, so this shouldn't be difficult to do.

J. --=_alternative 007502C985256D5F_=-- From w3c-dist-auth-request@w3.org Fri Jul 11 03:15:10 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 DAA19066 for ; Fri, 11 Jul 2003 03:15:09 -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 h6B7FBUi005645; Fri, 11 Jul 2003 03:15:11 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6B7Es6k005572; Fri, 11 Jul 2003 03:14:54 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 03:14:54 -0400 (EDT) Resent-Message-Id: <200307110714.h6B7Es6k005572@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6B7EqUi005538 for ; Fri, 11 Jul 2003 03:14:52 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6B7Epvx005353 for ; Fri, 11 Jul 2003 03:14:51 -0400 Received: (qmail 28211 invoked by uid 65534); 11 Jul 2003 07:14:46 -0000 Received: from p3EE24766.dip.t-dialin.net (HELO lisa) (62.226.71.102) by mail.gmx.net (mp003) with SMTP; 11 Jul 2003 09:14:46 +0200 From: "Julian Reschke" To: "Jason Crawford" , "Chris Knight" Cc: "Geoffrey M Clemm" , "Nevermann, Dr., Peter" , Date: Fri, 11 Jul 2003 09:14:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C3478C.DC6620E0" 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: COPY and bindings X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDCHNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7723 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C3478C.DC6620E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agreed. Should we mention that it can't be a "must" because there may be servers where only parts of the URL namespace support multiple bindings? 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 Jason Crawford Sent: Thursday, July 10, 2003 11:25 PM To: Chris Knight Cc: Geoffrey M Clemm; Nevermann, Dr., Peter; 'w3c-dist-auth@w3.org' Subject: Re: COPY and bindings I recommend that we specify that the server SHOULD create a single copy of the resource. To encourage this we can also point out that this can improve the performance of the operation because it can prevent the recopying/xmitting of identical subtrees. The server probably has to do loop detection anyway to avoid infinite loops, so this shouldn't be difficult to do. J. ------=_NextPart_000_0021_01C3478C.DC6620E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Agreed.
 
Should=20 we mention that it can't be a "must" because there may be servers where = only=20 parts of the URL namespace support multiple = bindings?
 
Julian
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Thursday, July 10, 2003 11:25 = PM
To: Chris=20 Knight
Cc: Geoffrey M Clemm; Nevermann, Dr., Peter;=20 'w3c-dist-auth@w3.org'
Subject: Re: COPY and=20 bindings


I = recommend that=20 we specify that the server SHOULD create a single copy of the = resource.=20  To encourage this we can also point out that this can improve = the=20 performance of the operation because it can prevent the = recopying/xmitting of=20 identical subtrees.  The server probably has to do loop detection = anyway=20 to avoid infinite loops, so this shouldn't be difficult to do.=20

J. ------=_NextPart_000_0021_01C3478C.DC6620E0-- From w3c-dist-auth-request@w3.org Fri Jul 11 11:26:38 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 LAA03503 for ; Fri, 11 Jul 2003 11:26:36 -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 h6BFQZUi026313; Fri, 11 Jul 2003 11:26:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BFQQAJ025913; Fri, 11 Jul 2003 11:26:26 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 11:26:26 -0400 (EDT) Resent-Message-Id: <200307111526.h6BFQQAJ025913@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BFQLV2025611 for ; Fri, 11 Jul 2003 11:26:22 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6BFIavx030178 for ; Fri, 11 Jul 2003 11:18:36 -0400 Received: (qmail 28757 invoked by uid 65534); 11 Jul 2003 15:18:30 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013) with SMTP; 11 Jul 2003 17:18:30 +0200 From: "Julian Reschke" To: Date: Fri, 11 Jul 2003 17:18:29 +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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Ann: RSS feed for http://greenbytes.de/tech/webdav X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEECHNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7724 X-Loop: 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, for those who are interested in RSS newfeeds: our WebDAV resources page now has an RSS feed summarizing announcements about new protocol drafts, issue resolutions etc. [1]. Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jul 11 17:40: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 RAA18539 for ; Fri, 11 Jul 2003 17:40:41 -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 h6BLegUi029764; Fri, 11 Jul 2003 17:40:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BLeYRK029359; Fri, 11 Jul 2003 17:40:34 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 17:40:34 -0400 (EDT) Resent-Message-Id: <200307112140.h6BLeYRK029359@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BLe2X6027544 for ; Fri, 11 Jul 2003 17:40:25 -0400 (EDT) Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6BLO4vx029915 for ; Fri, 11 Jul 2003 17:24:05 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by catbox.hotcat.org (8.12.6/8.12.6) with ESMTP id h6BLRWpH005535; Fri, 11 Jul 2003 14:27:32 -0700 Message-ID: <3F0F2B26.7010600@nasa.gov> Date: Fri, 11 Jul 2003 14:24:54 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: "'w3c-dist-auth@w3.org'" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/3F0F2B26.7010600@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7725 X-Loop: 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 Reading this discussion has brought up another point of confusion that may need clarification in the spec. If you have a binding loop and you are doing a Depth: infinity PROPFIND, you either (correct me if I'm wrong, 'course): a) return a 506 Loop Detected error b) return a 207 Multistatus containing responses and when you come across loops, identify them as such with a 506 Loop Detected What's unclear to me (perhaps due to the example given in the spec) is that, in the second case, do you continue traversing the tree when a 506 is encountered or do you terminate traversal? For example, if you had the following example: --C- v | 1-A->2-B->3 -D->4 Sorry for the poor ASCII graphics and it's probably unreadable. The numbers represent unique resources (think of them as resource id's.) The textual description is that the root collection "/" contains two members "/A" and "/D". "/A" contains one member "/A/B" and "/A/B" contains one member "/A/B/C" which is bound to "/A" (resource id 2). Now, presuming we do a depth-first search and we go down "/A/B" first, we would report a 200 for "/A", a 200 for "/A/B", a 506 for the loop "/A/B/C", and a 200 for "/A/D". Correct? Or do I report a 200 for "/A/B/C" and then a 506 for the fact that "/A/B/C" created a loop? How would I tell where the loop connected to? (i.e. how do I tell the loop goes back to resource id 2 and not 1?) Would I do a followup PROPFIND on "/A/B/C" to determine the resource id? What if I got back 10 506 responses? Would it be possible (correct) to either report a 200 for "/A/B/C" (containing the resource-id property) and then a 506? Or perhaps a "Resource-ID" HTTP header in the 506 response? This is important if we want clients to be able to replicate loops across servers. From w3c-dist-auth-request@w3.org Fri Jul 11 17:48: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 RAA18953 for ; Fri, 11 Jul 2003 17:48:28 -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 h6BLmUUi001954; Fri, 11 Jul 2003 17:48:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BLmU5E001941; Fri, 11 Jul 2003 17:48:30 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 17:48:30 -0400 (EDT) Resent-Message-Id: <200307112148.h6BLmU5E001941@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BLmTUi001908 for ; Fri, 11 Jul 2003 17:48:29 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6BLmSvx003318 for ; Fri, 11 Jul 2003 17:48:28 -0400 Received: (qmail 21068 invoked by uid 65534); 11 Jul 2003 21:48:22 -0000 Received: from p3EE24748.dip.t-dialin.net (HELO lisa) (62.226.71.72) by mail.gmx.net (mp002) with SMTP; 11 Jul 2003 23:48:22 +0200 From: "Julian Reschke" To: "Chris Knight" , "Julian Reschke" Cc: Date: Fri, 11 Jul 2003 23:48:15 +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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F0F2B26.7010600@nasa.gov> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEFPHNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7726 X-Loop: 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 Chris, you are right that this probably should be explained a bit better. My p.o.v. (which seems to be compatible with the example) is that the 506 should be reported once the depth:infinity processing encounters a resource that already has been traversed/reported. So, in your example, you'd report a 506 for "/A/B/C" -- note that you can't report the same resource twice. It's also correct that this means that a client that wants to replicate bindings will need an additional PROPFIND against "/A/B/C" to get the DAV:resource-id. However, this *only* applies to depth:infinity processing, which is sort of deprecated anyway (meaning servers are allowed to reject these requests, and I think moddav does this by default). So my understanding is that a "modern" client would only do depth:1 PROPFINDs, and thus never see a 506. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Chris Knight [mailto:Christopher.D.Knight@nasa.gov] > Sent: Friday, July 11, 2003 11:25 PM > To: Julian Reschke > Cc: 'w3c-dist-auth@w3.org' > Subject: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > Reading this discussion has brought up another point of confusion that > may need clarification in the spec. If you have a binding loop and you > are doing a Depth: infinity PROPFIND, you either (correct me if I'm > wrong, 'course): > > a) return a 506 Loop Detected error > b) return a 207 Multistatus containing responses and when you come > across loops, identify them as such with a 506 Loop Detected > > What's unclear to me (perhaps due to the example given in the spec) is > that, in the second case, do you continue traversing the tree when a 506 > is encountered or do you terminate traversal? > > For example, if you had the following example: > --C- > v | > 1-A->2-B->3 > -D->4 > > Sorry for the poor ASCII graphics and it's probably unreadable. The > numbers represent unique resources (think of them as resource id's.) The > textual description is that the root collection "/" contains two members > "/A" and "/D". "/A" contains one member "/A/B" and "/A/B" contains one > member "/A/B/C" which is bound to "/A" (resource id 2). > > Now, presuming we do a depth-first search and we go down "/A/B" first, > we would report a 200 for "/A", a 200 for "/A/B", a 506 for the loop > "/A/B/C", and a 200 for "/A/D". Correct? Or do I report a 200 for > "/A/B/C" and then a 506 for the fact that "/A/B/C" created a loop? > > How would I tell where the loop connected to? (i.e. how do I tell the > loop goes back to resource id 2 and not 1?) Would I do a followup > PROPFIND on "/A/B/C" to determine the resource id? What if I got back 10 > 506 responses? > > Would it be possible (correct) to either report a 200 for "/A/B/C" > (containing the resource-id property) and then a 506? Or perhaps a > "Resource-ID" HTTP header in the 506 response? > > This is important if we want clients to be able to replicate loops > across servers. > From w3c-dist-auth-request@w3.org Fri Jul 11 18:06: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 SAA19857 for ; Fri, 11 Jul 2003 18:06:26 -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 h6BM6SUi004509; Fri, 11 Jul 2003 18:06:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BM5UAQ004419; Fri, 11 Jul 2003 18:05:30 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 18:05:30 -0400 (EDT) Resent-Message-Id: <200307112205.h6BM5UAQ004419@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BM5SUi004386 for ; Fri, 11 Jul 2003 18:05:29 -0400 (EDT) Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6BM5Svx006884 for ; Fri, 11 Jul 2003 18:05:28 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by catbox.hotcat.org (8.12.6/8.12.6) with ESMTP id h6BM8upH005601; Fri, 11 Jul 2003 15:08:56 -0700 Message-ID: <3F0F34DB.80809@nasa.gov> Date: Fri, 11 Jul 2003 15:06:19 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/3F0F34DB.80809@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7727 X-Loop: 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: >Chris, > >you are right that this probably should be explained a bit better. > > First/easiest thing would be to change the example to have the 506 followed by a 200. (The example implied to me that processing stopped at the first 506.) >My p.o.v. (which seems to be compatible with the example) is that the 506 >should be reported once the depth:infinity processing encounters a resource >that already has been traversed/reported. So, in your example, you'd report >a 506 for "/A/B/C" -- note that you can't report the same resource twice. > >It's also correct that this means that a client that wants to replicate >bindings will need an additional PROPFIND against "/A/B/C" to get the >DAV:resource-id. > > Fair enough. In environments where the may be many many loops, following up with multiple PROPFIND requests might be time consuming. Is it expected that Delta-V environments (particularly with some of the advanced features) might have (many) loops? (Elias implied that bindings are prettymuch necessary and I think I remember him saying that loops are necessary as well.) >However, this *only* applies to depth:infinity processing, which is sort of >deprecated anyway (meaning servers are allowed to reject these requests, and >I think moddav does this by default). > > Yes, mod_dav does reject Depth: infinity propfinds by default. I am working on a server that has a client that very much prefers to use Depth: infinity but perhaps I'll just respond with the first case (a 506 response) and make him do Depth: 1 whenever there're loops. >So my understanding is that a "modern" client would only do depth:1 >PROPFINDs, and thus never see a 506. > :^> Being a server developer, I would love to see Depth: infinity disappear...But I'm sure client developers would say the opposite. From w3c-dist-auth-request@w3.org Fri Jul 11 18:15: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 SAA20698 for ; Fri, 11 Jul 2003 18:15:20 -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 h6BMFNUi005992; Fri, 11 Jul 2003 18:15:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BMFMq3005969; Fri, 11 Jul 2003 18:15:22 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 18:15:22 -0400 (EDT) Resent-Message-Id: <200307112215.h6BMFMq3005969@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BMFLUi005933 for ; Fri, 11 Jul 2003 18:15:21 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6BMFKvx009323 for ; Fri, 11 Jul 2003 18:15:20 -0400 Received: (qmail 17042 invoked by uid 65534); 11 Jul 2003 22:15:15 -0000 Received: from p3EE24748.dip.t-dialin.net (HELO lisa) (62.226.71.72) by mail.gmx.net (mp012) with SMTP; 12 Jul 2003 00:15:15 +0200 From: "Julian Reschke" To: "Chris Knight" , "Julian Reschke" Cc: Date: Sat, 12 Jul 2003 00:15:08 +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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F0F34DB.80809@nasa.gov> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEGCHNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7728 X-Loop: 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: Chris Knight [mailto:Christopher.D.Knight@nasa.gov] > Sent: Saturday, July 12, 2003 12:06 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: Binding loops and PROPFIND clarification needed (was Re: > COPY and bindings) > > > Julian Reschke wrote: > > >Chris, > > > >you are right that this probably should be explained a bit better. > > > > > First/easiest thing would be to change the example to have the 506 > followed by a 200. (The example implied to me that processing stopped at > the first 506.) That would break the multistatus format - every URI may only appear once. What we should do is clarify that the processing only stops *for the resource that is part of the bind loop*. So maybe just change the example to have the "looping child" appear first in the collection. > ... > Fair enough. In environments where the may be many many loops, following > up with multiple PROPFIND requests might be time consuming. Is it > expected that Delta-V environments (particularly with some of the > advanced features) might have (many) loops? (Elias implied that bindings > are prettymuch necessary and I think I remember him saying that loops > are necessary as well.) > > >However, this *only* applies to depth:infinity processing, which > is sort of > >deprecated anyway (meaning servers are allowed to reject these > requests, and > >I think moddav does this by default). > > > > > Yes, mod_dav does reject Depth: infinity propfinds by default. I am > working on a server that has a client that very much prefers to use > Depth: infinity but perhaps I'll just respond with the first case (a 506 > response) and make him do Depth: 1 whenever there're loops. Well, how does this client handle the case where (a) the server either rejects depth:infinity, or the the response to depth:infinity gets *really* big? I think it's better just not to use it... > >So my understanding is that a "modern" client would only do depth:1 > >PROPFINDs, and thus never see a 506. > > > :^> Being a server developer, I would love to see Depth: infinity > disappear...But I'm sure client developers would say the opposite. Maybe, maybe not. So which clients *do* require PROPFIND/depth:infinity? The Microsoft webfolder client doesn't. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jul 11 18:23: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 SAA21191 for ; Fri, 11 Jul 2003 18:23: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 h6BMNMUi009357; Fri, 11 Jul 2003 18:23:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BMNLRq009340; Fri, 11 Jul 2003 18:23:21 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 18:23:21 -0400 (EDT) Resent-Message-Id: <200307112223.h6BMNLRq009340@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BMNKUi009307 for ; Fri, 11 Jul 2003 18:23:20 -0400 (EDT) Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6BMNJvx011841 for ; Fri, 11 Jul 2003 18:23:19 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by catbox.hotcat.org (8.12.6/8.12.6) with ESMTP id h6BMQmpH005623; Fri, 11 Jul 2003 15:26:48 -0700 Message-ID: <3F0F3909.5090109@nasa.gov> Date: Fri, 11 Jul 2003 15:24:09 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/3F0F3909.5090109@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7729 X-Loop: 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: >>First/easiest thing would be to change the example to have the 506 >>followed by a 200. (The example implied to me that processing stopped at >>the first 506.) >> >> > >That would break the multistatus format - every URI may only appear once. > >What we should do is clarify that the processing only stops *for the >resource that is part of the bind loop*. So maybe just change the example to >have the "looping child" appear first in the collection. > > Sorry for being unclear, that's what I meant (having a different URI in the 200 after the 506.) >Maybe, maybe not. So which clients *do* require PROPFIND/depth:infinity? The >Microsoft webfolder client doesn't. > > You're right, no client requires it and could do the same by recursively PROPFINDing down the tree. Are you going to make it to the Interop? Hope to see you there! (We might even have a first pass at a BIND-capable server. :*) From w3c-dist-auth-request@w3.org Fri Jul 11 18:48: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 SAA22314 for ; Fri, 11 Jul 2003 18:48:36 -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 h6BMmdUi015038; Fri, 11 Jul 2003 18:48:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6BMmZnL014896; Fri, 11 Jul 2003 18:48:35 -0400 (EDT) Resent-Date: Fri, 11 Jul 2003 18:48:35 -0400 (EDT) Resent-Message-Id: <200307112248.h6BMmZnL014896@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6BMmYUi014863 for ; Fri, 11 Jul 2003 18:48:34 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6BMmXvx018347 for ; Fri, 11 Jul 2003 18:48:34 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19b6gr-000883-00; Fri, 11 Jul 2003 22:48:33 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19b6gn-00087s-00; Fri, 11 Jul 2003 22:48:32 +0000 From: "Lisa Dusseault" To: , "Webdav WG" Date: Fri, 11 Jul 2003 15:48:40 -0700 Message-ID: <006e01c347fe$9498e820$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: agenda@ietf.org, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h6BMmYUi014863 Subject: WebDAV WG agenda X-Archived-At: http://www.w3.org/mid/006e01c347fe$9498e820$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7730 X-Loop: 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: 8bit I know this is late but here it is anyway. WebDAV WG -- Web-based Distributed Authoring and Versioning IETF #57, Vienna Tuesday, July 15, 1545 -1645 --------------- Chairs: Lisa Dusseault (present), Jim Whitehead (absent) AGENDA - Interop plans – 15 min - when, where, etc. Official Drafts - ACL progress - Changes to -10 - Submission plans - RFC2518bis open issues - DTD usage - 207 response to DELETE method - Bindings - Copy/move behavior - Ordering -- status in IESG submission Related drafts - Search - Current status From w3c-dist-auth-request@w3.org Thu Jul 17 13:22: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 NAA14386 for ; Thu, 17 Jul 2003 13:22:48 -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 h6HHLpEh009709; Thu, 17 Jul 2003 13:21:51 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HHLfF7009696; Thu, 17 Jul 2003 13:21:41 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 13:21:41 -0400 (EDT) Resent-Message-Id: <200307171721.h6HHLfF7009696@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HHLeEh009663 for ; Thu, 17 Jul 2003 13:21:40 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HHLdvx016802 for ; Thu, 17 Jul 2003 13:21:39 -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 h6HHKiX09941 for ; Thu, 17 Jul 2003 10:20:44 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 17 Jul 2003 10:22:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01C34C4D.47DBDD50" 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 V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIECLIFAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7731 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01C34C4D.47DBDD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Winston Spencer [mailto:wspencer@fortistech.com] Sent: Wednesday, July 16, 2003 1:59 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: Interest in standardizing Batch methods? I can't see how anyone could realize the important of a standardize batch method. At the end of the day, it saves money. ------=_NextPart_000_00BE_01C34C4D.47DBDD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Winston Spencer=20 [mailto:wspencer@fortistech.com]
Sent: Wednesday, July 16, = 2003 1:59=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action] RE:=20 Interest in standardizing Batch methods?

I can’t see how = anyone could =20 realize the important of a standardize batch method.  At the end of = the=20 day, it saves money.

------=_NextPart_000_00BE_01C34C4D.47DBDD50-- From w3c-dist-auth-request@w3.org Thu Jul 17 13:43:02 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 NAA14936 for ; Thu, 17 Jul 2003 13:43:02 -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 h6HHh4Eh013493; Thu, 17 Jul 2003 13:43:04 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HHh35M013475; Thu, 17 Jul 2003 13:43:03 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 13:43:03 -0400 (EDT) Resent-Message-Id: <200307171743.h6HHh35M013475@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HHh1Eh013438 for ; Thu, 17 Jul 2003 13:43:01 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6HHh0vx022433 for ; Thu, 17 Jul 2003 13:43:00 -0400 Received: (qmail 13095 invoked by uid 65534); 17 Jul 2003 17:42:53 -0000 Received: from pD950C264.dip.t-dialin.net (HELO lisa) (217.80.194.100) by mail.gmx.net (mp003) with SMTP; 17 Jul 2003 19:42:53 +0200 From: "Julian Reschke" To: "WebDAV" Date: Thu, 17 Jul 2003 19:42:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C34C9B.9C09B6B0" 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: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDMHOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7732 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C34C9B.9C09B6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, but at the start of the day, somebody needs to write down a spec that we can discuss. So far, nobody has done that. 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 Jim Whitehead Sent: Thursday, July 17, 2003 7:22 PM To: WebDAV Subject: RE: Interest in standardizing Batch methods? Accidentally caught by the spam filter. - Jim -----Original Message----- From: Winston Spencer [mailto:wspencer@fortistech.com] Sent: Wednesday, July 16, 2003 1:59 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: Interest in standardizing Batch methods? I can't see how anyone could realize the important of a standardize batch method. At the end of the day, it saves money. ------=_NextPart_000_0006_01C34C9B.9C09B6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well,
 
but at the start of the day, somebody needs = to write=20 down a spec that we can discuss. So far, nobody has done=20 that.
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim=20 Whitehead
Sent: Thursday, July 17, 2003 7:22 = PM
To:=20 WebDAV
Subject: RE: Interest in standardizing Batch=20 methods?

Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Winston Spencer=20 [mailto:wspencer@fortistech.com]
Sent: Wednesday, July 16, = 2003 1:59=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 RE: Interest in standardizing Batch methods?

I can’t see how = anyone could =20 realize the important of a standardize batch method.  At the end = of the=20 day, it saves=20 money.

------=_NextPart_000_0006_01C34C9B.9C09B6B0-- From w3c-dist-auth-request@w3.org Thu Jul 17 14:26: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 OAA16716 for ; Thu, 17 Jul 2003 14:26: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 h6HIQuEh028168; Thu, 17 Jul 2003 14:26:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HIQimj028025; Thu, 17 Jul 2003 14:26:44 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 14:26:44 -0400 (EDT) Resent-Message-Id: <200307171826.h6HIQimj028025@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HIQhEh027992 for ; Thu, 17 Jul 2003 14:26:43 -0400 (EDT) Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HIQgvx003926 for ; Thu, 17 Jul 2003 14:26:42 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h6HIQSW19917; Thu, 17 Jul 2003 11:26:29 -0700 (PDT) Message-ID: <3F16EA8F.40904@nasa.gov> Date: Thu, 17 Jul 2003 11:27:27 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: WebDAV References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/3F16EA8F.40904@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7733 X-Loop: 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: >Well, > >but at the start of the day, somebody needs to write down a spec that we >can discuss. So far, nobody has done that. > > And boy, the semantics of batch requests are pretty hairy. At the end of the day is there much benefit? Is each request in a batch atomic and/or is the entire batch? (Do you have multiple levels of transactions?) How do you cache a batch? (Boy, there's a long topic...) The HTTP overhead for multiple requests (made over the same TCP connection, mind you) is small (arguably, couldn't be much smaller) and if you want atomic batches, locks do an ok job of it. I've certainly considered something like a PUT/PROPPATCH combination (for example if you had "required dead properties") but it's probably just easier to do a null lock and the two requests separately. From w3c-dist-auth-request@w3.org Thu Jul 17 15:17:04 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 PAA19343 for ; Thu, 17 Jul 2003 15:17:04 -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 h6HJH6Eh012122; Thu, 17 Jul 2003 15:17:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HJH4U9012098; Thu, 17 Jul 2003 15:17:04 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 15:17:04 -0400 (EDT) Resent-Message-Id: <200307171917.h6HJH4U9012098@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HJH3Eh012062 for ; Thu, 17 Jul 2003 15:17:03 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HJH3vx019148 for ; Thu, 17 Jul 2003 15:17:03 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6HJGrwO114782 for ; Thu, 17 Jul 2003 15:16:53 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HJGhhB027450 for ; Thu, 17 Jul 2003 15:16:51 -0400 In-Reply-To: <3F16EA8F.40904@nasa.gov> To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Jul 2003 15:17:09 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/17/2003 15:16:51, Serialize complete at 07/17/2003 15:16:51 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/OF1961D97D.F007B4BE-ON85256D66.0069A426-85256D66.0069F116@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7734 X-Loop: 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 Chris. The easy things aren't worth doing (you get virtually all of the benefit by streaming your requests and not blocking waiting for the response to each request), and the hard things are very complex and any given approach is unlikely to be a good basis for interoperation. Cheers, Geoff Chris wrote on 07/17/2003 02:27:27 PM: > And boy, the semantics of batch requests are pretty hairy. At the end of > the day is there much benefit? Is each request in a batch atomic and/or > is the entire batch? (Do you have multiple levels of transactions?) How > do you cache a batch? (Boy, there's a long topic...) > > The HTTP overhead for multiple requests (made over the same TCP > connection, mind you) is small (arguably, couldn't be much smaller) and > if you want atomic batches, locks do an ok job of it. > > I've certainly considered something like a PUT/PROPPATCH combination > (for example if you had "required dead properties") but it's probably > just easier to do a null lock and the two requests separately. > From w3c-dist-auth-request@w3.org Thu Jul 17 16:31: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 QAA21646 for ; Thu, 17 Jul 2003 16:31:51 -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 h6HKVsEh001858; Thu, 17 Jul 2003 16:31:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HKVcxp001834; Thu, 17 Jul 2003 16:31:38 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 16:31:38 -0400 (EDT) Resent-Message-Id: <200307172031.h6HKVcxp001834@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HKVbEh001801 for ; Thu, 17 Jul 2003 16:31:37 -0400 (EDT) Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HKVbvx004698 for ; Thu, 17 Jul 2003 16:31:37 -0400 Received: from fsa.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 17 Jul 2003 21:31:27 +0100 Received: (from nobody@localhost) by fsa.bris.ac.uk (8.11.6p2/8.11.6) id h6HKURr26926 for w3c-dist-auth@w3.org; Thu, 17 Jul 2003 21:30:27 +0100 (BST) X-Authentication-Warning: fsa.bris.ac.uk: nobody set sender to shadgar@compsci.bristol.ac.uk using -f To: WebDAV Date: Thu, 17 Jul 2003 21:30:27 +0100 From: shadgar@cs.bris.ac.uk Message-ID: <1058473827.3f1707632fa52@webmail.bris.ac.uk> References: In-Reply-To: X-Mailer: SilkyMail v1.1.8 23-July-2002 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Originating-IP: 137.222.211.155 Subject: Re: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/1058473827.3f1707632fa52@webmail.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7735 X-Loop: 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: 8bit I am sure that you guys, who don't agree with standardising Batch method, have good reasons for that. But shall we be more clear about those reasons which might not quite clear for all. Of course I know some of those reasons by chasing the thread with the same subject in the WebDAV mailing list. But I think the WebDAV protocol is almost enough mature to interest many organisations and Web users. So that they would like to apply this protocol rather HTTP protocol, and use the WebDAV advantages such as metadata, access control,... to author Web resources. Now the question is: if the WebDAV is going to be a substitute for HTTP protocol, can it handle authoring all kind of Web resources as it claims, or still we need other conventions based on the HTTP protocol in order to support authoring Web resources except file systems. So if you believe the WebDAV as a protocol for authoring all Web resources (and not only the file systems), then how we can handle Web resources such as emails and databases. In order to implement some operations on those resources, you might use a sequence of WebDAV methods which need to be considered as one transaction. In those cases lock method cannot help. So what is your suggestion to handle those operations? I think a mechanism for supporting transactions is a strong point that WebDAV needs. > > I agree with Chris. The easy things aren't worth doing (you get > virtually > all of the benefit by streaming your requests and not blocking > waiting for > the response to each request), and the hard things are very complex > and > any given approach is unlikely to be a good basis for > interoperation. > > Cheers, > Geoff > > Chris wrote on 07/17/2003 02:27:27 PM: > > > And boy, the semantics of batch requests are pretty hairy. At the > end of > > > the day is there much benefit? Is each request in a batch atomic > and/or > > is the entire batch? (Do you have multiple levels of transactions?) > How > > do you cache a batch? (Boy, there's a long topic...) > > > > The HTTP overhead for multiple requests (made over the same TCP > > connection, mind you) is small (arguably, couldn't be much smaller) > and > > if you want atomic batches, locks do an ok job of it. > > > > I've certainly considered something like a PUT/PROPPATCH > combination > > (for example if you had "required dead properties") but it's > probably > > just easier to do a null lock and the two requests separately. > > > From w3c-dist-auth-request@w3.org Thu Jul 17 17:02:15 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 RAA22656 for ; Thu, 17 Jul 2003 17:02:15 -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 h6HL2IEh009521; Thu, 17 Jul 2003 17:02:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HL2GKb009509; Thu, 17 Jul 2003 17:02:16 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 17:02:16 -0400 (EDT) Resent-Message-Id: <200307172102.h6HL2GKb009509@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HL2FEh009476 for ; Thu, 17 Jul 2003 17:02:15 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HL2Fvx013711 for ; Thu, 17 Jul 2003 17:02:15 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6HL29Kb138210 for ; Thu, 17 Jul 2003 17:02:09 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HL28hA026098 for ; Thu, 17 Jul 2003 17:02:08 -0400 In-Reply-To: <1058473827.3f1707632fa52@webmail.bris.ac.uk> To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Jul 2003 17:02:15 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/17/2003 17:02:07, Serialize complete at 07/17/2003 17:02:07 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/OF9EB838B6.28A40330-ON85256D66.007305F9-85256D66.00739088@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7736 X-Loop: 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: If you are interested in defining a transactioning model, then it would be best to make that explicit, because the term "batch" is used to encompass many things. To date, the WebDAV approach has been to define specific transacted operations (e.g. PROPPATCH), because that is something that can be implemented on a wide range of repositories, while generic transactioning support is likely to only be feasible on repositories that are actually databases. But enough repositories really are databases that it probably is worthwhile trying to define generic transactioning support for WebDAV. Cheers, Geoff > > I am sure that you guys, who don't agree with standardising Batch > method, have good reasons for that. But shall we be more clear about > those reasons which might not quite clear for all. Of course I know > some of those reasons by chasing the thread with the same subject in > the WebDAV mailing list. But I think the WebDAV protocol is almost > enough mature to interest many organisations and Web users. So that > they would like to apply this protocol rather HTTP protocol, and use > the WebDAV advantages such as metadata, access control,... to author > Web resources. > > Now the question is: if the WebDAV is going to be a substitute for HTTP > protocol, can it handle authoring all kind of Web resources as it > claims, or still we need other conventions based on the HTTP protocol > in order to support authoring Web resources except file systems. > > So if you believe the WebDAV as a protocol for authoring all Web > resources (and not only the file systems), then how we can handle Web > resources such as emails and databases. In order to implement some > operations on those resources, you might use a sequence of WebDAV > methods which need to be considered as one transaction. In those cases > lock method cannot help. So what is your suggestion to handle those > operations? > > I think a mechanism for supporting transactions is a strong point that > WebDAV needs. > > > > > I agree with Chris. The easy things aren't worth doing (you get > > virtually > > all of the benefit by streaming your requests and not blocking > > waiting for > > the response to each request), and the hard things are very complex > > and > > any given approach is unlikely to be a good basis for > > interoperation. > > > > Cheers, > > Geoff > > > > Chris wrote on 07/17/2003 02:27:27 PM: > > > > > And boy, the semantics of batch requests are pretty hairy. At the > > end of > > > > > the day is there much benefit? Is each request in a batch atomic > > and/or > > > is the entire batch? (Do you have multiple levels of transactions?) > > How > > > do you cache a batch? (Boy, there's a long topic...) > > > > > > The HTTP overhead for multiple requests (made over the same TCP > > > connection, mind you) is small (arguably, couldn't be much smaller) > > and > > > if you want atomic batches, locks do an ok job of it. > > > > > > I've certainly considered something like a PUT/PROPPATCH > > combination > > > (for example if you had "required dead properties") but it's > > probably > > > just easier to do a null lock and the two requests separately. > > > > > > From w3c-dist-auth-request@w3.org Thu Jul 17 17:20: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 RAA23059 for ; Thu, 17 Jul 2003 17:20:58 -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 h6HLL2Eh012903; Thu, 17 Jul 2003 17:21:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HLKvSl012868; Thu, 17 Jul 2003 17:20:57 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 17:20:57 -0400 (EDT) Resent-Message-Id: <200307172120.h6HLKvSl012868@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HLKtEh012835 for ; Thu, 17 Jul 2003 17:20:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6HLKsvx018342 for ; Thu, 17 Jul 2003 17:20:55 -0400 Received: (qmail 12403 invoked by uid 65534); 17 Jul 2003 21:20:49 -0000 Received: from pD950C264.dip.t-dialin.net (HELO lisa) (217.80.194.100) by mail.gmx.net (mp006) with SMTP; 17 Jul 2003 23:20:49 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , "WebDAV" Date: Thu, 17 Jul 2003 23:20:46 +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: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEELHOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7737 X-Loop: 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 True, but... ...speaking from personal experience working on a document management system, the temptation "give up" and just state "transactions are going to solve this problem in general" is big. However, transactions can be very expensive to implement, in particular in a HTTP server scenario. How many concurrent transactions are you going to support? What are you going to do if a client starts a transaction but doesn't finish it within a few minutes? IMHO it makes a lot of sense to try to *avoid* them by a) defining methods with the "right" level of transactionality (for instance, see PROPPATCH or ORDERPATCH) or b) try to do things using the existing locking and/or versioning machinery. So at a minimum, I'd expect a working group activity on transactions to start with a list of use cases. Then we can take a look at the use cases and decide whether they require a generic transaction mechanism, or whether something simpler can do that as well (and please don't say: I want to do JDBC over HTTP). 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 Geoffrey M Clemm > Sent: Thursday, July 17, 2003 11:02 PM > To: WebDAV > Subject: Re: Interest in standardizing Batch methods? > > > > If you are interested in defining a transactioning model, then > it would be best to make that explicit, because the term "batch" > is used to encompass many things. To date, the WebDAV approach has > been to define specific transacted operations (e.g. PROPPATCH), > because that is something that can be implemented on a wide range > of repositories, while generic transactioning support is likely to > only be feasible on repositories that are actually databases. > > But enough repositories really are databases that it probably is > worthwhile trying to define generic transactioning support for > WebDAV. > > Cheers, > Geoff > > > > > I am sure that you guys, who don't agree with standardising Batch > > method, have good reasons for that. But shall we be more clear about > > those reasons which might not quite clear for all. Of course I know > > some of those reasons by chasing the thread with the same subject in > > the WebDAV mailing list. But I think the WebDAV protocol is almost > > enough mature to interest many organisations and Web users. So that > > they would like to apply this protocol rather HTTP protocol, and use > > the WebDAV advantages such as metadata, access control,... to author > > Web resources. > > > > Now the question is: if the WebDAV is going to be a substitute for HTTP > > protocol, can it handle authoring all kind of Web resources as it > > claims, or still we need other conventions based on the HTTP protocol > > in order to support authoring Web resources except file systems. > > > > So if you believe the WebDAV as a protocol for authoring all Web > > resources (and not only the file systems), then how we can handle Web > > resources such as emails and databases. In order to implement some > > operations on those resources, you might use a sequence of WebDAV > > methods which need to be considered as one transaction. In those cases > > lock method cannot help. So what is your suggestion to handle those > > operations? > > > > I think a mechanism for supporting transactions is a strong point that > > WebDAV needs. > > > > > > > > I agree with Chris. The easy things aren't worth doing (you get > > > virtually > > > all of the benefit by streaming your requests and not blocking > > > waiting for > > > the response to each request), and the hard things are very complex > > > and > > > any given approach is unlikely to be a good basis for > > > interoperation. > > > > > > Cheers, > > > Geoff > > > > > > Chris wrote on 07/17/2003 02:27:27 PM: > > > > > > > And boy, the semantics of batch requests are pretty hairy. At the > > > end of > > > > > > > the day is there much benefit? Is each request in a batch atomic > > > and/or > > > > is the entire batch? (Do you have multiple levels of transactions?) > > > How > > > > do you cache a batch? (Boy, there's a long topic...) > > > > > > > > The HTTP overhead for multiple requests (made over the same TCP > > > > connection, mind you) is small (arguably, couldn't be much smaller) > > > and > > > > if you want atomic batches, locks do an ok job of it. > > > > > > > > I've certainly considered something like a PUT/PROPPATCH > > > combination > > > > (for example if you had "required dead properties") but it's > > > probably > > > > just easier to do a null lock and the two requests separately. > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Jul 17 18:03: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 SAA24144 for ; Thu, 17 Jul 2003 18:03:44 -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 h6HM3ZEh019684; Thu, 17 Jul 2003 18:03:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HM3S1j019660; Thu, 17 Jul 2003 18:03:28 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 18:03:28 -0400 (EDT) Resent-Message-Id: <200307172203.h6HM3S1j019660@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HM3REh019621 for ; Thu, 17 Jul 2003 18:03:27 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HM3Qvx028829 for ; Thu, 17 Jul 2003 18:03:26 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6HM3Lkh084576 for ; Thu, 17 Jul 2003 18:03:21 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HM3KhA101414 for ; Thu, 17 Jul 2003 18:03:20 -0400 In-Reply-To: To: "WebDAV" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 17 Jul 2003 18:03:28 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/17/2003 18:03:19, Serialize complete at 07/17/2003 18:03:19 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/OFB98EEFD3.57770D02-ON85256D66.0078D50C-85256D66.00792B22@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7738 X-Loop: 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. Note that my statement "it probably is worthwhile trying to define generic transactioning support for WebDAV" explicitly did not suggest that such an attempt would succeed (:-). In particular, I believe it is likely that such an attempt would fail for the reasons Julian describes. Cheers, Geoff "Julian Reschke" wrote on 07/17/2003 05:20:46 PM: > True, but... > > ...speaking from personal experience working on a document management > system, the temptation "give up" and just state "transactions are going to > solve this problem in general" is big. However, transactions can be very > expensive to implement, in particular in a HTTP server scenario. How many > concurrent transactions are you going to support? What are you going to do > if a client starts a transaction but doesn't finish it within a few minutes? > > IMHO it makes a lot of sense to try to *avoid* them by > > a) defining methods with the "right" level of transactionality (for > instance, see PROPPATCH or ORDERPATCH) or > > b) try to do things using the existing locking and/or versioning machinery. > > > So at a minimum, I'd expect a working group activity on transactions to > start with a list of use cases. Then we can take a look at the use cases and > decide whether they require a generic transaction mechanism, or whether > something simpler can do that as well (and please don't say: I want to do > JDBC over HTTP). > > > 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 Geoffrey M Clemm > > Sent: Thursday, July 17, 2003 11:02 PM > > To: WebDAV > > Subject: Re: Interest in standardizing Batch methods? > > > > > > > > If you are interested in defining a transactioning model, then > > it would be best to make that explicit, because the term "batch" > > is used to encompass many things. To date, the WebDAV approach has > > been to define specific transacted operations (e.g. PROPPATCH), > > because that is something that can be implemented on a wide range > > of repositories, while generic transactioning support is likely to > > only be feasible on repositories that are actually databases. > > > > But enough repositories really are databases that it probably is > > worthwhile trying to define generic transactioning support for > > WebDAV. > > > > Cheers, > > Geoff > > > > > > > > I am sure that you guys, who don't agree with standardising Batch > > > method, have good reasons for that. But shall we be more clear about > > > those reasons which might not quite clear for all. Of course I know > > > some of those reasons by chasing the thread with the same subject in > > > the WebDAV mailing list. But I think the WebDAV protocol is almost > > > enough mature to interest many organisations and Web users. So that > > > they would like to apply this protocol rather HTTP protocol, and use > > > the WebDAV advantages such as metadata, access control,... to author > > > Web resources. > > > > > > Now the question is: if the WebDAV is going to be a substitute for HTTP > > > protocol, can it handle authoring all kind of Web resources as it > > > claims, or still we need other conventions based on the HTTP protocol > > > in order to support authoring Web resources except file systems. > > > > > > So if you believe the WebDAV as a protocol for authoring all Web > > > resources (and not only the file systems), then how we can handle Web > > > resources such as emails and databases. In order to implement some > > > operations on those resources, you might use a sequence of WebDAV > > > methods which need to be considered as one transaction. In those cases > > > lock method cannot help. So what is your suggestion to handle those > > > operations? > > > > > > I think a mechanism for supporting transactions is a strong point that > > > WebDAV needs. > > > > > > > > > > > I agree with Chris. The easy things aren't worth doing (you get > > > > virtually > > > > all of the benefit by streaming your requests and not blocking > > > > waiting for > > > > the response to each request), and the hard things are very complex > > > > and > > > > any given approach is unlikely to be a good basis for > > > > interoperation. > > > > > > > > Cheers, > > > > Geoff > > > > > > > > Chris wrote on 07/17/2003 02:27:27 PM: > > > > > > > > > And boy, the semantics of batch requests are pretty hairy. At the > > > > end of > > > > > > > > > the day is there much benefit? Is each request in a batch atomic > > > > and/or > > > > > is the entire batch? (Do you have multiple levels of transactions?) > > > > How > > > > > do you cache a batch? (Boy, there's a long topic...) > > > > > > > > > > The HTTP overhead for multiple requests (made over the same TCP > > > > > connection, mind you) is small (arguably, couldn't be much smaller) > > > > and > > > > > if you want atomic batches, locks do an ok job of it. > > > > > > > > > > I've certainly considered something like a PUT/PROPPATCH > > > > combination > > > > > (for example if you had "required dead properties") but it's > > > > probably > > > > > just easier to do a null lock and the two requests separately. > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Jul 17 19:24: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 TAA26745 for ; Thu, 17 Jul 2003 19:24:44 -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 h6HNOlEh006646; Thu, 17 Jul 2003 19:24:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6HNMcfr006297; Thu, 17 Jul 2003 19:22:38 -0400 (EDT) Resent-Date: Thu, 17 Jul 2003 19:22:38 -0400 (EDT) Resent-Message-Id: <200307172322.h6HNMcfr006297@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6HNMbEh006264 for ; Thu, 17 Jul 2003 19:22:37 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HNMavx015225 for ; Thu, 17 Jul 2003 19:22:37 -0400 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6HM3b4B021003; Thu, 17 Jul 2003 15:03:38 -0700 (PDT) Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h6HM3Wl08548; Thu, 17 Jul 2003 16:03:32 -0600 (MDT) Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-134.us.oracle.com [130.35.170.134]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h6HM3Vl08533; Thu, 17 Jul 2003 16:03:31 -0600 (MDT) Message-ID: <01a601c34caf$3e82c090$86aa2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" , "Geoffrey M Clemm" , "WebDAV" References: Date: Thu, 17 Jul 2003 15:03:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Re: Interest in standardizing Batch methods? X-Archived-At: http://www.w3.org/mid/01a601c34caf$3e82c090$86aa2382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7739 X-Loop: 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 think something along the lines of what NFSv4 supports with the COMPOUND method would be in order. The big benefit of doing a COMPOUND/BATCH method is the atomicity. Note that the transaction you want to do may operate on multiple resources, and while LOCK will help, rolling back incomplete changes is a big pain in the ass for the client to do. Do you expect the client to implement a log file (like a database) which will be updated on each successful response, and then require that the client know how to apply undo from the log file in case of an error? Let's look at a use case: I want to PROPPATCH resources /a1, /a2 ... /a10 with the same dead property called foo to some new value either as a unit or not at all. With today's WebDAV, I LOCK all of these resources and start pipelining the PROPPATCH requests. As the replies come back in, I log them to a file on the client that is fsync'ed to the disk (so that I'm sure my logging makes it to disk in case the client crashes at some point, the way databases do). It turns out that there was an error in the PROPPATCH on /a8 (ACL violation) and I want to rollback all of the preceding proppatches in the client log. Now the client starts to replay the log (since the last transaction start), re-PROPPATCHing /a1 through /a7 hoping there is no other error, and then cleans up the log entries (or marks them as rolled back). Just in case this work sounds easy for client implementors to do, it's not. Plus, this strategy would only work if I happened to know the old values of the foo property so that I could undo them. PROPPATCH doesn't tell me what the old values were (you need the equivalent of the SQL statement "UPDATE foo RETURNING foo INTO :1") to do this. In general, undoing WebDAV operations is not easy and not always possible (e.g. some versioning operations). Given that NFSv4 could handle COMPOUND, I don't think that this is too hard or out of scope for WebDAV. Also, I believe that none of the publically announced NFSv4 implementations are built on databases, so I don't think this is too hard for server implementors in general, but we could make BATCH methods an optional feature to address this concern. As to Julian's particular concern about transactions started but not completed, the same solution should be applied as for any method in which part of the request has arrived but the rest has not after a few minutes--you timeout the entire request. --Eric ----- Original Message ----- From: "Julian Reschke" To: "Geoffrey M Clemm" ; "WebDAV" Sent: Thursday, July 17, 2003 2:20 PM Subject: RE: Interest in standardizing Batch methods? > > True, but... > > ...speaking from personal experience working on a document management > system, the temptation "give up" and just state "transactions are going to > solve this problem in general" is big. However, transactions can be very > expensive to implement, in particular in a HTTP server scenario. How many > concurrent transactions are you going to support? What are you going to do > if a client starts a transaction but doesn't finish it within a few minutes? > > IMHO it makes a lot of sense to try to *avoid* them by > > a) defining methods with the "right" level of transactionality (for > instance, see PROPPATCH or ORDERPATCH) or > > b) try to do things using the existing locking and/or versioning machinery. > > > So at a minimum, I'd expect a working group activity on transactions to > start with a list of use cases. Then we can take a look at the use cases and > decide whether they require a generic transaction mechanism, or whether > something simpler can do that as well (and please don't say: I want to do > JDBC over HTTP). > > > 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 Geoffrey M Clemm > > Sent: Thursday, July 17, 2003 11:02 PM > > To: WebDAV > > Subject: Re: Interest in standardizing Batch methods? > > > > > > > > If you are interested in defining a transactioning model, then > > it would be best to make that explicit, because the term "batch" > > is used to encompass many things. To date, the WebDAV approach has > > been to define specific transacted operations (e.g. PROPPATCH), > > because that is something that can be implemented on a wide range > > of repositories, while generic transactioning support is likely to > > only be feasible on repositories that are actually databases. > > > > But enough repositories really are databases that it probably is > > worthwhile trying to define generic transactioning support for > > WebDAV. > > > > Cheers, > > Geoff > > > > > > > > I am sure that you guys, who don't agree with standardising Batch > > > method, have good reasons for that. But shall we be more clear about > > > those reasons which might not quite clear for all. Of course I know > > > some of those reasons by chasing the thread with the same subject in > > > the WebDAV mailing list. But I think the WebDAV protocol is almost > > > enough mature to interest many organisations and Web users. So that > > > they would like to apply this protocol rather HTTP protocol, and use > > > the WebDAV advantages such as metadata, access control,... to author > > > Web resources. > > > > > > Now the question is: if the WebDAV is going to be a substitute for HTTP > > > protocol, can it handle authoring all kind of Web resources as it > > > claims, or still we need other conventions based on the HTTP protocol > > > in order to support authoring Web resources except file systems. > > > > > > So if you believe the WebDAV as a protocol for authoring all Web > > > resources (and not only the file systems), then how we can handle Web > > > resources such as emails and databases. In order to implement some > > > operations on those resources, you might use a sequence of WebDAV > > > methods which need to be considered as one transaction. In those cases > > > lock method cannot help. So what is your suggestion to handle those > > > operations? > > > > > > I think a mechanism for supporting transactions is a strong point that > > > WebDAV needs. > > > > > > > > > > > I agree with Chris. The easy things aren't worth doing (you get > > > > virtually > > > > all of the benefit by streaming your requests and not blocking > > > > waiting for > > > > the response to each request), and the hard things are very complex > > > > and > > > > any given approach is unlikely to be a good basis for > > > > interoperation. > > > > > > > > Cheers, > > > > Geoff > > > > > > > > Chris wrote on 07/17/2003 02:27:27 PM: > > > > > > > > > And boy, the semantics of batch requests are pretty hairy. At the > > > > end of > > > > > > > > > the day is there much benefit? Is each request in a batch atomic > > > > and/or > > > > > is the entire batch? (Do you have multiple levels of transactions?) > > > > How > > > > > do you cache a batch? (Boy, there's a long topic...) > > > > > > > > > > The HTTP overhead for multiple requests (made over the same TCP > > > > > connection, mind you) is small (arguably, couldn't be much smaller) > > > > and > > > > > if you want atomic batches, locks do an ok job of it. > > > > > > > > > > I've certainly considered something like a PUT/PROPPATCH > > > > combination > > > > > (for example if you had "required dead properties") but it's > > > > probably > > > > > just easier to do a null lock and the two requests separately. > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Jul 18 20:10: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 UAA18641 for ; Fri, 18 Jul 2003 20:10: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 h6J0AvEh008458; Fri, 18 Jul 2003 20:10:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6J0A1Of008329; Fri, 18 Jul 2003 20:10:01 -0400 (EDT) Resent-Date: Fri, 18 Jul 2003 20:10:01 -0400 (EDT) Resent-Message-Id: <200307190010.h6J0A1Of008329@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6J0A0Eh008257 for ; Fri, 18 Jul 2003 20:10:00 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6J09wvx025579 for ; Fri, 18 Jul 2003 20:09:59 -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 h6J09Gi12271 for ; Fri, 18 Jul 2003 17:09:17 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 18 Jul 2003 17:10:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010D_01C34D4F.7AA64CE0" 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 V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: [Moderator Action] VB6.0 vs. WebDav X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEIPIFAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7740 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_010D_01C34D4F.7AA64CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Kim H. Madsen [mailto:kmadsen@oppsol.com] Sent: Friday, July 18, 2003 1:54 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] VB6.0 vs. WebDav Hi I’m new to WebDav, I always used CDO and Outlook from VB6.0 to solve my problems but now I have a serious problem that I had been told that WebDav can solve for me, but I don’t know how to use WebDav from VB6.0. Do you know? Thank you, very much Best regards Kim Høst-Madsen ------=_NextPart_000_010D_01C34D4F.7AA64CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Kim H. Madsen=20 [mailto:kmadsen@oppsol.com]
Sent: Friday, July 18, 2003 1:54=20 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 VB6.0 vs. WebDav

Hi=20

 

I=92m new=20 to WebDav, I always used CDO and Outlook from VB6.0 to solve my problems = but now=20 I have a serious problem that I had been told that WebDav can solve for = me, but=20 I don=92t know how to use WebDav from = VB6.0.

 

Do you=20 know?

 

Thank=20 you, very much

 

Best=20 regards

 

Kim=20 H=F8st-Madsen

 

<= /DIV> ------=_NextPart_000_010D_01C34D4F.7AA64CE0-- From w3c-dist-auth-request@w3.org Sat Jul 19 12:02: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 MAA17345 for ; Sat, 19 Jul 2003 12:02:36 -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 h6JG2eEh018104; Sat, 19 Jul 2003 12:02:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6JG2QlF018086; Sat, 19 Jul 2003 12:02:26 -0400 (EDT) Resent-Date: Sat, 19 Jul 2003 12:02:26 -0400 (EDT) Resent-Message-Id: <200307191602.h6JG2QlF018086@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6JG2PEh018053 for ; Sat, 19 Jul 2003 12:02:25 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6JG2Pvx019219 for ; Sat, 19 Jul 2003 12:02:25 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6JG2J4X194034 for ; Sat, 19 Jul 2003 12:02:19 -0400 Received: from D01ML239.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 h6JG2E90022852 for ; Sat, 19 Jul 2003 12:02:19 -0400 In-Reply-To: <3F0F3909.5090109@nasa.gov> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: Geoffrey M Clemm Message-ID: Date: Sat, 19 Jul 2003 12:02:06 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 07/19/2003 12:02:19, Serialize complete at 07/19/2003 12:02:19 Content-Type: multipart/alternative; boundary="=_alternative 0053EA6485256D68_=" Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OF9CDA3961.0826FBC8-ON85256D68.005139C9-85256D68.005814BC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7741 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 0053EA6485256D68_= Content-Type: text/plain; charset="US-ASCII" How about the following alternative: For PROPFIND, define a new 2xx status code that means "resource already reported". A server that detects a loop in a PROPFIND result, would use this new 2xx status code for the 2'nd (and subsequent) encounters with a given resource. This allows the client to reconstruct the binding structure based on just a single PROPFIND call. In particular, we could add the following paragraph to the Binding specification: ----------------------------- 7.1 208 Already Reported The 208 (Already Reported) status code can be used inside a DAV:propstat response element to indicate that information about the resource has already been reported in a previous DAV:propstat element in that response. The members of the 208 status resource are omitted from the response. For example, consider a PROPFIND request on /Coll (bound to collection C), where the members of /Coll are /Coll/Foo (bound to resource R) and /Coll/Bar (bound to collection C). >> Request: PROPFIND /Coll/ HTTP/1.1 Host: www.example.com Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxx >> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx http://www.example.com/Coll/ Loop Demo HTTP/1.1 200 OK http://www.example.com/Coll/Foo Bird Inventory HTTP/1.1 200 OK http://www.example.com/Coll/Bar Loop Demo HTTP/1.1 208 Already Reported A client can request the DAV:resourceid property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource. ------------------------------------- Cheers, Geoff Chris wrote on 07/11/2003 06:24:09 PM: > > Julian Reschke wrote: > > >>First/easiest thing would be to change the example to have the 506 > >>followed by a 200. (The example implied to me that processing stopped at > >>the first 506.) > >> > >> > > > >That would break the multistatus format - every URI may only appear once. > > > >What we should do is clarify that the processing only stops *for the > >resource that is part of the bind loop*. So maybe just change the example to > >have the "looping child" appear first in the collection. > > > > > Sorry for being unclear, that's what I meant (having a different URI in > the 200 after the 506.) > > >Maybe, maybe not. So which clients *do* require PROPFIND/depth:infinity? The > >Microsoft webfolder client doesn't. > > > > > You're right, no client requires it and could do the same by recursively > PROPFINDing down the tree. > > Are you going to make it to the Interop? Hope to see you there! (We > might even have a first pass at a BIND-capable server. :*) > --=_alternative 0053EA6485256D68_= Content-Type: text/html; charset="US-ASCII"
How about the following alternative:

For PROPFIND, define a new 2xx status code that means "resource already reported".

A server that detects a loop in a PROPFIND result, would use this new 2xx status
code for the 2'nd (and subsequent) encounters with a given resource.  This allows
the client to reconstruct the binding structure based on just a single PROPFIND
call.

In particular, we could add the following paragraph to the Binding specification:

-----------------------------

7.1   208 Already Reported
The 208 (Already Reported) status code can be used inside a DAV:propstat
response element to indicate that information about the resource has
already been reported in a previous DAV:propstat element in that response.
The members of the 208 status resource are omitted from the response.  
For example, consider a PROPFIND request on /Coll (bound to collection C),
where the members of  /Coll are /Coll/Foo (bound to resource R)
and /Coll/Bar (bound to collection C).

>> Request:

PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop> <D:displayname/> </D:prop>
</D:propfind>

>> Response:

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

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
   <D:response>
      <D:href>http://www.example.com/Coll/</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Loop Demo</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.example.com/Coll/Foo</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Bird Inventory</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.example.com/Coll/Bar</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Loop Demo</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 208 Already Reported</D:status>
      </D:propstat>
   </D:response>
</D:multistatus>

A client can request the DAV:resourceid property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource.
-------------------------------------

Cheers,
Geoff

Chris wrote on 07/11/2003 06:24:09 PM:
>
> Julian Reschke wrote:
>
> >>First/easiest thing would be to change the example to have the 506
> >>followed by a 200. (The example implied to me that processing stopped at
> >>the first 506.)
> >>    
> >>
> >
> >That would break the multistatus format - every URI may only appear once.
> >
> >What we should do is clarify that the processing only stops *for the
> >resource that is part of the bind loop*. So maybe just change the example to
> >have the "looping child" appear first in the collection.
> >  
> >
> Sorry for being unclear, that's what I meant (having a different URI in
> the 200 after the 506.)
>
> >Maybe, maybe not. So which clients *do* require PROPFIND/depth:infinity? The
> >Microsoft webfolder client doesn't.
> >  
> >
> You're right, no client requires it and could do the same by recursively
> PROPFINDing down the tree.
>
> Are you going to make it to the Interop? Hope to see you there! (We
> might even have a first pass at a BIND-capable server. :*)
>
--=_alternative 0053EA6485256D68_=-- From w3c-dist-auth-request@w3.org Sun Jul 20 12:18: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 MAA22153 for ; Sun, 20 Jul 2003 12:18:45 -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 h6KGIlEh024261; Sun, 20 Jul 2003 12:18:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6KGIINg024155; Sun, 20 Jul 2003 12:18:18 -0400 (EDT) Resent-Date: Sun, 20 Jul 2003 12:18:18 -0400 (EDT) Resent-Message-Id: <200307201618.h6KGIINg024155@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6KGIGEh024118 for ; Sun, 20 Jul 2003 12:18:16 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6KGIFvx032458 for ; Sun, 20 Jul 2003 12:18:15 -0400 Received: (qmail 1802 invoked by uid 65534); 20 Jul 2003 16:18:07 -0000 Received: from pD950C3A0.dip.t-dialin.net (HELO lisa) (217.80.195.160) by mail.gmx.net (mp013) with SMTP; 20 Jul 2003 18:18:07 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Sun, 20 Jul 2003 18:18:01 +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.1165 In-Reply-To: Importance: Normal Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEJBHOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7742 X-Loop: 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 Geoffrey M Clemm > Sent: Saturday, July 19, 2003 6:02 PM > To: w3c-dist-auth@w3.org > Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > > How about the following alternative: > > For PROPFIND, define a new 2xx status code that means "resource already > reported". > > A server that detects a loop in a PROPFIND result, would use this new 2xx > status > code for the 2'nd (and subsequent) encounters with a given resource. This > allows > the client to reconstruct the binding structure based on just a single > PROPFIND > call. > > In particular, we could add the following paragraph to the Binding > specification: > > ----------------------------- > > 7.1 208 Already Reported > The 208 (Already Reported) status code can be used inside a DAV:propstat > response element to indicate that information about the resource has > already been reported in a previous DAV:propstat element in that response. > The members of the 208 status resource are omitted from the response. > For example, consider a PROPFIND request on /Coll (bound to collection C), > where the members of /Coll are /Coll/Foo (bound to resource R) > and /Coll/Bar (bound to collection C). > > >> Request: > > PROPFIND /Coll/ HTTP/1.1 > Host: www.example.com > Depth: infinity > Content-Type: text/xml; charset="utf-8" > Content-Length: xxx > > > > > > > >> Response: > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml; charset="utf-8" > Content-Length: xxx > > > > > http://www.example.com/Coll/ > > > Loop Demo > > HTTP/1.1 200 OK > > > > http://www.example.com/Coll/Foo > > > Bird Inventory > > HTTP/1.1 200 OK > > > > http://www.example.com/Coll/Bar > > > Loop Demo > > HTTP/1.1 208 Already Reported > > > > > A client can request the DAV:resourceid property in a PROPFIND request to > guarantee that they can accurately reconstruct the binding structure of a > collection with multiple bindings to a single resource. > ------------------------------------- > > Cheers, > Geoff OK, this issue has been coming up several times (see for the last time). 1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as result of operations other than PROPFIND, for instance COPY. 2) What error condition do we need to really indicate for the documented example (PROPFIND depth infinity)? The problem is not with the resource itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't indicate any special condition at all. The problem occurs *only* because there's a bind loop, yet the request asked for a depth: infinity resource listing. So there's not a specific resource that can be "blamed" -- instead, it's the traversal of the collection's children that can't be done, and for which optimally the response should indicate failure. 3) A similar problem exists with PROPFINDing deph != 0 on collections when access privileges forbid listing the members. 4) Will clients that aren't aware of the ordering protocol ignore resources with a status of 208? Not necessarily -- there may be clients that accept all 2xx status codes as success (and I think those a stricly conforming to RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if we do use it, we can simply use the approach outlined in . I'm not convinced that a new 2xx status code is a good idea -- one approach that's much more simpler would be just to forbid depth:infinity PROPFINDs on collections that contain bind loops and to define an according precondition value. If we *do* want a new 2xx code, I'd rephrase the status condition. As a matter of fact, the issue is *not* that the resource already was reported! In fact, having multiple bindings to the same resource within the same PROPFIND result is just fine. So, I'd propose: "208 OK, but children not listed" We could then extend the response body to indicate *why* children haven't been traversed: DAV:no-bind-loop (recursing below this collection would result in a loop) DAV:need-privileges (you are allowed to see this collection, but not it's content) (see for a proposal how to marshall that). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jul 22 11:33: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 LAA17557 for ; Tue, 22 Jul 2003 11:33: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 h6MFXlEh010289; Tue, 22 Jul 2003 11:33:47 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6MFVuDN009957; Tue, 22 Jul 2003 11:31:56 -0400 (EDT) Resent-Date: Tue, 22 Jul 2003 11:31:56 -0400 (EDT) Resent-Message-Id: <200307221531.h6MFVuDN009957@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6MFVtEh009924 for ; Tue, 22 Jul 2003 11:31:55 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MFVsvx017466 for ; Tue, 22 Jul 2003 11:31:54 -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 h6MFUBX28560 for ; Tue, 22 Jul 2003 08:30:12 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 22 Jul 2003 08:31:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C3502B.AB8FA700" 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 V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: XP and WebDAV X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEHMIGAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7743 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C3502B.AB8FA700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit XP and WebDAVAccidentally caught by the spam filter. - Jim -----Original Message----- From: Paul Hermans [mailto:paul_hermans@protext.be] Sent: Tuesday, July 22, 2003 4:29 AM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] XP and WebDAV Recently switched from a Win 2000 to Windows XP platform. Browsing Webfolders however did become extremely slow under XP. Anyone knowing what the reason could be ? Regards, Paul Paul Hermans Pro Text www.protext.be phermans@protext.be ------=_NextPart_000_00D7_01C3502B.AB8FA700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable XP and WebDAV
Accidentally caught by the spam filter.
 
-=20 Jim
-----Original Message-----
From: Paul Hermans=20 [mailto:paul_hermans@protext.be]
Sent: Tuesday, July 22, 2003 = 4:29=20 AM
To: 'w3c-dist-auth@w3.org'
Subject: [Moderator = Action] XP=20 and WebDAV

Recently switched from a Win 2000 to = Windows XP=20 platform.
Browsing Webfolders = however did=20 become extremely slow under XP.

Anyone knowing what the reason could be = ?=20


Regards,

Paul
Paul=20 Hermans
Pro Text
www.protext.be
phermans@protext.be

------=_NextPart_000_00D7_01C3502B.AB8FA700-- From w3c-dist-auth-request@w3.org Thu Jul 24 00:47: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 AAA13088 for ; Thu, 24 Jul 2003 00:47: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 h6O4lNEh017502; Thu, 24 Jul 2003 00:47:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6O4l3uL017478; Thu, 24 Jul 2003 00:47:03 -0400 (EDT) Resent-Date: Thu, 24 Jul 2003 00:47:03 -0400 (EDT) Resent-Message-Id: <200307240447.h6O4l3uL017478@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6O4l1Eh017441 for ; Thu, 24 Jul 2003 00:47:02 -0400 (EDT) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O4l1vx014491 for ; Thu, 24 Jul 2003 00:47:01 -0400 Received: from Tycho (dsl3-63-249-68-18.cruzio.com [63.249.68.18]) by mail.cruzio.com with SMTP id h6O4l0Gq093071 for ; Wed, 23 Jul 2003 21:47:00 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 23 Jul 2003 21:47:51 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: FW: WebDav X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEOHIGAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7744 X-Loop: 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 Accidentally caught by the spam filter. - Jim -----Original Message----- From: J.R. Hermosillo [mailto:deactivator2000@yahoo.com] Sent: Tuesday, July 22, 2003 10:00 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDav Hello, I saw your web page and I had some questions about Webdav, I was wondering how if I could put it on my web server and how or is it a protocol that the server already uses and I just have to enable some extensions on it. In any case since you seem pretty savvy on web folders I was trying to do like an ftp site on my IIS server but it seems that web folders are a lot more secure and easy to manage, if you have any input let me know, Thanks, J.R. From w3c-dist-auth-request@w3.org Fri Jul 25 05:09: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 FAA29651 for ; Fri, 25 Jul 2003 05: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 h6P991Eh027234; Fri, 25 Jul 2003 05:09:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6P98cfc027167; Fri, 25 Jul 2003 05:08:38 -0400 (EDT) Resent-Date: Fri, 25 Jul 2003 05:08:38 -0400 (EDT) Resent-Message-Id: <200307250908.h6P98cfc027167@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6P98bEh027134 for ; Fri, 25 Jul 2003 05:08:37 -0400 (EDT) Received: from masblrexc02.mascotsystems.com ([202.151.157.115]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6P98Yvx018395 for ; Fri, 25 Jul 2003 05:08:36 -0400 Received: by masblrexc02.mascotsystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jul 2003 14:37:17 +0530 Message-ID: <5575473D4532D411BE4C009027E8C8380B2F5320@masblrexc02.mascotsystems.com> From: Arun Panda To: w3c-dist-auth@w3.org Date: Fri, 25 Jul 2003 14:37:08 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: Performance tool X-Archived-At: http://www.w3.org/mid/5575473D4532D411BE4C009027E8C8380B2F5320@masblrexc02.mascotsystems.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7745 X-Loop: 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: Does anyone have any idea of a tool to check the performance of Exchange server? I want to check the performance of the exchange server when I'm polling it for the mails and calendar events from my cadaver client. Info in this regard would be greatly appreciated Regards Arun Panda From w3c-dist-auth-request@w3.org Fri Jul 25 06:00: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 GAA00519 for ; Fri, 25 Jul 2003 06:00:11 -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 h6PA0EEh006683; Fri, 25 Jul 2003 06:00:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6PA07JL006364; Fri, 25 Jul 2003 06:00:07 -0400 (EDT) Resent-Date: Fri, 25 Jul 2003 06:00:07 -0400 (EDT) Resent-Message-Id: <200307251000.h6PA07JL006364@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6PA03Ej006117 for ; Fri, 25 Jul 2003 06:00:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6P9uEvx030468 for ; Fri, 25 Jul 2003 05:56:14 -0400 Received: (qmail 12785 invoked by uid 65534); 25 Jul 2003 09:56:08 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007) with SMTP; 25 Jul 2003 11:56:08 +0200 From: "Julian Reschke" To: Date: Fri, 25 Jul 2003 11:56: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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: redirect ref spec revived X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEHDHPAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7746 X-Loop: 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, I just started reviving the old expired redirect references draft. Based on (expired June 2000) and the last call issues list I started a new revision which is currently at (basically it includes all open issues in-text, and those issues that were trivial to resolve have been closed). The current version was also submitted to the IETF as draft -03. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jul 25 15:29:14 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 PAA18005 for ; Fri, 25 Jul 2003 15:29:13 -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 h6PJTEEh011235; Fri, 25 Jul 2003 15:29:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6PJT2R8011215; Fri, 25 Jul 2003 15:29:02 -0400 (EDT) Resent-Date: Fri, 25 Jul 2003 15:29:02 -0400 (EDT) Resent-Message-Id: <200307251929.h6PJT2R8011215@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6PJT1Eh011182 for ; Fri, 25 Jul 2003 15:29:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6PJT0vx010764 for ; Fri, 25 Jul 2003 15:29:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17986; Fri, 25 Jul 2003 15:28:55 -0400 (EDT) Message-Id: <200307251928.PAA17986@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 25 Jul 2003 15:28:55 -0400 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-03.txt X-Archived-At: http://www.w3.org/mid/200307251928.PAA17986@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7747 X-Loop: 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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Redirect Reference Resources Author(s) : J. Slein et al. Filename : draft-ietf-webdav-redirectref-protocol-03.txt Pages : 78 Date : 2003-7-25 This is one of a pair of specifications that extend the WebDAV Distributed Authoring Protocol to enable clients to create new access paths to existing resources. The two protocol extensions have very different characteristics that make them useful for different sorts of applications. The present specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 302 (Found) status code, redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. The related specification [B], defines bindings, and the BIND method for creating them. Creating a new binding to a resource indirectly creates one or more new URIs mapped to that resource, which can then be used to access it. Servers are required to insure the integrity of any bindings that they allow to be created. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org [1], which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org [2]. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-redirectref-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-25152259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152259.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Jul 30 09:18: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 JAA29794 for ; Wed, 30 Jul 2003 09:18: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 h6UDIWEh020944; Wed, 30 Jul 2003 09:18:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UDIAXs020873; Wed, 30 Jul 2003 09:18:10 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 09:18:10 -0400 (EDT) Resent-Message-Id: <200307301318.h6UDIAXs020873@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UDI7Eh020825 for ; Wed, 30 Jul 2003 09:18:07 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UDI6vx012743 for ; Wed, 30 Jul 2003 09:18:06 -0400 Received: (qmail 2730 invoked by uid 65534); 30 Jul 2003 13:18:00 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009) with SMTP; 30 Jul 2003 15:18:00 +0200 From: "Julian Reschke" To: Date: Wed, 30 Jul 2003 15:17:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Subject: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDIIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7748 X-Loop: 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: 8bit Hi. Below is a list of issues I raised against draft 03 which IMHO have not been adequately addressed in the latest draft (see [1] for the original message). 03-C02 4.4: “…or when they may be shown to a human user and hence require encoding in…” I’m not sure what the requirement “may be shown to a human user” is supposed to mean here. Proposal: just write: “…or when they require encoding in…” 03-C03 4.4: “Note that the use of a new top-level URI identifier as a namespace is considered by many to be a bad thing…” [as of draft 04 this now reads: "Note that ”DAV:“ is a top-level URI identifier that was defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of top-level URI identifiers is difficult. "DAV:" was defined as the WebDAV namespace before standard best practices emerged, and this namespace is kept and still used because of significant existing deployments, but this should not be emulated. "] Rewrite as: “Note that both defining a new URI scheme just for the purpose of identifying protocol elements, and using just the scheme name as a namespace name is to be considered a bad practice, and should not be copied”. 03-C05 4.5: “The value of a property appears inside the property name element. The value may be any text, including valid XML. When the value is structured as XML, namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML.” 1) I think this needs to rephrased to use proper XML terminology, also 2) I think that namespace prefixes within the property value do need to be round.tripped. Proposal: “The value of a property appears inside the property name element and may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespaces and namespace prefixes that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later.” [Issue 2 still needs to be resolved, the current text says: "Namespace prefixes need not be preserved due to the rules of prefix declaration in XML."] 03-C12: 8.1.1.: “Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML].” Add “…and [REC-XMLNS]”. We also need allow servers and clients to rejects a certain set of request/response that are indeed well-formed, in particular: - when it exceeds some predefined size or - when expansion of internal entities may cause a denial of service. [the last issue still needs to be adressed] 03-C14: 8.1.3: “When the Location header is used in a response, it is used by the server to indicate the preferred address for the target resource of the request. Whenever the server has a preferred address, it should use that address consistently. This means that when a response contains a Location header, all the URLs in the response body (e.g. a Multi-Status) should be consistent.” If we keep this paragraph, we’ll have to define what “consistent” means here. 03-C16: 8.1.5: “If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property.” Note that this breaks the “etag promotion” strategy used both by IIS and Moddav (PUT usually returns weak etags which later are promoted to strong etags when there was no other change to that resource within a specific time window). Therefore I’d make that a SHOULD (at least for PUT). 03-C17: 8.1.5.: “Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server MUST not change the ETag (or getlastmodified value) for a resource when only its property values change.” Some servers do, and I don’t think we can change that. Therefore I think this change at least needs explicit consensus on the mailing list. 03-C19: General comment re: 8.1.6: I really like that change (actually, I like it so much that I’d like to have condition names for all frequently signalled problems….). However, if it uses the same format as RFC3253, it should be consistent with it. In particular, the names should identify conditions that must be met. For instance, use “allow-external-entities” rather than “forbid-internal-entities”. We may also want to note that one DAV:error element can hold multiple elements identifying failed conditions. 03-C21: 8.2.: “Note that ‘allprop’ does not return values for all properties.” Change to: “Note that ‘allprop’ does not return values for all live properties.” 03-C22: 8.2: “URLs for collections appearing in the results MUST end in a slash character.” I don’t think we have consensus for this being a MUST. 03-C24: 8.2.2: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.” Change to: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all non-prefixed enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.” (Actually I’d rather prefer to get rid of this. RFC2518bis shouldn’t try to give XML lessons). 03-C29: 9.1 (DAV header) allows coded URLs in the DAV header. I’d like to see the rationale for that. 03-C30: 9.4 (force-authenticate): is this the consensus we reached in January? Ilyas, did you take notes? 03-C31: 9.5 defines “” as a new special state token. I think this is unneeded – any URI which is known not to identify a lock MUST work as well, so we can simply recommend using something like “” (which is something that RFC2518-compliant servers already support). [This text changed, but it now makes "DAV:no-lock" a special feature of the grammar. This is not necessary. Just state that DAV:no-lock by definition never identifies a valid lock (because the WebDAV WG says so :-)] 03-C32: (old text) The example in 9.5.2 uses an invalid lock token (the URI scheme “locktoken” isn’t IETF-registered, so it can’t claim conformance to the uniqueness requirements). Just use a sample token using the “opaquelocktoken” scheme instead). [this now uses the right scheme, but an illegal token value] 03-C34: Section 13: XML element definitions I don’t like the syntax change in the DTDs. For instance, activelock now is defined as: ANY value: Any number of elements, including one of each of (lockscope, locktype, depth, owner, timeout, locktoken, lockroot) It used to be: For consistency with RFC2518, RFC3253 and the ACL spec we really should stay with the old notation. 03-C36: Section 17: “Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties.” We may want to add a new category (condition names). [This has been done, but it still says "three" -- remember the Spanish Inquisition Sketch?] Editorial notes: 03-E01 Expiry date is wrong. 03-E04 There are many places where example URLs do not use the set of example host names allowed by the IETF. [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 10:01:50 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 KAA01307 for ; Wed, 30 Jul 2003 10:01:48 -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 h6UE1mEh027369; Wed, 30 Jul 2003 10:01:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UE1kfN027321; Wed, 30 Jul 2003 10:01:46 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 10:01:46 -0400 (EDT) Resent-Message-Id: <200307301401.h6UE1kfN027321@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UE1QG3026440 for ; Wed, 30 Jul 2003 10:01:41 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UDgqvx020301 for ; Wed, 30 Jul 2003 09:42:52 -0400 Received: (qmail 30195 invoked by uid 65534); 30 Jul 2003 13:42:46 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012) with SMTP; 30 Jul 2003 15:42:46 +0200 From: "Julian Reschke" To: Date: Wed, 30 Jul 2003 15:42: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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: rfc2518-bis-04 issues (part 2) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDKIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7749 X-Loop: 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. Below is a list of issues I raised against draft 02 which IMHO have not been adequately addressed in the latest draft (see [1] for the original message). 02-C05 Section 6.3, p3 Replace "However resources are free to return any URI scheme so long as it meets the uniqueness requirements." by "However servers are free to use any IETF-registered URI scheme so long as it meets the uniqueness requirements." (If it's not IETF-registered, I don't see how it can possibly meet the uniqueness criterium). C02-10) Section 8.2.2 (...) Also: the example for propfind/allprop is missing. C02-14) Section 8.11, The Effect of Locks on Properties and Collections "This means that if a collection is locked, its lock-token is required in all these cases: - DELETE a collection's direct internal member - MOVE a member out of the collection - MOVE a member into the collection, unless it overwrites a pre-existing member" I think the latter is not really consistent with RFC3253. [In general I'd like to have the latest GULP as normative appendix, and remove some of the prose about lock behaviour from the various sections; I think this is also we agreed upon in January] C02-18) Section 9.1 I'd like to see the rational for the "extend" production. C02-24) Section 12.1 Proposal: add an example. C02-26) Section 13.6 Replace: "Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value" by "Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST contain this element." C02-30) Section 14.7 "A change in a property SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body." I think this is a new requirement that hasn't been discussed. BTW: it's inconsistent with the attempt to make ETags a MUST -- if you have Etags, you don't have to rely on the last modified date anyway. E02-01) Editorial note I think that removing the section numbers from the 3rd-level section names is a bad idea. [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 12:21: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 MAA06945 for ; Wed, 30 Jul 2003 12:21: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 h6UGLOEh026775; Wed, 30 Jul 2003 12:21:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UGLCEI026643; Wed, 30 Jul 2003 12:21:12 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 12:21:12 -0400 (EDT) Resent-Message-Id: <200307301621.h6UGLCEI026643@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UGLBEh026610 for ; Wed, 30 Jul 2003 12:21:11 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UGL9vx006794 for ; Wed, 30 Jul 2003 12:21:10 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA00322 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 30 Jul 2003 09:21:09 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA32765 sender obsfucated@us.ibm.com; Wed, 30 Jul 2003 09:21:07 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UGKXpW145964; Wed, 30 Jul 2003 12:20:33 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UGKVbt027850; Wed, 30 Jul 2003 12:20:31 -0400 To: "Julian Reschke" 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: Wed, 30 Jul 2003 12:20:23 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/30/2003 12:20:31, Serialize complete at 07/30/2003 12:20:31 Content-Type: multipart/alternative; boundary="=_alternative 0058F9E285256D73_=" Subject: Re: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/OF14B60618.EFDE9723-ON85256D73.0056E92C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7750 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 0058F9E285256D73_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't have the spec handy, so I can only comment on the items that=20 include enough comment... > 03-C03 >=20 > 4.4: "Note that the use of a new top-level URI identifier as a namespace = is > considered by many to be a bad thing?" >=20 > [as of draft 04 this now reads: "Note that "DAV:" is a top-level URI > identifier that was defined > solely to provide a namespace for WebDAV XML elements and property > names. This practice is discouraged in part because registration of > top-level URI identifiers is difficult. "DAV:" was defined as the > WebDAV namespace before standard best practices emerged, and this > namespace is kept and still used because of significant existing > deployments, but this should not be emulated. "] >=20 > Rewrite as: >=20 > "Note that both defining a new URI scheme just for the purpose of > identifying protocol elements, and using just the scheme name as a=20 namespace > name is to be considered a bad practice, and should not be copied". >=20 The previous text seems clearer. I'd not rewrite this. > 03-C05 >=20 > 4.5: "The value of a property appears inside the property name element.=20 The > value may be any text, including valid XML. When the value is=20 structured > as XML, namespaces that are in scope for that part of the XML document > apply within the property value as well, and MUST be preserved in=20 server > storage for retransmission later. Namespace prefixes need not be=20 preserved > due to the rules of prefix declaration in XML." >=20 > 1) I think this needs to rephrased to use proper XML terminology,=20 also > 2) I think that namespace prefixes within the property value do need=20 to=20 > be > round.tripped. >=20 > Proposal: >=20 > "The value of a property appears inside the property name element and=20 may be > any kind of well-formed XML content, including both text-only and mixed > content. When the property value contains further XML elements,=20 namespaces > and namespace prefixes that are in scope for that part of the XML=20 document > apply within the property value as well, and MUST be preserved in server > storage for retransmission later." >=20 > [Issue 2 still needs to be resolved, the current text says: "Namespace > prefixes need not be preserved due to the rules of prefix declaration in > XML."] I have no opinion on prefix preservation.=20 > 03-C12: >=20 > 8.1.1.: "Some of the following new HTTP methods use XML as a request and > response format. All DAV compliant clients and resources MUST use XML > parsers that are compliant with [REC-XML]." >=20 > Add "?and [REC-XMLNS]". >=20 > We also need allow servers and clients to rejects a certain set of > request/response that are indeed well-formed, in particular: >=20 > - when it exceeds some predefined size or Sounds fine, but it's just one of several reasons to reject a request. If possible, I'd like to declare these as out of scope as long as we're clear how the server should respond to problems of this class. Is it clear how server writers should respond to problematic situations that we don't explicitly mention? > 03-C17: >=20 > 8.1.5.: "Because clients may be forced to prompt users or throw away=20 changed > content if the ETag changes, a WebDAV server MUST not change the ETag=20 (or > getlastmodified value) for a resource when only its property values=20 change." >=20 > Some servers do, and I don't think we can change that. Therefore I think > this change at least needs explicit consensus on the mailing list. I vote for the wording that is in there. I think we've already reached=20 consensus that changing property values should not be changing etags. > 03-C21: >=20 > 8.2.: "Note that 'allprop' does not return values for all properties." >=20 > Change to: >=20 > "Note that 'allprop' does not return values for all live properties." All dead properties must be returned? I didn't pick that up in our=20 discussions. =20 --=_alternative 0058F9E285256D73_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't have the spec handy, so I ca= n only comment on the items that include
enough comment...

> 03-C03
>
> 4.4: "Note that the use of a new top-level URI identifier as a namespa= ce is
> considered by many to be a bad thing…"
>
> [as of draft 04 this now reads: "Note that "DAV:" is a top-level = URI
> identifier that was defined
>    solely to provide a namespace for WebDAV XML elements and= property
>    names.  This practice is discouraged in part because= registration of
>    top-level URI identifiers is difficult. "DAV:" = was defined as the
>    WebDAV namespace before standard best practices emerged, = and this
>    namespace is kept and still used because of significant e= xisting
>    deployments, but this should not be emulated. "]
>
> Rewrite as:
>
> "Note that both defining a new URI scheme just for the purpose of
> identifying protocol elements, and using just the scheme name as a nam= espace
> name is to be considered a bad practice, and should not be copied".
>

The previous text seems clearer. &nb= sp;I'd not rewrite this.


> 03-C05
>
> 4.5: "The value of a property appears inside the property name element= .  The
> value may be any text, including valid XML.  When the value is &n= bsp;structured
> as XML, namespaces that are in scope for that part of the  XML do= cument
> apply within the property value as well, and MUST be  preserved i= n server
> storage for retransmission later. Namespace prefixes need not be prese= rved
> due to the rules of prefix declaration in XML."
>
> 1)        I think this needs to rephrased to use p= roper XML terminology, also
> 2)        I think that namespace prefixes within t= he property value do need to
> be
> round.tripped.
>
> Proposal:
>
> "The value of a property appears inside the property name element and = may be
> any kind of well-formed XML content, including both text-only and mixe= d
> content. When the property value contains further XML elements, namesp= aces
> and namespace prefixes that are in scope for that part of the XML docu= ment
> apply within the property value as well, and MUST be preserved in serv= er
> storage for retransmission later."
>
> [Issue 2 still needs to be resolved, the current text says: "Name= space
> prefixes need not be preserved due to the rules of prefix declaration = in
> XML."]

I have no opinion on prefix preserva= tion.  


> 03-C12:
>
> 8.1.1.: "Some of the following new HTTP methods use XML as a request a= nd
> response format.  All DAV compliant clients and resources MUST us= e  XML
> parsers that are compliant with [REC-XML]."
>
> Add "…and [REC-XMLNS]".
>
> We also need allow servers and clients to rejects a certain set of
> request/response that are indeed well-formed, in particular:
>
> -        when it exceeds some predefined size or
Sounds fine, but it's just one of se= veral reasons to reject
a request.  If possible, I'd li= ke to declare these as out of
scope as long as we're clear how the= server should respond
to problems of this class.  Is = it clear how server writers
should respond to problematic situat= ions that we don't
explicitly mention?



> 03-C17:
>
> 8.1.5.: "Because clients may be forced to prompt users or throw away c= hanged
> content if the ETag changes, a WebDAV server MUST not change the  = ;ETag (or
> getlastmodified value) for a resource when only its property values ch= ange."
>
> Some servers do, and I don't think we can change that. Therefore I thi= nk
> this change at least needs explicit consensus on the mailing list.

I vote for the wording that is in th= ere.  I think we've already reached consensus
that changing property values should= not be changing etags.


> 03-C21:
>
> 8.2.: "Note that 'allprop' does not return values for all properties."=
>
> Change to:
>
> "Note that 'allprop' does not return values for all live properties."<= /font>

All dead properties must be returned= ?  I didn't pick that up in our discussions.


--=_alternative 0058F9E285256D73_=-- From w3c-dist-auth-request@w3.org Wed Jul 30 12:36: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 MAA07500 for ; Wed, 30 Jul 2003 12:36: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 h6UGaPEh001869; Wed, 30 Jul 2003 12:36:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UGaOPu001825; Wed, 30 Jul 2003 12:36:24 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 12:36:24 -0400 (EDT) Resent-Message-Id: <200307301636.h6UGaOPu001825@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UGaNEh001792 for ; Wed, 30 Jul 2003 12:36:23 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UGaMvx012313 for ; Wed, 30 Jul 2003 12:36:22 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA01066 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 30 Jul 2003 09:36:22 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA01041 sender obsfucated@us.ibm.com; Wed, 30 Jul 2003 09:36:20 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UGZnPS108866; Wed, 30 Jul 2003 12:35:49 -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 h6UGZmJr120202; Wed, 30 Jul 2003 12:35:48 -0400 To: "Julian Reschke" 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: Wed, 30 Jul 2003 12:35:40 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/30/2003 12:35:48, Serialize complete at 07/30/2003 12:35:48 Content-Type: multipart/alternative; boundary="=_alternative 005A972685256D73_=" Subject: RE: rfc2518-bis-04 issues (part 2) X-Archived-At: http://www.w3.org/mid/OFC92BA1BE.06FAE70A-ON85256D73.00590F8B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7751 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 005A972685256D73_= Content-Type: text/plain; charset="us-ascii" On Wednesday, 07/30/2003 at 03:42 ZE2, "Julian Reschke" wrote: > Hi. > > Below is a list of issues I raised against draft 02 which IMHO have not been > adequately addressed in the latest draft (see [1] for the original message). > > > 02-C05 Section 6.3, p3 > > Replace > > "However resources are free to return any URI scheme so long as it meets the > uniqueness requirements." > > by > > "However servers are free to use any IETF-registered URI scheme so long as > it meets the uniqueness requirements." > > (If it's not IETF-registered, I don't see how it can possibly meet the > uniqueness criterium). I'd vote to leave the text as it is. > C02-14) Section 8.11, The Effect of Locks on Properties and Collections > > "This means that if a collection is locked, its lock-token is required in > all these cases: > - DELETE a collection's direct internal member > - MOVE a member out of the collection > - MOVE a member into the collection, unless it overwrites a pre-existing > member" > > I think the latter is not really consistent with RFC3253. Perhaps I misunderstand the existing text, but I also suspect the "unless it overwrites..." part is wrong. If you do a MOVE and it's actually a different resource in that slot, I think you do need the parent collection's lock token. It's only a PUT that doesn't require it. > C02-30) Section 14.7 > > "A change in a property SHOULD NOT cause the last-modified date to change, > because clients MAY rely on the last-modified date to know when to overwrite > the existing body." > > I think this is a new requirement that hasn't been discussed. BTW: it's > inconsistent with the attempt to make ETags a MUST -- if you have Etags, you > don't have to rely on the last modified date anyway. I don't know if we discussed it or not, but the wording that is there seems fine. I do lack any compelling test cases to drive this issue in a particular direction though. I will rhetorically ask what non-WebDAV browsers do with ETags and lastmoddate. --=_alternative 005A972685256D73_= Content-Type: text/html; charset="us-ascii"
On Wednesday, 07/30/2003 at 03:42 ZE2, "Julian Reschke" <nnjulian.reschke___at___gmx.de@smallcue.com> wrote:
> Hi.
>
> Below is a list of issues I raised against draft 02 which IMHO have not been
> adequately addressed in the latest draft (see [1] for the original message).
>
>
> 02-C05 Section 6.3, p3
>
> Replace
>
> "However resources are free to return any URI scheme so long as it meets the
> uniqueness requirements."
>
> by
>
> "However servers are free to use any IETF-registered URI scheme so long as
> it meets the uniqueness requirements."
>
> (If it's not IETF-registered, I don't see how it can possibly meet the
> uniqueness criterium).

I'd vote to leave the text as it is.


> C02-14)  Section 8.11, The Effect of Locks on Properties and Collections
>
> "This means that if a collection is locked, its lock-token is required in
> all these cases:
> -        DELETE a collection's direct  internal member
> -        MOVE a member out of the collection
> -        MOVE a member into the collection, unless it overwrites a pre-existing
> member"
>
> I think the latter is not really consistent with RFC3253.
Perhaps I misunderstand the existing text, but I also suspect the
"unless it overwrites..." part is wrong.  If you do a MOVE and it's
actually a different resource in that slot, I think you do need the parent
collection's lock token.  It's only a PUT that doesn't require it.


> C02-30) Section 14.7
>
> "A change in a property SHOULD NOT cause the last-modified date to change,
> because clients MAY rely on the last-modified date to know when to overwrite
> the existing body."
>
> I think this is a new requirement that hasn't been discussed. BTW: it's
> inconsistent with the attempt to make ETags a MUST -- if you have Etags, you
> don't have to rely on the last modified date anyway.

I don't know if we discussed it or not, but the wording that is there seems
fine.  I do lack any compelling test cases to drive this issue in a particular
direction though.  I will rhetorically ask what non-WebDAV browsers do
with ETags and lastmoddate.

--=_alternative 005A972685256D73_=-- From w3c-dist-auth-request@w3.org Wed Jul 30 14:16: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 OAA11495 for ; Wed, 30 Jul 2003 14:16: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 h6UIGbEh001542; Wed, 30 Jul 2003 14:16:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UIGXqu001496; Wed, 30 Jul 2003 14:16:33 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 14:16:33 -0400 (EDT) Resent-Message-Id: <200307301816.h6UIGXqu001496@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UIGUEh001441 for ; Wed, 30 Jul 2003 14:16:30 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UIGTvx011272 for ; Wed, 30 Jul 2003 14:16:29 -0400 Received: (qmail 15332 invoked by uid 65534); 30 Jul 2003 18:16:15 -0000 Received: from p3EE2475A.dip.t-dialin.net (HELO lisa) (62.226.71.90) by mail.gmx.net (mp023) with SMTP; 30 Jul 2003 20:16:15 +0200 From: "Julian Reschke" To: "Jason Crawford" Cc: Date: Wed, 30 Jul 2003 20:15:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEEMIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7752 X-Loop: 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: 8bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Jason Crawford > Sent: Wednesday, July 30, 2003 6:20 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: rfc2518-bis-04 issues (part 1) > > > > I don't have the spec handy, so I can only comment on the items that include > enough comment... > > > 03-C03 > > > > 4.4: "Note that the use of a new top-level URI identifier as a namespace > is > > considered by many to be a bad thing…" > > > > [as of draft 04 this now reads: "Note that "DAV:" is a top-level URI > > identifier that was defined > > solely to provide a namespace for WebDAV XML elements and property > > names. This practice is discouraged in part because registration of > > top-level URI identifiers is difficult. "DAV:" was defined as the > > WebDAV namespace before standard best practices emerged, and this > > namespace is kept and still used because of significant existing > > deployments, but this should not be emulated. "] > > > > Rewrite as: > > > > "Note that both defining a new URI scheme just for the purpose of > > identifying protocol elements, and using just the scheme name as anamespace > > name is to be considered a bad practice, and should not be copied". > > > > The previous text seems clearer. I'd not rewrite this. It may "seem" clearer, but it isn't. Mainly 1) usage of the term "top-level URI identifier" -- this isn't documented anywhere. We're talking about the URI scheme name, and thus should use that term. 2) the issues are exactly what I wrote: a) defining a new URI scheme without actually needing one, and b) using just the scheme name as namespace URI (which is illegal according to RFC2396). Therefore, this section should be rewritten accordingly. > > 03-C05 > > > > 4.5: "The value of a property appears inside the property name element. The > > value may be any text, including valid XML. When the value is structured > > as XML, namespaces that are in scope for that part of the XML document > > apply within the property value as well, and MUST be preserved in server > > storage for retransmission later. Namespace prefixes need not be preserved > > due to the rules of prefix declaration in XML." > > > > 1) I think this needs to rephrased to use proper XML terminology, also > > 2) I think that namespace prefixes within the property value do need to be > > round.tripped. > > > > Proposal: > > > > "The value of a property appears inside the property name > element and may > be > > any kind of well-formed XML content, including both text-only and mixed > > content. When the property value contains further XML elements, > namespaces > > and namespace prefixes that are in scope for that part of the > XML document > > apply within the property value as well, and MUST be preserved in server > > storage for retransmission later." > > > > [Issue 2 still needs to be resolved, the current text says: "Namespace > > prefixes need not be preserved due to the rules of prefix declaration in > > XML."] > > I have no opinion on prefix preservation. It was pointed out that the prefixes are irrelevant, *unfortunately* this is not true, as they also may appear in attribute values (for instance in XSLT and XML Schema datatypes). > > 03-C12: > > > > 8.1.1.: "Some of the following new HTTP methods use XML as a request and > > response format. All DAV compliant clients and resources MUST use XML > > parsers that are compliant with [REC-XML]." > > > > Add "…and [REC-XMLNS]". > > > > We also need allow servers and clients to rejects a certain set of > > request/response that are indeed well-formed, in particular: > > > > - when it exceeds some predefined size or > Sounds fine, but it's just one of several reasons to reject > a request. If possible, I'd like to declare these as out of > scope as long as we're clear how the server should respond > to problems of this class. Is it clear how server writers > should respond to problematic situations that we don't > explicitly mention? First of all, we should clarify that servers may reject requests for a number of reasons we don't specify, such as to prevent DoS attacks. In this particular case, I think the spec should actually *recommend* these requests because they are a known XML protocol vulnerability. > > 03-C17: > > > > 8.1.5.: "Because clients may be forced to prompt users or throw away > changed > > content if the ETag changes, a WebDAV server MUST not change > the ETag (or > > getlastmodified value) for a resource when only its property values > change." > > > > Some servers do, and I don't think we can change that. Therefore I think > > this change at least needs explicit consensus on the mailing list. > > I vote for the wording that is in there. I think we've already reached > consensus > that changing property values should not be changing etags. a) When and where? b) Just for etags or for the last-modified date as well? I just want to make sure that everybody is aware that this requirement will make existing servers non-compliant, and it's unclear whether they'll be able to become compliant. So we'll either see servers not being upgraded to RFC2518bis, or servers claiming compliance to RFC2528bis but breaking it. I don't see this as improvement. > > 03-C21: > > > > 8.2.: "Note that 'allprop' does not return values for all properties." > > > > Change to: > > > > "Note that 'allprop' does not return values for all live properties." > > All dead properties must be returned? I didn't pick that up in our > discussions. It never was discussed. RFC2518 guarantuees this and there never has been any discussion about changing this (why?). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 14:23: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 OAA11730 for ; Wed, 30 Jul 2003 14:23: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 h6UINbEh004272; Wed, 30 Jul 2003 14:23:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UINasv004259; Wed, 30 Jul 2003 14:23:36 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 14:23:36 -0400 (EDT) Resent-Message-Id: <200307301823.h6UINasv004259@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UINYEh004226 for ; Wed, 30 Jul 2003 14:23:34 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UINWvx013706 for ; Wed, 30 Jul 2003 14:23:33 -0400 Received: (qmail 20916 invoked by uid 65534); 30 Jul 2003 18:23:27 -0000 Received: from p3EE2475A.dip.t-dialin.net (HELO lisa) (62.226.71.90) by mail.gmx.net (mp026) with SMTP; 30 Jul 2003 20:23:27 +0200 From: "Julian Reschke" To: "Jason Crawford" Cc: Date: Wed, 30 Jul 2003 20:23:21 +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: rfc2518-bis-04 issues (part 2) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEENIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7753 X-Loop: 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 Jason Crawford > Sent: Wednesday, July 30, 2003 6:36 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: rfc2518-bis-04 issues (part 2) > > ... > > > 02-C05 Section 6.3, p3 > > > > Replace > > > > "However resources are free to return any URI scheme so long as it meets the > > uniqueness requirements." > > > > by > > > > "However servers are free to use any IETF-registered URI scheme so long as > > it meets the uniqueness requirements." > > > > (If it's not IETF-registered, I don't see how it can possibly meet the > > uniqueness criterium). > > I'd vote to leave the text as it is. Again, please help me understand...: 1) Are you suggesting that to for a scheme to be IETF-registered is not a requirement? In which case I'll argue that by definition there can't be any uniquess guarantee otherwise. 2) Are you suggesting that this is obvious? I which case I'll have to point out that there are well-known server implementations doing just that, so obviously the spec hasn't been clear enough about that. > > C02-14) Section 8.11, The Effect of Locks on Properties and Collections > > > > "This means that if a collection is locked, its lock-token is > required in > > all these cases: > > - DELETE a collection's direct internal member > > - MOVE a member out of the collection > > - MOVE a member into the collection, unless it overwrites a > pre-existing > > member" > > > > I think the latter is not really consistent with RFC3253. > Perhaps I misunderstand the existing text, but I also suspect the > "unless it overwrites..." part is wrong. If you do a MOVE and it's > actually a different resource in that slot, I think you do need the parent > collection's lock token. It's only a PUT that doesn't require it. Correct. > > C02-30) Section 14.7 > > > > "A change in a property SHOULD NOT cause the last-modified date to change, > > because clients MAY rely on the last-modified date to know when to overwrite > > the existing body." > > > > I think this is a new requirement that hasn't been discussed. BTW: it's > > inconsistent with the attempt to make ETags a MUST -- if you have Etags, you > > don't have to rely on the last modified date anyway. > > I don't know if we discussed it or not, but the wording that is there seems > fine. I do lack any compelling test cases to drive this issue in a particular > direction though. I will rhetorically ask what non-WebDAV browsers do > with ETags and lastmoddate. It's a procedural question. I think *any* change to RFC2518 (and this is a change) should appear on the issues list, indicating when and why it was raised as an issue, and what conclusion was reached. As far as I know, this hasn't happened. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 15:59: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 PAA15718 for ; Wed, 30 Jul 2003 15:59:07 -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 h6UJx8Eh000563; Wed, 30 Jul 2003 15:59:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UJwspl000490; Wed, 30 Jul 2003 15:58:54 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 15:58:54 -0400 (EDT) Resent-Message-Id: <200307301958.h6UJwspl000490@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UJwqEh000435 for ; Wed, 30 Jul 2003 15:58:52 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UJwpvx011199 for ; Wed, 30 Jul 2003 15:58:51 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA17429 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 30 Jul 2003 12:58:50 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA17379 sender obsfucated@us.ibm.com; Wed, 30 Jul 2003 12:58:48 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UJwCwO139288; Wed, 30 Jul 2003 15:58:16 -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 h6UJwBJr256432; Wed, 30 Jul 2003 15:58:11 -0400 To: "Julian Reschke" 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: Wed, 30 Jul 2003 15:58:06 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/30/2003 15:58:11, Serialize complete at 07/30/2003 15:58:11 Content-Type: multipart/alternative; boundary="=_alternative 006D467085256D73_=" Subject: RE: rfc2518-bis-04 issues (part 2) X-Archived-At: http://www.w3.org/mid/OF4343D6B8.166DA144-ON85256D73.006CC3C5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7754 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 006D467085256D73_= Content-Type: text/plain; charset="us-ascii" > > > Replace > > > > > > "However resources are free to return any URI scheme so long as it meets > > > the uniqueness requirements." > > > > > > by > > > > > > "However servers are free to use any IETF-registered URI scheme so long > > > as it meets the uniqueness requirements." > > > > > > (If it's not IETF-registered, I don't see how it can possibly meet the > > > uniqueness criterium). > > > > I'd vote to leave the text as it is. > > Again, please help me understand...: > > 1) Are you suggesting that to for a scheme to be IETF-registered is not a > requirement? In which case I'll argue that by definition there can't be any > uniquess guarantee otherwise. > 2) Are you suggesting that this is obvious? I which case I'll have to point > out that there are well-known server implementations doing just that, so > obviously the spec hasn't been clear enough about that. I think there are a lot of things a developer might do to that can result in collisions, and that we don't need to outline them. --=_alternative 006D467085256D73_= Content-Type: text/html; charset="us-ascii"
> > > Replace
> > >
> > > "However resources are free to return any URI scheme so long as it meets
> > > the uniqueness requirements."
> > >
> > > by
> > >
> > > "However servers are free to use any IETF-registered URI scheme so long
> > > as it meets the uniqueness requirements."
> > >
> > > (If it's not IETF-registered, I don't see how it can possibly meet the
> > > uniqueness criterium).
> >
> > I'd vote to leave the text as it is.
>
> Again, please help me understand...:
>
> 1) Are you suggesting that to for a scheme to be IETF-registered is not a
> requirement? In which case I'll argue that by definition there can't be any
> uniquess guarantee otherwise.
> 2) Are you suggesting that this is obvious? I which case I'll have to point
> out that there are well-known server implementations doing just that, so
> obviously the spec  hasn't been clear enough about that.

I think there are a lot of things a developer might do to that can result in
collisions, and that we don't need to outline them.


--=_alternative 006D467085256D73_=-- From w3c-dist-auth-request@w3.org Wed Jul 30 15:59:09 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 PAA15724 for ; Wed, 30 Jul 2003 15:59:08 -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 h6UJx9Eh000572; Wed, 30 Jul 2003 15:59:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UJx1rY000527; Wed, 30 Jul 2003 15:59:01 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 15:59:01 -0400 (EDT) Resent-Message-Id: <200307301959.h6UJx1rY000527@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UJwqEh000445 for ; Wed, 30 Jul 2003 15:58:52 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UJwpvx011200 for ; Wed, 30 Jul 2003 15:58:51 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA17432 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 30 Jul 2003 12:58:50 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA17380 sender obsfucated@us.ibm.com; Wed, 30 Jul 2003 12:58:48 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UJwCwO106458; Wed, 30 Jul 2003 15:58:16 -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 h6UJwBJr248760; Wed, 30 Jul 2003 15:58:11 -0400 To: "Julian Reschke" 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: Wed, 30 Jul 2003 15:58:06 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/30/2003 15:58:10, Serialize complete at 07/30/2003 15:58:10 Content-Type: multipart/alternative; boundary="=_alternative 006CBB0F85256D73_=" Subject: RE: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/OF026FEE4C.BEE5CEF7-ON85256D73.006B97C3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7755 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 006CBB0F85256D73_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > 03-C03 > > > > > > 4.4: "Note that the use of a new top-level URI identifier as a=20 namespace > > is > > > considered by many to be a bad thing?" > > > > > > [as of draft 04 this now reads: "Note that "DAV:" is a top-level URI > > > identifier that was defined > > > solely to provide a namespace for WebDAV XML elements and=20 property > > > names. This practice is discouraged in part because registration = of > > > top-level URI identifiers is difficult. "DAV:" was defined as the > > > WebDAV namespace before standard best practices emerged, and this > > > namespace is kept and still used because of significant existing > > > deployments, but this should not be emulated. "] > > > > > > Rewrite as: > > > > > > "Note that both defining a new URI scheme just for the purpose of > > > identifying protocol elements, and using just the scheme name as > anamespace > > > name is to be considered a bad practice, and should not be copied". > > > > > > > The previous text seems clearer. I'd not rewrite this. >=20 > It may "seem" clearer, but it isn't. Mainly >=20 > 1) usage of the term "top-level URI identifier" -- this isn't documented > anywhere. We're talking about the URI scheme name, and thus should use=20 that > term. > 2) the issues are exactly what I wrote: a) defining a new URI scheme=20 without > actually needing one, and b) using just the scheme name as namespace URI > (which is illegal according to RFC2396). > > Therefore, this section should be rewritten accordingly. I suspect a hybrid of your proposal and the old text would be best. > > > [Issue 2 still needs to be resolved, the current text says:=20 "Namespace > > > prefixes need not be preserved due to the rules of prefix=20 declaration in > > > XML."] > > > > I have no opinion on prefix preservation. >=20 > It was pointed out that the prefixes are irrelevant, *unfortunately*=20 this is > not true, as they also may appear in attribute values (for instance in=20 XSLT > and XML Schema datatypes). Yup. Still no opinion. If people feel these situations are significant,=20 then I don't have a problem with preserving prefixes. > > > 03-C21: > > > > > > 8.2.: "Note that 'allprop' does not return values for all=20 properties." > > > > > > Change to: > > > > > > "Note that 'allprop' does not return values for all live=20 properties." > > > > All dead properties must be returned? I didn't pick that up in our > > discussions. >=20 > It never was discussed. RFC2518 guarantuees this and there never has=20 been > any discussion about changing this (why?). I only ask because I recall discussions about whether they return all properties and reasons we don't want to require that servers return all properties, but I don't recall a discussion about how a server decides what properties to return and definitely nothing about what a client can assume about what the server has decided. I could have overlooked a discussion though. I just want to give people a heads-up that this wouild be a good time to speak up if you disagree with this text. --=_alternative 006CBB0F85256D73_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> > > 03-C03
> > >
> > > 4.4: "Note that the use of a new top-level URI identifi= er as a namespace
> > is
> > > considered by many to be a bad thing…"
> > >
> > > [as of draft 04 this now reads: "Note that "DAV:&q= uot; is a top-level URI
> > > identifier that was defined
> > >    solely to provide a namespace for WebDAV XML el= ements and property
> > >    names.  This practice is discouraged in pa= rt because registration of
> > >    top-level URI identifiers is difficult. "D= AV:" was defined as the
> > >    WebDAV namespace before standard best practices= emerged, and this
> > >    namespace is kept and still used because of sig= nificant existing
> > >    deployments, but this should not be emulated. &= quot;]
> > >
> > > Rewrite as:
> > >
> > > "Note that both defining a new URI scheme just for the = purpose of
> > > identifying protocol elements, and using just the scheme nam= e as
> anamespace
> > > name is to be considered a bad practice, and should not be c= opied".
> > >
> >
> > The previous text seems clearer.  I'd not rewrite this.
>
> It may "seem" clearer, but it isn't. Mainly
>
> 1) usage of the term "top-level URI identifier" -- this isn'= t documented
> anywhere. We're talking about the URI scheme name, and thus should use= that
> term.
> 2) the issues are exactly what = I wrote: a) defining a new URI scheme without
> actually needing one, and b) using just the scheme name as namespace U= RI
> (which is illegal according to RFC2396).
>
> Therefore, this section should be rewritten accordingly.

I suspect a hybrid of your proposal = and the old text would be best.

> > > [Issue 2 still needs to be resolved, the current text says: = "Namespace
> > > prefixes need not be preserved due to the rules of prefix de= claration in
> > > XML."]
> >
> > I have no opinion on prefix preservation.
>
> It was pointed out that the prefixes are irrelevant, *unfortunately* t= his is
> not true, as they also may appear in attribute values (for instance in= XSLT
> and XML Schema datatypes).

Yup.  Still no opinion.  I= f people feel these situations are significant, then
I don't have a problem with preservi= ng prefixes.

> > > 03-C21:
> > >
> > > 8.2.: "Note that 'allprop' does not return values for a= ll properties."
> > >
> > > Change to:
> > >
> > > "Note that 'allprop' does not return values for all liv= e properties."
> >
> > All dead properties must be returned?  I didn't pick that up= in our
> > discussions.
>
> It never was discussed. RFC2518 guarantuees this and there never has b= een
> any discussion about changing this (why?).

I only ask because I recall discussi= ons about whether they return all
properties and reasons we don't want= to require that servers return all
properties, but I don't recall a dis= cussion about how a server decides
what properties to return and defini= tely nothing about what a client can
assume about what the server has dec= ided.  I could have overlooked
a discussion though.  I just wa= nt to give people a heads-up that
this wouild be a good time to speak = up if you disagree with this text.


--=_alternative 006CBB0F85256D73_=-- From w3c-dist-auth-request@w3.org Wed Jul 30 16:48: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 QAA17159 for ; Wed, 30 Jul 2003 16:48: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 h6UKmWEh008535; Wed, 30 Jul 2003 16:48:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UKmU7B008511; Wed, 30 Jul 2003 16:48:30 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 16:48:30 -0400 (EDT) Resent-Message-Id: <200307302048.h6UKmU7B008511@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UKmTEh008478 for ; Wed, 30 Jul 2003 16:48:29 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UKmSvx025108 for ; Wed, 30 Jul 2003 16:48:28 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h6UKmMO17185 for ; Wed, 30 Jul 2003 13:48:22 -0700 (PDT) Message-ID: <3F282F16.3000402@cse.ucsc.edu> Date: Wed, 30 Jul 2003 13:48:22 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: multipart/alternative; boundary="------------090209090306020404070507" Subject: Re: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/3F282F16.3000402@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7756 X-Loop: 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: --------------090209090306020404070507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Comments inlined below... Cheers, Elias Jason Crawford wrote: > I don't have the spec handy, so I can only comment on the items that > include > enough comment... > > > 03-C03 > > > > 4.4: "Note that the use of a new top-level URI identifier as a > namespace is > > considered by many to be a bad thing..." > > > > [as of draft 04 this now reads: "Note that "DAV:" is a top-level URI > > identifier that was defined > > solely to provide a namespace for WebDAV XML elements and property > > names. This practice is discouraged in part because registration of > > top-level URI identifiers is difficult. "DAV:" was defined as the > > WebDAV namespace before standard best practices emerged, and this > > namespace is kept and still used because of significant existing > > deployments, but this should not be emulated. "] > > > > Rewrite as: > > > > "Note that both defining a new URI scheme just for the purpose of > > identifying protocol elements, and using just the scheme name as a > namespace > > name is to be considered a bad practice, and should not be copied". > > > > The previous text seems clearer. I'd not rewrite this. The existing text seems a bit 'heavy' (for lack of a better word), while the suggested replacement seems a bit 'light'. At the least, it makes sense to include some justification for the approach that was taken while making the case for others to not follow in suit. Further, saying something is 'bad practice' or discouraged without explaining why simply begs the question... > > 03-C05 > > > > 4.5: "The value of a property appears inside the property name > element. The > > value may be any text, including valid XML. When the value is > structured > > as XML, namespaces that are in scope for that part of the XML document > > apply within the property value as well, and MUST be preserved in > server > > storage for retransmission later. Namespace prefixes need not be > preserved > > due to the rules of prefix declaration in XML." > > > > 1) I think this needs to rephrased to use proper XML > terminology, also > > 2) I think that namespace prefixes within the property value > do need to > > be > > round.tripped. > > > > Proposal: > > > > "The value of a property appears inside the property name element > and may be > > any kind of well-formed XML content, including both text-only and mixed > > content. When the property value contains further XML elements, > namespaces > > and namespace prefixes that are in scope for that part of the XML > document > > apply within the property value as well, and MUST be preserved in server > > storage for retransmission later." > > > > [Issue 2 still needs to be resolved, the current text says: "Namespace > > prefixes need not be preserved due to the rules of prefix declaration in > > XML."] > > I have no opinion on prefix preservation. My feeling is that while a server is allowed to rewrite XML as long as it preserves the semantics, dropping namespace prefixes is likely to cause problems. For example: Storing as to save space is perfectly fine, while storing the above as is not. The issue at hand is that namespaces serve to qualify the semantic interpretation of a given XML element, hence dropping that qualification can only lead to interoperability problems between clients which respect or, alternately, expect namespaces. Without the namespace qualifier, a client may not be able to know what is meant by an element. I would be happy to construct a more meaningful example to illustrate this, but I hope the above is sufficient. This is an important issue that we need to reach a concensus on. > > 03-C12: > > > > 8.1.1.: "Some of the following new HTTP methods use XML as a request and > > response format. All DAV compliant clients and resources MUST use XML > > parsers that are compliant with [REC-XML]." > > > > Add "...and [REC-XMLNS]". > > > > We also need allow servers and clients to rejects a certain set of > > request/response that are indeed well-formed, in particular: > > > > - when it exceeds some predefined size or > Sounds fine, but it's just one of several reasons to reject a request. > If possible, I'd like to declare these as out of scope as long as > we're clear how the server should respond to problems of this class. > Is it clear how server writers should respond to problematic > situations that we don't explicitly mention? I agree, adding the suggested text is a good idea. Re: Jason's comment, I think the best we can do is define a common response mechanism, as what qualifies as exceeding 'some predefined size' and what constitutes a denial of service attack will likely change from one server to another and over time as server hardware improves. > > 03-C17: > > > > 8.1.5.: "Because clients may be forced to prompt users or throw away > changed > > content if the ETag changes, a WebDAV server MUST not change the > ETag (or > > getlastmodified value) for a resource when only its property values > change." > > > > Some servers do, and I don't think we can change that. Therefore I think > > this change at least needs explicit consensus on the mailing list. > > I vote for the wording that is in there. I think we've already > reached consensus that changing property values should not be changing > etags. I also believe that there was already concensus re: property values not affecting ETags... Since doing a PUT of a resource doesn't affect properties and a GET doesn't retrieve properties, the ETag should not change when properties on a resource do. That is to say that ETags should only be modified when the enitity, itself, is modified (hence the name entity tag). We may want to consider, however, introducing an equivalent property tag, or PTag, which could be used to determine if properties on a given resource have changed. An argument with a (set of) use case(s) would have to be developed to make this a compelling idea. --------------090209090306020404070507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Comments inlined below...

Cheers,
Elias


Jason Crawford wrote:
I don't have the spec handy, so I can only comment on the items that include
enough comment...

> 03-C03
>
> 4.4: "Note that the use of a new top-level URI identifier as a namespace is
> considered by many to be a bad thing…"
>
> [as of draft 04 this now reads: "Note that "DAV:" is a top-level URI
> identifier that was defined
>    solely to provide a namespace for WebDAV XML elements and property
>    names.  This practice is discouraged in part because registration of
>    top-level URI identifiers is difficult. "DAV:" was defined as the
>    WebDAV namespace before standard best practices emerged, and this
>    namespace is kept and still used because of significant existing
>    deployments, but this should not be emulated. "]
>
> Rewrite as:
>
> "Note that both defining a new URI scheme just for the purpose of
> identifying protocol elements, and using just the scheme name as a namespace
> name is to be considered a bad practice, and should not be copied".
>

The previous text seems clearer.  I'd not rewrite this.
The existing text seems a bit 'heavy' (for lack of a better word), while the suggested replacement seems a bit 'light'. At the least, it makes sense to include some justification for the approach that was taken while making the case for others to not follow in suit. Further, saying something is 'bad practice' or discouraged without explaining why simply begs the question...
> 03-C05
>
> 4.5: "The value of a property appears inside the property name element.  The
> value may be any text, including valid XML.  When the value is  structured
> as XML, namespaces that are in scope for that part of the  XML document
> apply within the property value as well, and MUST be  preserved in server
> storage for retransmission later. Namespace prefixes need not be preserved
> due to the rules of prefix declaration in XML."
>
> 1)        I think this needs to rephrased to use proper XML terminology, also
> 2)        I think that namespace prefixes within the property value do need to
> be
> round.tripped.
>
> Proposal:
>
> "The value of a property appears inside the property name element and may be
> any kind of well-formed XML content, including both text-only and mixed
> content. When the property value contains further XML elements, namespaces
> and namespace prefixes that are in scope for that part of the XML document
> apply within the property value as well, and MUST be preserved in server
> storage for retransmission later."
>
> [Issue 2 still needs to be resolved, the current text says: "Namespace
> prefixes need not be preserved due to the rules of prefix declaration in
> XML."]

I have no opinion on prefix preservation.
My feeling is that while a server is allowed to rewrite XML as long as it preserves the semantics, dropping namespace prefixes is likely to cause problems. For example:

Storing
<Foo:bar>
</Foo:bar>
as
<Foo:bar/>
to save space is perfectly fine, while storing the above as
<bar/>
is not. The issue at hand is that namespaces serve to qualify the semantic interpretation of a given XML element, hence dropping that qualification can only lead to interoperability problems between clients which respect or, alternately, expect namespaces. Without the namespace qualifier, a client may not be able to know what is meant by an element. I would be happy to construct a more meaningful example to illustrate this, but I hope the above is sufficient. This is an important issue that we need to reach a concensus on.
> 03-C12:
>
> 8.1.1.: "Some of the following new HTTP methods use XML as a request and
> response format.  All DAV compliant clients and resources MUST use  XML
> parsers that are compliant with [REC-XML]."
>
> Add "…and [REC-XMLNS]".
>
> We also need allow servers and clients to rejects a certain set of
> request/response that are indeed well-formed, in particular:
>
> -        when it exceeds some predefined size or
Sounds fine, but it's just one of several reasons to reject a request.  If possible, I'd like to declare these as out of  scope as long as we're clear how the server should respond to problems of this class.  Is it clear how server writers should respond to problematic situations that we don't explicitly mention?
I agree, adding the suggested text is a good idea. Re: Jason's comment, I think the best we can do is define a common response mechanism, as what qualifies as exceeding 'some predefined size' and what constitutes a denial of service attack will likely change from one server to another and over time as server hardware improves.
> 03-C17:
>
> 8.1.5.: "Because clients may be forced to prompt users or throw away changed
> content if the ETag changes, a WebDAV server MUST not change the  ETag (or
> getlastmodified value) for a resource when only its property values change."
>
> Some servers do, and I don't think we can change that. Therefore I think
> this change at least needs explicit consensus on the mailing list.

I vote for the wording that is in there.  I think we've already reached consensus that changing property values should not be changing etags.
I also believe that there was already concensus re: property values not affecting ETags... Since doing a PUT of a resource doesn't affect properties and a GET doesn't retrieve properties, the ETag should not change when properties on a resource do. That is to say that ETags should only be modified when the enitity, itself, is modified (hence the name entity tag). We may want to consider, however, introducing an equivalent property tag, or PTag, which could be used to determine if properties on a given resource have changed. An argument with a (set of) use case(s) would have to be developed to make this a compelling idea.
--------------090209090306020404070507-- From w3c-dist-auth-request@w3.org Wed Jul 30 17:06: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 RAA17956 for ; Wed, 30 Jul 2003 17:06:28 -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 h6UL6UEh012183; Wed, 30 Jul 2003 17:06:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UL6R6K012165; Wed, 30 Jul 2003 17:06:27 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 17:06:27 -0400 (EDT) Resent-Message-Id: <200307302106.h6UL6R6K012165@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UL6QEh012132 for ; Wed, 30 Jul 2003 17:06:26 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UL6Ovx029670 for ; Wed, 30 Jul 2003 17:06:25 -0400 Received: (qmail 27963 invoked by uid 65534); 30 Jul 2003 21:05:59 -0000 Received: from p3EE2475A.dip.t-dialin.net (HELO lisa) (62.226.71.90) by mail.gmx.net (mp022) with SMTP; 30 Jul 2003 23:05:59 +0200 From: "Julian Reschke" To: Date: Wed, 30 Jul 2003 23:05:37 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: rfc2518-bis-04 issues (part 3) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEFGIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7757 X-Loop: 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 Here's a set of new issues (that is, issues I didn't raise earlier, they may have been present for longer or even in RFC2518): 04-C01 attributes on properties Section 4.5: "Attributes on the property name element may convey information about the property, but are not considered part of the value." As far as I can tell, we haven't reached consensus on this. The latest discussion I'm aware of is at . 04-C02 lock discovery and tokens Section 6.3: "Finally, the lockdiscovery property can be queried using PROPFIND and the token can be discovered that way. Each lock has only one unique lock token." - the token can only be discovered this way if there aren't multiple tokens (due to shared locks) - clarify "has only one" by "has exactly one" 04-C03 opaquelocktoken syntax Section 6.4, last p.: "Extension = path ; path is defined in section 3.2.1 of [RFC2616]" ...should say "3.3 of RFC2396" 04-C04 sect 6.5, access control I find the mixing of lock capabilities and access control capabilities confusing. Maybe we should remove or rewrite this in the light of the ACL spec. 04-C05 sect 7.4, p2 "The lost-update problem is not an issue for collections because MKCOL can only be used to create a collection, not to overwrite an existing collection. In order to immediately lock a collection upon creation, clients may attempt to pipeline the MKCOL and LOCK requests together." There's no guarantee that this will be atomically, thus in the best case, it just makes a race condition less likely. As you can't rely on this to always succeed, I'd recommend not to say anything at all. 04-C06 sect 7.4, p3 "A lock request to an unmapped URL should result in the creation of a resource that is locked. A subsequent PUT request with the correct lock token should normally succeed, and provides the content, content-type, content-language and other information as appropriate." If this is supposed to be normative text, it should use "SHOULD" instead of "should" (same problem with many places where text was added). Besides, what is "should normally succeed" supposed to mean? 04-C07 sect 7.4, p4 "Historically, a lock-null resource: ... - Disappears (becomes once more an unmapped URL) if its lock goes away before it is converted to a regular resource. (This must..." The lock-null resource becomes unmapped, it doesn't become an unmapped URL. 04-C08, sect 8.1.1 "illformed" isn't defined in REC-XML. Propose to use "non-wellformed". 04-C09, sect 8.1.3 ...speaks of "consistent" usage of addresses without precisely defining what that means. 04-C10, sect 8.1.5 "HTTP 1.1 suggests the use of the ETag header in responses to GET and PUT requests" Make this more precise (maybe "recommends"?). Also directly reference the section in RFC2616. 04-C11, sect 8.1.5 p 2 This requirement will make both IIS and Apache/moddav non-compliant. Before I can agree to this, I'd like *at least* see the Apache/moddav developers committing to this change. 04-C11, sect 8.1.5 p 3 This will make IIS non-compliant. 04-C12, sect 8.2 p 2 'A client may submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND on a collection resource with internal member URLs.' Remove "with internal member URLs". It's irrelevant whether the collection has members. 04-C13, sect 8.2 "Clients expect the fully-qualified URLs of members of a collection to have a common prefix which is the fully-qualified URL of the parent collection itself." If this is meant to define a normative requirement on server behaviour, it should be worded accordingly. "URLs in a PROPFIND response body MAY be represented as fully-qualified URLs, in which case they must all contain the full parent collection URL (scheme, host, port, and absolute path). Alternatively, these URLs MAY be absolute paths (not containing scheme, host or port), but in this case they must all still contain the full parent collection path." I'd strongly suggest to remove all of this and to clearly state using the RFC2396 productions what is allowed. "URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) must also be legal URIs." This somehow suggests that there's something like an "illegal" URI. Either a text string conforms to the RFC2396 requirements (then it is a URI) or it doesn't (then it's not a URI at all). Recommend to drop this paragraph, but do add normative language somewhere else (for instance, when defining legal contents for DAV:href). "In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property should be silently excluded from the response." s/should/MAY/ 04-C14, sect 8.4 "For example, if a request to create collection /a/b/c/d/ is made, and either /a/b/ nor /a/b/c/ exists, the request must fail." I think it must fail if and only if /a/b/c/ does not exist. It's irrelevant whether /a/b/ exists. 04-C15, sect 8.4 status codes "The collection or structured resource was created in its entirety." What is a "structured resource" and where was it defined? "405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource." HTTP methods are applied to URLs, not resources. Say "can only be executed on an unmapped URL" 04-C16, sect 8.7 "Thus, after a successful DELETE operation (and in the absence of other actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI would return 404 (Not Found)". s/would/MUST/ 04-C17, sect 8.9, Copy for properties "If a property cannot be copied live, then its value MUST be duplicated, octet-for-octet, in an identically named, dead property on the destination resource." No! That would be a desaster. Make this "SHOULD NOT". Otherwise clients will see the dead property (such as DAV:checked-in) and make wrong assumptions about the resource. 04-C18, sect 8.9.3 "Either the source context does not support copying to the destination context, or the destination context refuses to accept the resource." If we use the term "context", we'oll have to define it somewhere. 04-C19, sect 8.10 "If a resource exists at the destination, the destination resource will be DELETEd as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header." s/DELETEd/deleted/ 04-C20, sect 8.10.1 "Live properties described in this document MUST be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. If the live properties will not work the same way at the destination, the server MUST fail the request (the client can perform COPY then DELETE if it wants a MOVE to work that badly). This can mean that the server removes a live property if that's the most appropriate behavior for that live property at the destination." The second sentence implies that the MOVE must fail if the live properties can't be moved as well, while the last sentence says that the server may remove the live properties. "A MOVE can be a rename operation, so it's not appropriate to reset live properties which are set at resource creation. For example, the creationdate property value SHOULD remain the same." So can a MOVE be something else then a rename operation? If yes, how does the second sentence then applies? If it doesn't apply always, and the client won't know, why are we mentioning it? 04-C21, sect 8.11, refreshing LOCKs "A lock is refreshed by sending a new LOCK request to the resource which is the root of the lock. A LOCK request to refresh a lock must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time). This request does not contain a body, but it may contain a Timeout header. A server MAY accept the Timeout header to change the duration remaining on the lock to the new value." Replace by "A lock is refreshed by applying a LOCK request to the URL which is the root of the lock. This request must specify which lock to refresh by using the Lock-Token header with a single lock token (only one lock may be refreshed at a time) and does not contain a body, but it may contain a Timeout header. A server MAY accept the Timeout header to change the duration remaining on the lock to the new value." 04-C22, sect 8.11.1 Fix the XML response by replacing http://example.com/workspace/webdav /proposal.doc by something like http://example.com/workspace/webdav/proposal.doc< /D:href> 04-C23, section 9.8 Do we have interoperability for status "102" and the Status-URI header? I don't think so, so I'd recommend to remove them from the spec. 04-C24, section 11 I think this section doesn't really help. It doesn't seem to say anything normative, so I'd recommend to drop it, and to improve the sections for the individual methods. 04-C25, section 12 "When a Multi-Status response does not have a clear scope (e.g. in response to MOVE or COPY when the scope could be either the source or the destination), URLs appearing in the response body SHOULD be absolute and fully-qualified URLs." Either define "clear scope", or (preferably) improve RFC2518 that there is no situation where the scope is not "clear". 04-C26, section 13, "lockroot" "Purpose: The resource where the lock is orootedo, which is the resource that was addressed in the LOCK request." This is not purpose. Say "Purpose: contains the root of the lock, i.e. the URL to which the LOCK request was applied." 04-C27, section 13, "deadprops" During the January meeting we agreed upon "dead-props". We already implement that. Why change it? 04-C28, section 14, displayname "It MAY be attempted to be set in remote COPY operation." I'd say: it MUST NOT. "This property is live and MAY be protected." What's the use case for it being protected? 04-C29, section 14 Uses the term "remote COPY operation" and "cross-server copy". I think we need to define what this means. 04-C30, section 14.5 "In a remote COPY operation that is implemented through a GET request, the GET request must have the appropriate Content-Type header." I honestly don't understand what this means. 04-C31, section 14.6 "It MUST NOT be set in PROPPATCH during a cross-server copy." It seems that we assume here that the reader is aware of implementations that implement cross-sever copies using GET/PROPFIND/PUT/PROPPATCH. If we want to keep this, we need to expand this (probably in the section about COPY). Alternatively drop it. "Refer to RFC2616 for a complete definition of the semantics of an ETag." Just say: "(see RFC2616, section a.b.c)" 04-C32, section 17 "It is only in the case where the set of properties is not known ahead of time that an application need display a property name URI to a user" There is no such thing as a "property name URI", unless we define it. 04-E01 non-ASCII characters There are many instances of non-ASCII characters in the document, probably caused by a missing conversion step. 04-E02 usage of sample host names not according to IETF recommendations For instance: 04-E03 undefined reference in last paragraph on page 6 04-E04 Numbering of appendices Each appendix should have it's own section number. draft-rfc-editor-rfc2223bis-06.txt seems to recommand uppercase letters (such as "Appendix A"). 04-E05 wrong reference Page 7, 2nd paragraph refers to 13.28, I think this needs to be 14. 04-E06 Terminology URI/URL: note we should be prepared to update to RFC2396bis when it's ready. 04-E07 usage of property names in surrounding text I think we should try to use a consistent syntax when referring to DAV: properties. Currently we have a mix between "foo" and "DAV:foo". 04-E08 section 3: definition of "null resource" ...is gone, yet is still used in later sections. 04-E09 "DAV compliant" I think we should try to use either "DAV compliant" or "WebDAV compliant" consistently. 04-E10 sect 7.5, 2nd last para Closing ")" missing. 04-E11 section 8.1.4 Indentation off. 04-E12 paragraph numbering in sec 9 ...is broken. For instance, "Example - No-tag-list If Header" should be a subsection of "No-tag-list Production". 04-E13 paragraph numbering in sec 13 ...is broken. For instance, 13.2 should be a subsection of 13.1 -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 17:17:01 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, 30 Jul 2003 17:16: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 h6ULH1Eh013790; Wed, 30 Jul 2003 17:17:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6ULH0GA013765; Wed, 30 Jul 2003 17:17:00 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 17:17:00 -0400 (EDT) Resent-Message-Id: <200307302117.h6ULH0GA013765@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6ULGxEh013729 for ; Wed, 30 Jul 2003 17:16:59 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6ULGvvx032324 for ; Wed, 30 Jul 2003 17:16:57 -0400 Received: (qmail 18876 invoked by uid 65534); 30 Jul 2003 21:16:41 -0000 Received: from p3EE2475A.dip.t-dialin.net (HELO lisa) (62.226.71.90) by mail.gmx.net (mp012) with SMTP; 30 Jul 2003 23:16:41 +0200 From: "Julian Reschke" To: Date: Wed, 30 Jul 2003 23:16:20 +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: <3F282F16.3000402@cse.ucsc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEFHIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7758 X-Loop: 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 Elias Sinderson > Sent: Wednesday, July 30, 2003 10:48 PM > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518-bis-04 issues (part 1) > > > Comments inlined below... > > Cheers, > Elias > > > ... > > My feeling is that while a server is allowed to rewrite XML as long as it > preserves the semantics, dropping namespace prefixes is likely to cause > problems. For example: > > Storing > > > as > > to save space is perfectly fine, while storing the above as > > is not. The issue at hand is that namespaces serve to qualify the semantic > interpretation of a given XML element, hence dropping that > qualification can > only lead to interoperability problems between clients which respect or, > alternately, expect namespaces. Without the namespace qualifier, a client > may not be able to know what is meant by an element. I would be happy to > construct a more meaningful example to illustrate this, but I > hope the above > is sufficient. This is an important issue that we need to reach a > concensus > on. It get's worse. Consider true Not storing the namespace mapping for "xs" will simply break the content, even if the prefix isn't used for any child element. > ... > > > 03-C17: > > > > 8.1.5.: "Because clients may be forced to prompt users or throw away > changed > > content if the ETag changes, a WebDAV server MUST not change > the ETag (or > > getlastmodified value) for a resource when only its property values > change." > > > > Some servers do, and I don't think we can change that. Therefore I think > > this change at least needs explicit consensus on the mailing list. > > I vote for the wording that is in there. I think we've already reached > consensus that changing property values should not be changing etags. Where and when? > I also believe that there was already concensus re: property values not > affecting ETags... Since doing a PUT of a resource doesn't affect > properties > and a GET doesn't retrieve properties, the ETag should not change when > properties on a resource do. That is to say that ETags should only be That's simply not true. You're argueing from a world view where the server stores properties and content as separate entities. However, it's perfectly legal to have a server that - extracts some properties upon PUT (for instance metadata from a WORD document) and/or - changes the content upon PROPPATCH of one of the aforementioned properties. I think that we can't and shouldn't make this behaviour illegal. > modified when the enitity, itself, is modified (hence the name > entity tag). > We may want to consider, however, introducing an equivalent > property tag, or > PTag, which could be used to determine if properties on a given resource > have changed. An argument with a (set of) use case(s) would have to be > developed to make this a compelling idea. Yes, but that's a separate discussion. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jul 30 17:59: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 RAA19953 for ; Wed, 30 Jul 2003 17:59: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 h6ULxXEh021610; Wed, 30 Jul 2003 17:59:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6ULxStQ021573; Wed, 30 Jul 2003 17:59:28 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 17:59:28 -0400 (EDT) Resent-Message-Id: <200307302159.h6ULxStQ021573@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6ULxREh021540 for ; Wed, 30 Jul 2003 17:59:27 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6ULxQvx011670 for ; Wed, 30 Jul 2003 17:59:26 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA25596 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 30 Jul 2003 14:59:26 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id OAA25563 sender obsfucated@us.ibm.com; Wed, 30 Jul 2003 14:59:24 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6ULwswO123742; Wed, 30 Jul 2003 17:58:54 -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 h6ULwqJr189120; Wed, 30 Jul 2003 17:58:53 -0400 To: "Julian Reschke" 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: Wed, 30 Jul 2003 17:58:47 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/30/2003 17:58:52, Serialize complete at 07/30/2003 17:58:52 Content-Type: multipart/alternative; boundary="=_alternative 0078302085256D73_=" Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1), X-Archived-At: http://www.w3.org/mid/OFF333C66C.62227758-ON85256D73.0076761C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7759 X-Loop: 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: This is a multipart message in MIME format. --=_alternative 0078302085256D73_= Content-Type: text/plain; charset="us-ascii" > > I vote for the wording that is in there. I think we've already reached > > consensus that changing property values should not be changing etags. > > Where and when? Sorry. I don't have a particular posting that declares consensus. It was just what I heard over and over again in postings. People seemed comfortable declaring that changing properties should not change ETags. There was no significant opposition to it that I recall. The issues list lists... http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html But I seem to recall that it was discussed more often than this. As you (and Geoff in the referenced page) point out, some products will become incompatible with 2518bis. I believe people were aware of this, but if they were not, you've just pointed it out. They should speak up... J. --=_alternative 0078302085256D73_= Content-Type: text/html; charset="us-ascii"
> > I vote for the wording that is in there.  I think we've already reached
> > consensus that changing property values should not be changing etags.
>
> Where and when?
Sorry.  I don't have a particular posting that declares consensus.  It was
just what I heard over and over again in postings.  People seemed
comfortable declaring that changing properties should not change ETags.  
There was no significant opposition to it that I recall.

The issues list lists...

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html

But I seem to recall that it was discussed more often than this.

As you (and Geoff in the referenced page) point out, some products will
become incompatible with 2518bis.   I believe people were aware of this,
but if they were not, you've just pointed it out.  They should speak up...

J.
--=_alternative 0078302085256D73_=-- From w3c-dist-auth-request@w3.org Wed Jul 30 18:54:41 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 SAA22531 for ; Wed, 30 Jul 2003 18:54: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 h6UMsiEh001379; Wed, 30 Jul 2003 18:54:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UMseOx001349; Wed, 30 Jul 2003 18:54:40 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 18:54:40 -0400 (EDT) Resent-Message-Id: <200307302254.h6UMseOx001349@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UMscEh001316 for ; Wed, 30 Jul 2003 18:54:38 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6UMsbvx025806 for ; Wed, 30 Jul 2003 18:54:37 -0400 Received: (qmail 9833 invoked by uid 65534); 30 Jul 2003 22:54:11 -0000 Received: from p3EE2475A.dip.t-dialin.net (HELO lisa) (62.226.71.90) by mail.gmx.net (mp002) with SMTP; 31 Jul 2003 00:54:11 +0200 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: Date: Thu, 31 Jul 2003 00:53:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C356FE.2E49B450" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1), X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEFMIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7760 X-Loop: 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: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C356FE.2E49B450 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I guess we need to distinguish two cases: - a PROPPATCH that indeed changes the result of a subsequent GET -- this is a perfectly legal implementation, and I think nobody claims that if a PROPPATCH changes what GET returns the etag shouldn't change as well -- thus: a PROPPATCH MAY change the etag if it changes the content as well, - a PROPPATCH that does not affect the GETtable content -- I'm tempted to agree that this SHOULD NOT change the etag. The other issue was whether once we require this for etags, do we *also* need to require it for getlastmodified? My concern here is that once we normatively de-couple DAV:getlastmodified from property changes, there's no standard date property left that a client could use to monitor *any* state changes of the resource (which I think would be a really useful thing to have). So if RFC2518bis changes the requirements for DAV:getlastmodified, this should *at least* appear in the issues list and should properly discussed on the mailing list. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Wednesday, July 30, 2003 11:59 PM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1), > > I vote for the wording that is in there. I think we've already reached > > consensus that changing property values should not be changing etags. > > Where and when? Sorry. I don't have a particular posting that declares consensus. It was just what I heard over and over again in postings. People seemed comfortable declaring that changing properties should not change ETags. There was no significant opposition to it that I recall. The issues list lists... http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html But I seem to recall that it was discussed more often than this. As you (and Geoff in the referenced page) point out, some products will become incompatible with 2518bis. I believe people were aware of this, but if they were not, you've just pointed it out. They should speak up... J. ------=_NextPart_000_000B_01C356FE.2E49B450 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I guess we need to distinguish two cases:
 
- a PROPPATCH that indeed changes the result of a subsequent = GET --=20 this is a perfectly legal implementation, and I think nobody claims that = if a=20 PROPPATCH changes what GET returns the etag shouldn't change as well -- = thus: a=20 PROPPATCH MAY change the etag if it changes the content as=20 well,
 
- a PROPPATCH that does not affect the GETtable content -- I'm = tempted to=20 agree that this SHOULD NOT change the etag.
 
The other issue was whether once we require this for etags, do = we *also*=20 need to require it for getlastmodified? My concern here is that once we=20 normatively de-couple DAV:getlastmodified from property changes, there's = no=20 standard date property left that a client could use to monitor *any* = state=20 changes of the resource (which I think would be a really useful thing to = have).
 
So if RFC2518bis changes the requirements for = DAV:getlastmodified, this=20 should *at least* appear in the issues list and should properly = discussed on the=20 mailing list.
 
 
Julian
 

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

-----Original Message-----
From: Jason Crawford=20 [mailto:nn683849@smallcue.com]
Sent: Wednesday, July 30, = 2003 11:59=20 PM
To: Julian Reschke
Cc:=20 w3c-dist-auth@w3.org
Subject: RE: Etags changing on property = value=20 changes, WAS: rfc2518-bis-04 issues (part = 1),


> > I vote for the wording that is in = there.=20  I think we've already reached
> > consensus that = changing=20 property values should not be changing etags.
>
> Where = and=20 when?

Sorry.  I = don't have a=20 particular posting that declares consensus.  It was =
just what I heard over and over again in = postings.=20  People seemed
comfortable=20 declaring that changing properties should not change ETags. =  =20
There was no significant = opposition to it=20 that I recall.

The = issues list=20 lists...

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/006= 7.html=20

But I seem to recall that it = was=20 discussed more often than this.

As=20 you (and Geoff in the referenced page) point out, some products = will=20
become incompatible with 2518bis. =   I=20 believe people were aware of this,
but=20 if they were not, you've just pointed it out.  They should speak=20 up...

J.=20
------=_NextPart_000_000B_01C356FE.2E49B450-- From w3c-dist-auth-request@w3.org Wed Jul 30 19:38: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 TAA23432 for ; Wed, 30 Jul 2003 19:38: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 h6UNcnEh006860; Wed, 30 Jul 2003 19:38:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h6UNch6H006836; Wed, 30 Jul 2003 19:38:43 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 19:38:43 -0400 (EDT) Resent-Message-Id: <200307302338.h6UNch6H006836@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UNcgEh006803 for ; Wed, 30 Jul 2003 19:38:42 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UNcfvx003418 for ; Wed, 30 Jul 2003 19:38:41 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h6UNcaO17871 for ; Wed, 30 Jul 2003 16:38:38 -0700 (PDT) Message-ID: <3F2856FB.8010608@cse.ucsc.edu> Date: Wed, 30 Jul 2003 16:38:35 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: multipart/alternative; boundary="------------090905070603000307030507" Subject: Re: rfc2518-bis-04 issues (part 1) X-Archived-At: http://www.w3.org/mid/3F2856FB.8010608@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7761 X-Loop: 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: --------------090905070603000307030507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Julian Reschke wrote: >>> 03-C17: >>> >>>8.1.5.: "Because clients may be forced to prompt users or throw away changed >>> >>> >>>content if the ETag changes, a WebDAV server MUST not change the ETag (or >>> >>> >>>getlastmodified value) for a resource when only its property values change." >>> >>> >>>Some servers do, and I don't think we can change that. Therefore I think >>>this change at least needs explicit consensus on the mailing list. >>> >>> >> I vote for the wording that is in there. I think we've already reached consensus that changing property values should not be changing etags. >> >> > > Where and when? > While I had agreed with Jason and thought that there had been some concensus on this, an exhaustive search of the mailing list archives has not backed this up. I is entirely likely that I was misremembering the consensus that had been reached regarding the inclusion of stronger ETag requirements in 2518bis. That being said, however, there has been a fair amount of discussion around this very issue and the majority opinion seems to be in favor of this interpretation... (more below). As an aside, after reading through the previous discussions, I now firmly believe that the specification of a property tag, PTag, would put this issue soundly to rest. The idea has been brought up before, and I think it deserves consideration. >> I also believe that there was already concensus re: property values not affecting ETags... Since doing a PUT of a resource doesn't affect properties >>and a GET doesn't retrieve properties, the ETag should not change when properties on a resource do. That is to say that ETags should only be >> >> > That's simply not true. You're argueing from a world view where the server stores properties and content as separate entities. However, it's perfectly >legal to have a server that > >- extracts some properties upon PUT (for instance metadata from a WORD >document) and/or >- changes the content upon PROPPATCH of one of the aforementioned >properties. > >I think that we can't and shouldn't make this behaviour illegal. > No, implementation issues aside (that is, I don't care how a server stores properties as it is orthogonal to my position), ETags as defined in RFC 2616 have nothing to do with WebDAV properties. The fact that resources have subsequently been defined as having properties doesn't change this fact. More to the point, the WebDAV specification should not change the definition or semantic properties of ETags. Let us, however, consider existing implementations where resource properties are stored as the same blob of bits as the resource entity. This situation does not imply that changing a property of a resource entails changing it's ETag. In this case, the server must know how to seperate the two when responding to a GET or PROPFIND request and is perfectly capable of modifying the ETag without taking property values into consideration. The fact that RFC 2518 doesn't treat this matter directly has certainly complicated the issue for implementors, as evidenced by the different approaches that server implementations have taken in generating ETags. The two points you raise above are red herrings, if you ask me. In the first case you have stipulated that the client has done a PUT which affects some properties. This is, as you identify, a valid case for generating a new ETag, but this is simply because the client has done a PUT, not because of any property value(s) changing (i.e. you have refuted my assertion that a PUT won't change properties, but not provided a compelling reason why changing properties alone should affect the ETag). In the second case you state that modifying some special properties may change the content of the resource. Again, I think this is a valid case for generating a new ETag, but not due to the property changing but because the resource contents have changed. In short, this is similar to doing a PUT and modifying the resource itself although it is accomplished via a PROPPATCH instead. In short, my argument is this: ETags should only change when the contents of a resource change (e.g. when the entity itself changes). Generating strong ETags doesn't place an undue burden on server resources and neither does detecting when the actual contents of a resource have changed by any means. There will be some frustrations in updating existing server code to be compliant if we take a firm stand on this issue but, in the long run, the benefits to clients far outweigh any drawbacks. The alternative is to have different server implementations of ETags and, as a consequence, balkanizing the interoperability of clients and servers. Apologies for the long wind, I feel this particular issue is quite important and deserving of a thorough treatment on the road to consensus. Cheers, Elias --------------090905070603000307030507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Reschke wrote:

  

  

    

      
<Julian Reschke> 03-C17:

8.1.5.: "Because clients may be forced to prompt users or throw away changed
      

    

    

      
content if the ETag changes, a WebDAV server MUST not change the  ETag (or
      

    

    

      
getlastmodified value) for a resource when only its property values change."
      

    

    

      
Some servers do, and I don't think we can change that. Therefore I think
this change at least needs explicit consensus on the mailing list.
      

    

    
<Jason Crawford> I vote for the wording that is in there.  I think we've already reached consensus that changing property values should not be changing etags.
    

  

  

<Julian Reschke> Where and when?



While I had agreed with Jason and thought that there had been some concensus
on this, an exhaustive search of the mailing list archives has not backed
this up. I is entirely likely that I was misremembering the consensus that
had been reached regarding the inclusion of stronger ETag requirements in
2518bis.



That being said, however, there has been a fair amount of discussion around
this very issue and the majority opinion seems to be in favor of this interpretation...
(more below). As an aside, after reading through the previous discussions,
I now firmly believe that the specification of a property tag, PTag, would
put this issue soundly to rest. The idea has been brought up before, and
I think it deserves consideration.



  

    
<Elias Sinderson> I also believe that there was already concensus re: property values not affecting ETags... Since doing a PUT of a resource doesn't affect properties
and a GET doesn't retrieve properties, the ETag should not change when properties on a resource do. That is to say that ETags should only be
    

  

  
<Julian Reschke> That's simply not true. You're argueing from a world view where the server stores properties and content as separate entities. However, it's perfectly
legal to have a server that

- extracts some properties upon PUT (for instance metadata from a WORD
document) and/or
- changes the content upon PROPPATCH of one of the aforementioned
properties.

I think that we can't and shouldn't make this behaviour illegal.



No, implementation issues aside (that is, I don't care how a server stores
properties as it is orthogonal to my position), ETags as defined in RFC 2616
have nothing to do with WebDAV properties. The fact that resources have subsequently
been defined as having properties doesn't change this fact. More to the point,
the WebDAV specification should not change the definition or semantic properties
of ETags.



Let us, however, consider existing implementations where resource properties
are stored as the same blob of bits as the resource entity. This situation
does not imply that changing a property of a resource entails changing it's
ETag. In this case, the server must know how to seperate the two when responding
to a GET or PROPFIND request and is perfectly capable of modifying the ETag
without taking property values into consideration. The fact that RFC 2518
doesn't treat this matter directly has certainly complicated the issue for
implementors, as evidenced by the different approaches that server implementations
have taken in generating ETags.



The two points you raise above are red herrings, if you ask me. In the first
case you have stipulated that the client has done a PUT which affects some
properties. This is, as you identify, a valid case for generating a new ETag,
but this is simply because the client has done a PUT, not because of any
property value(s) changing (i.e. you have refuted my assertion that a PUT
won't change properties, but not provided a compelling reason why changing
properties alone should affect the ETag).



In the second case you state that modifying some special properties may change
the content of the resource. Again, I think this is a valid case for generating
a new ETag, but not due to the property changing but because the resource
contents have changed. In short, this is similar to doing a PUT and modifying
the resource itself although it is accomplished via a PROPPATCH instead.



In short, my argument is this: ETags should only change when the contents
of a resource change (e.g. when the entity itself changes). Generating strong
ETags doesn't place an undue burden on server resources and neither does
detecting when the actual contents of a resource have changed by any means.
There will be some frustrations in updating existing server code to be compliant
if we take a firm stand on this issue but, in the long run, the benefits
to clients far outweigh any drawbacks. The alternative is to have different
server implementations of ETags and, as a consequence, balkanizing the interoperability
of clients and servers.



Apologies for the long wind, I feel this particular issue is quite important
and deserving of a thorough treatment on the road to consensus.





Cheers,

Elias




--------------090905070603000307030507--



From w3c-dist-auth-request@w3.org  Wed Jul 30 19:54:55 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 TAA24150
	for ; Wed, 30 Jul 2003 19:54: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 h6UNsuEh008221;
	Wed, 30 Jul 2003 19:54:57 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6UNsrSM008196;
	Wed, 30 Jul 2003 19:54:53 -0400 (EDT)
Resent-Date: Wed, 30 Jul 2003 19:54:53 -0400 (EDT)
Resent-Message-Id: <200307302354.h6UNsrSM008196@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6UNspEh008159
	for ; Wed, 30 Jul 2003 19:54:51 -0400 (EDT)
Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6UNsovx007221
	for ; Wed, 30 Jul 2003 19:54:51 -0400
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h6UNsoO17928
	for ; Wed, 30 Jul 2003 16:54:50 -0700 (PDT)
Message-ID: <3F285ACA.5000000@cse.ucsc.edu>
Date: Wed, 30 Jul 2003 16:54:50 -0700
From: Elias Sinderson 
Reply-To: w3c-dist-auth@w3.org
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: 
Content-Type: multipart/alternative;
 boundary="------------080202070300000109000608"
Subject: Re: Etags changing on property value changes, WAS: rfc2518-bis-04  issues (part 1),
X-Archived-At: http://www.w3.org/mid/3F285ACA.5000000@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7762
X-Loop: 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: 



--------------080202070300000109000608
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julian Reschke wrote:

> I guess we need to distinguish two cases:
>  
> - a PROPPATCH that indeed changes the result of a subsequent GET -- 
> this is a perfectly legal implementation, and I think nobody claims 
> that if a PROPPATCH changes what GET returns the etag shouldn't change 
> as well -- thus: a PROPPATCH MAY change the etag if it changes the 
> content as well,
>  
> - a PROPPATCH that does not affect the GETtable content -- I'm tempted 
> to agree that this SHOULD NOT change the etag.

I think we're converging on this...

> The other issue was whether once we require this for etags, do we 
> *also* need to require it for getlastmodified? My concern here is that 
> once we normatively de-couple DAV:getlastmodified from property 
> changes, there's no standard date property left that a client could 
> use to monitor *any* state changes of the resource (which I think 
> would be a really useful thing to have).

If clients can rely upon ETags not changing unless the GETable content 
has changed, then there is no reason to depend on DAV:getlastmodified 
for this. Furthermore, if this were the case, the notion of a PTag is 
superfluous as a client could simply check that the ETag hasn't changed 
while the DAV:getlastmodified value had...

> So if RFC2518bis changes the requirements for DAV:getlastmodified, 
> this should *at least* appear in the issues list and should properly 
> discussed on the mailing list.

Agreed.


Cheers,
Elias


--------------080202070300000109000608
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  


Julian Reschke wrote:


  
  
 
  
 
  
I guess we need to distinguish two cases:

 
  
 

 
  
- a PROPPATCH that indeed changes the result of
a subsequent GET --  this is a perfectly legal implementation, and I think
nobody claims that if a  PROPPATCH changes what GET returns the etag shouldn't
change as well -- thus: a  PROPPATCH MAY change the etag if it changes the
content as  well,

 
  
 

 
  
- a PROPPATCH that does not affect the GETtable
content -- I'm tempted to  agree that this SHOULD NOT change the etag.



I think we're converging on this...


 
  
 The other issue was whether once we require this for etags, do
we *also*  need to require it for getlastmodified? My concern here is that
once we  normatively de-couple DAV:getlastmodified from property changes,
there's no  standard date property left that a client could use to monitor
*any* state  changes of the resource (which I think would be a really useful
thing to  have).



If clients can rely upon ETags not changing unless the GETable content has
changed, then there is no reason to depend on DAV:getlastmodified for this.
Furthermore, if this were the case, the notion of a PTag is superfluous as
a client could simply check that the ETag hasn't changed while the DAV:getlastmodified
value had...


  
  
So if RFC2518bis changes the requirements for DAV:getlastmodified,
this  should *at least* appear in the issues list and should properly discussed
on the  mailing list.



Agreed.





Cheers,

Elias






--------------080202070300000109000608--



From w3c-dist-auth-request@w3.org  Thu Jul 31 00:55:04 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 AAA29455
	for ; Thu, 31 Jul 2003 00:55:04 -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 h6V4t7Eh012983;
	Thu, 31 Jul 2003 00:55:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6V4sfiM012732;
	Thu, 31 Jul 2003 00:54:41 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 00:54:41 -0400 (EDT)
Resent-Message-Id: <200307310454.h6V4sfiM012732@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6V4sdEh012699
	for ; Thu, 31 Jul 2003 00:54:39 -0400 (EDT)
Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6V4sdvx026767
	for ; Thu, 31 Jul 2003 00:54:39 -0400
Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161])
	by mtaw4.prodigy.net (8.12.9/8.12.3) with ESMTP id h6V4sb1e029840
	for ; Wed, 30 Jul 2003 21:54:37 -0700 (PDT)
Message-ID: <3F28A091.8060702@cse.ucsc.edu>
Date: Wed, 30 Jul 2003 21:52:33 -0700
From: Elias Sinderson 
Reply-To: w3c-dist-auth@w3.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: 
Content-Type: multipart/alternative;
 boundary="------------020803020204060705090405"
Subject: URI scheme uniqueness   (was Re: rfc2518-bis-04 issues (part 2))
X-Archived-At: http://www.w3.org/mid/3F28A091.8060702@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7763
X-Loop: 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: 



--------------020803020204060705090405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julian Reschke wrote:

>>> 02-C05 Section 6.3, p3
>>>Replace
>>>"However resources are free to return any URI scheme so long as it meets the
>>>      
>>>
>>>uniqueness requirements."
>>>by
>>>"However servers are free to use any IETF-registered URI scheme so long as
>>>      
>>>
>>>it meets the uniqueness requirements."
>>>(If it's not IETF-registered, I don't see how it can possibly meet the
>>>uniqueness criterium).
>>>      
>>>
>> I'd vote to leave the text as it is.
>>    
>>
> Again, please help me understand...:
>
>1) Are you suggesting that to for a scheme to be IETF-registered is not a
>requirement? In which case I'll argue that by definition there can't be any
>uniquess guarantee otherwise.
>
 It's a given that any IETF-registered URI scheme will 
meet the stated uniqueness requirements. I don't believe that it is the 
only way to do so, however. For example, private intranets may utilize 
their own, homegrown system to guarantee uniquenes. It's also entirely 
possible that, in the distant future, there may be alternative means to 
accomplish this on the public internet. Perhaps something along the 
lines of the following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated 
uniqueness requirements. One way to accomplish this is to use 
IETF-registered URI schemes."

This language seems specific enough to be unambiguous while flexible 
enough to allow for other mechanisms to ensure uniqueness. The drawback 
of not taking a firmer position on this is that it opens the possibility 
that someone will implement some half-baked idea and it won't meet the 
necessary requirements...


Cheers,
Elias

--------------020803020204060705090405
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Julian Reschke wrote:



  

    

    

      
<Julian Reschke> 02-C05 Section 6.3, p3
Replace
"However resources are free to return any URI scheme so long as it meets the
      

    

  

  

    

      
uniqueness requirements."
by
"However servers are free to use any IETF-registered URI scheme so long as
      

    

  

  

    

      
it meets the uniqueness requirements."
(If it's not IETF-registered, I don't see how it can possibly meet the
uniqueness criterium).
      

    

    
<Jason Crawford> I'd vote to leave the text as it is.
    

  

  
<Julian Reschke> Again, please help me understand...:

1) Are you suggesting that to for a scheme to be IETF-registered is not a
requirement? In which case I'll argue that by definition there can't be any
uniquess guarantee otherwise.



<Elias Sinderson> It's a given that any IETF-registered URI scheme
will meet the stated uniqueness requirements. I don't believe that it is
the only way to do so, however. For example, private intranets may utilize
their own, homegrown system to guarantee uniquenes. It's also entirely possible
that, in the distant future, there may be alternative means to accomplish
this on the public internet. Perhaps something along the lines of the following
would be acceptable?



"...are free to use any URI scheme so long as it meets the stated uniqueness
requirements. One way to accomplish this is to use IETF-registered URI schemes."



This language seems specific enough to be unambiguous while flexible enough
to allow for other mechanisms to ensure uniqueness. The drawback of not taking
a firmer position on this is that it opens the possibility that someone will
implement some half-baked idea and it won't meet the necessary requirements...





Cheers,

Elias




--------------020803020204060705090405--



From w3c-dist-auth-request@w3.org  Thu Jul 31 02:52:09 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 CAA13684
	for ; Thu, 31 Jul 2003 02:52:09 -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 h6V6qBEh011317;
	Thu, 31 Jul 2003 02:52:11 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6V6q4ID011268;
	Thu, 31 Jul 2003 02:52:04 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 02:52:04 -0400 (EDT)
Resent-Message-Id: <200307310652.h6V6q4ID011268@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6V6q2Eh011227
	for ; Thu, 31 Jul 2003 02:52:02 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6V6q1vx028030
	for ; Thu, 31 Jul 2003 02:52:01 -0400
Received: (qmail 3148 invoked by uid 65534); 31 Jul 2003 06:51:39 -0000
Received: from p3EE24825.dip.t-dialin.net (HELO lisa) (62.226.72.37)
  by mail.gmx.net (mp025) with SMTP; 31 Jul 2003 08:51:39 +0200
From: "Julian Reschke" 
To: 
Date: Thu, 31 Jul 2003 08:51: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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3F28A091.8060702@cse.ucsc.edu>
Importance: Normal
Subject: RE: URI scheme uniqueness   (was Re: rfc2518-bis-04 issues (part 2))
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEGGIAAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7764
X-Loop: 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 Elias Sinderson
> Sent: Thursday, July 31, 2003 6:53 AM
> To: w3c-dist-auth@w3.org
> Subject: URI scheme uniqueness (was Re: rfc2518-bis-04 issues (part 2))
>
>
> Julian Reschke wrote:
>
>
>  02-C05 Section 6.3, p3
> Replace
> "However resources are free to return any URI scheme so long as it meets
the
> uniqueness requirements."
> by
> "However servers are free to use any IETF-registered URI scheme so long as
> it meets the uniqueness requirements."
> (If it's not IETF-registered, I don't see how it can possibly meet the
> uniqueness criterium).
>
>  I'd vote to leave the text as it is.
>
>  Again, please help me understand...:
>
> 1) Are you suggesting that to for a scheme to be IETF-registered is not a
> requirement? In which case I'll argue that by definition there
> can't be any
> uniquess guarantee otherwise.
>  It's a given that any IETF-registered URI  scheme will
meet
> the stated uniqueness requirements. I don't believe that it is  the only
way

That's not a given. For instance, "file:///abc" or "dav:foobar" make very
poor lock tokens, although the URI schemes are IETF-registered.

> to do so, however. For example, private intranets may utilize their own,
> homegrown system to guarantee uniquenes. It's also entirely possible that,

Not true, unless your private intranet indeed isn't (and never will be)
connect to the public internet (in which case I really don't care :-). A
client may talk with two distinct "homegrown" systems at the same time.
RFC2518 requires that it will never ever see the same lock token twice. If
these systems do not use an IETF-registered URI scheme, there's simply no
way to guarantee this.

> in the distant future, there may be alternative means to
> accomplish this on
> the public internet. Perhaps something along the lines of the following
> would be acceptable?
>
> "...are free to use any URI scheme so long as it meets the stated
> uniqueness
> requirements. One way to accomplish this is to use IETF-registered URI
> schemes."

That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness criterium.

> This language seems specific enough to be unambiguous while
> flexible enough
> to allow for other mechanisms to ensure uniqueness. The drawback of not

See, this kind of proves that the spec needs to be enhanced. You and others
seem to read it as a license to come up with "private" URI schemes, which is
plainly wrong and breaks the uniqueness requirements. Therefore the text
should be clarified.

> taking a firmer position on this is that it opens the possibility that
> someone will implement some half-baked idea and it won't meet the
> necessary
> requirements...

Absolutely.

Can you provide an example that wouldn't be "half-baked"? My point being,
unless you register the scheme, nobody is guaranteeing uniqueness, so it is
soft of "half-baked" automatically.

Another question: why are people fighting against this requirement? There
are tons of simply ways to produce lock tokens that meet all the criteria,
one of which is the opaquelocktoken scheme. I really don't see what's so
attractive about inventing new schemes to do the same thing.


Julian


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



From w3c-dist-auth-request@w3.org  Thu Jul 31 03:13: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 DAA14063
	for ; Thu, 31 Jul 2003 03:13: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 h6V7DiEh013598;
	Thu, 31 Jul 2003 03:13:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6V7DfwK013559;
	Thu, 31 Jul 2003 03:13:41 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 03:13:41 -0400 (EDT)
Resent-Message-Id: <200307310713.h6V7DfwK013559@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6V7DeEh013524
	for ; Thu, 31 Jul 2003 03:13:40 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6V7Dcvx032442
	for ; Thu, 31 Jul 2003 03:13:39 -0400
Received: (qmail 13402 invoked by uid 65534); 31 Jul 2003 07:13:24 -0000
Received: from p3EE24825.dip.t-dialin.net (HELO lisa) (62.226.72.37)
  by mail.gmx.net (mp004) with SMTP; 31 Jul 2003 09:13:24 +0200
From: "Julian Reschke" 
To: 
Date: Thu, 31 Jul 2003 09:13: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.1165
In-Reply-To: <3F2856FB.8010608@cse.ucsc.edu>
Importance: Normal
Subject: properties vs entity body, was: rfc2518-bis-04 issues (part 1)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEGIIAAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7765
X-Loop: 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 Elias Sinderson
> Sent: Thursday, July 31, 2003 1:39 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: rfc2518-bis-04 issues (part 1)
>
> ...
>
> No, implementation issues aside (that is, I don't care how a server stores
> properties as it is orthogonal to my position), ETags as defined
> in RFC 2616
> have nothing to do with WebDAV properties. The fact that resources have
> subsequently been defined as having properties doesn't change this fact.
> More to the point, the WebDAV specification should not change the
> definition
> or semantic properties of ETags.

I didn't propose that. However, if you look at RFC2616 you will note that it
really doesn't say that the ETag MUST NOT change unless the entity changes.
It only defines the other direction (the etag must change if the entity
changes).

> Let us, however, consider existing implementations where resource
> properties
> are stored as the same blob of bits as the resource entity. This situation
> does not imply that changing a property of a resource entails
> changing it's
> ETag. In this case, the server must know how to seperate the two when
> responding to a GET or PROPFIND request and is perfectly capable of
> modifying the ETag without taking property values into consideration. The
> fact that RFC 2518 doesn't treat this matter directly has certainly
> complicated the issue for implementors, as evidenced by the different
> approaches that server implementations have taken in generating ETags.

Actually, the case I raised is the one where properties are *extracted* from
the content, *stay* in the content and the content is *updated* when
PROPPATCH is applied.

For instance, (upon PUT) a server might use the HTML Meta tag to extract a
"foo:author" property and expose that as DAV property (making it available
for DAV:basicsearch...). Applying PROPPATCH to this property would affect
the content that you'll get upon a subsequent GET as well.

Now if you tell me that this behaviour is non-compliant we are in deep
disagreement about WebDAV. I understand that many see WebDAV simply as a
drop-in for filesystems or FTP. This is just one use-case, but there are
other scenarios that RFC2616 and RFC2518 explicitly allow.

> The two points you raise above are red herrings, if you ask me.
> In the first
> case you have stipulated that the client has done a PUT which affects some
> properties. This is, as you identify, a valid case for generating a new
> ETag, but this is simply because the client has done a PUT, not because of

No, it may affect any number of properties that are protected on that
particular server.

> any property value(s) changing (i.e. you have refuted my assertion that a
> PUT won't change properties, but not provided a compelling reason why
> changing properties alone should affect the ETag).
>
> In the second case you state that modifying some special properties may
> change the content of the resource. Again, I think this is a
> valid case for
> generating a new ETag, but not due to the property changing but
> because the
> resource contents have changed. In short, this is similar to
> doing a PUT and
> modifying the resource itself although it is accomplished via a PROPPATCH
> instead.
>
> In short, my argument is this: ETags should only change when the
> contents of
> a resource change (e.g. when the entity itself changes). Generating strong

OK, let's make that very clear: ETags SHOULD not change unless the content
changes. *However*, it's completely up to the server *which* methods affect
the content. For instance (in the case mentioned above), a PROPPATCH/set to
foo:author may affect the META/name=author tag in the HTML content that you
GET.

> ETags doesn't place an undue burden on server resources and neither does
> detecting when the actual contents of a resource have changed by
> any means.

I think that's a separate dicussion. We still don't have any feedback from
the two major WebDAV implementions (moddav and IIS) about whether they plan
to implement this according to RFC2518bis.

> There will be some frustrations in updating existing server code to be
> compliant if we take a firm stand on this issue but, in the long run, the
> benefits to clients far outweigh any drawbacks. The alternative is to have
> different server implementations of ETags and, as a consequence,
> balkanizing
> the interoperability of clients and servers.

Well the alternative obviously is not to change the requirement, and to keep
things as they are right now. I'm not convinced the current situation is so
bad we need to break compatibility with both RFC2518 and lots of existing
servers.

> Apologies for the long wind, I feel this particular issue is
> quite important
> and deserving of a thorough treatment on the road to consensus.

Yes.


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



From w3c-dist-auth-request@w3.org  Thu Jul 31 03:31: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 DAA14603
	for ; Thu, 31 Jul 2003 03:31:11 -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 h6V7V4Eh016237;
	Thu, 31 Jul 2003 03:31:04 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6V7V22a016219;
	Thu, 31 Jul 2003 03:31:02 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 03:31:02 -0400 (EDT)
Resent-Message-Id: <200307310731.h6V7V22a016219@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6V7V1Eh016186
	for ; Thu, 31 Jul 2003 03:31:01 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6V7Uxvx003006
	for ; Thu, 31 Jul 2003 03:31:00 -0400
Received: from greenbytes.de ([192.168.1.23])
	by greenbytes.de (greenbytes.de [217.5.201.11])
	(MDaemon.PRO.v6.8.4.R)
	with ESMTP id 35-md50000000035.tmp
	for ; Thu, 31 Jul 2003 09:30:44 +0200
Date: Thu, 31 Jul 2003 09:30:46 +0200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Julian Reschke" , w3c-dist-auth@w3.org
To: Jason Crawford 
From: Stefan Eissing 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.552)
X-Spam-Processed: greenbytes.de, Thu, 31 Jul 2003 09:30:44 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h6V7V1Eh016186
Subject: Re: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1),
X-Archived-At: http://www.w3.org/mid/E6B120C2-C328-11D7-A5FF-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7766
X-Loop: 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: 8bit



What I  recall from the discussions is that we do not want the ETag or
getlastmodified to change when the content of the resource stays
as it is.

Some people had the notion that ETag/lasmodified needed to change
on PROPPATCH and that is definitely not desired. However iff upon
PROPPATCH the content of a resource also changes, the ETag MUST
change.

So, saying that PROPPATCH MUST not change the ETag is not what
we want.

What the intention of our consensus-reaching discussion was is:

PROPPATCH on a resource SHOULD NOT modifiy the ETag/getlastmodified
live properties unless the content/representation of the resource
changes as well. On content changes ETag/getlastmodified MUST
change as already required by HTTP/1.1 (RFC2616).

This issue is not heavy enough to render existing implementations
non-compliant. One can look at it as a word of advise to server
implementors in order to improve HTTP caching performance.

//Stefan

Am Mittwoch, 30.07.03, um 23:58 Uhr (Europe/Berlin) schrieb Jason 
Crawford:

>
> > > I vote for the wording that is in there.  I think we've already 
> reached
> > > consensus that changing property values should not be changing 
> etags.
> >
> > Where and when?
>
> Sorry.  I don't have a particular posting that declares consensus.  It 
> was
> just what I heard over and over again in postings.  People seemed
> comfortable declaring that changing properties should not change 
> ETags.  
> There was no significant opposition to it that I recall.
>
> The issues list lists...
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html
>
> But I seem to recall that it was discussed more often than this.
>
> As you (and Geoff in the referenced page) point out, some products will
> become incompatible with 2518bis.   I believe people were aware of 
> this,
> but if they were not, you've just pointed it out.  They should speak 
> up...
>
> J.





From w3c-dist-auth-request@w3.org  Thu Jul 31 09:20:31 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 JAA24512
	for ; Thu, 31 Jul 2003 09:20: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 h6VDIEEh019228;
	Thu, 31 Jul 2003 09:18:14 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6VDI28R019184;
	Thu, 31 Jul 2003 09:18:02 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 09:18:02 -0400 (EDT)
Resent-Message-Id: <200307311318.h6VDI28R019184@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6VDI0Eh019133
	for ; Thu, 31 Jul 2003 09:18:00 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6VDHxvx024244
	for ; Thu, 31 Jul 2003 09:17:59 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id h6VDHw322904; Thu, 31 Jul 2003 15:17:58 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19)
	id <3GBNMH54>; Thu, 31 Jul 2003 15:17:57 +0200
Message-ID: 
From: "Nevermann, Dr., Peter" 
To: "'w3c-dist-auth@w3.org'" 
Date: Thu, 31 Jul 2003 15:17:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C35766.25028A30"
Subject: BIND: 
X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47FBF@daemsg02.software-ag.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7767
X-Loop: 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: 


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C35766.25028A30
Content-Type: text/plain;
	charset="iso-8859-1"

The BIND spec (draft-ietf-webdav-bind-02) states at 3.1 DAV:resource-id
property:

"The value of DAV:resource-id is a URI, and may use any registered URI
scheme that guarantees the uniqueness of the value across all resources for
all time (e.g. the opaquelocktoken: scheme defined in [RFC2518])."

I found registered URI schemes at:
http://www.iana.org/assignments/uri-schemes. So, can I choose one of them,
e.g. urn: ? Or should I invent my own? :-)

Why doesn't the BIND spec define the URI scheme to be used?

Thanks,
Peter

------_=_NextPart_001_01C35766.25028A30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






BIND: 




The BIND spec (draft-ietf-webdav-bind-02) states at =
3.1 DAV:resource-id property:




"The value of DAV:resource-id is a URI, and may =
use any registered URI scheme that guarantees the uniqueness of the =
value across all resources for all time (e.g. the opaquelocktoken: =
scheme defined in [RFC2518])."



I found registered URI schemes at: http://www.iana.org/assignments/uri-schemes. So, =
can I choose one of them, e.g. urn: ? Or should I invent my own? =
:-)



Why doesn't the BIND spec define the URI scheme to be =
used?




Thanks,

Peter





------_=_NextPart_001_01C35766.25028A30--



From w3c-dist-auth-request@w3.org  Thu Jul 31 09:38: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 JAA25161
	for ; Thu, 31 Jul 2003 09:38:49 -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 h6VDcpEh023025;
	Thu, 31 Jul 2003 09:38:51 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.12.9/8.12.9/Submit) id h6VDcjRN022975;
	Thu, 31 Jul 2003 09:38:45 -0400 (EDT)
Resent-Date: Thu, 31 Jul 2003 09:38:45 -0400 (EDT)
Resent-Message-Id: <200307311338.h6VDcjRN022975@frink.w3.org>
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (8.12.9/8.12.9) with ESMTP id h6VDchEh022939
	for ; Thu, 31 Jul 2003 09:38:43 -0400 (EDT)
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h6VDcgvx029074
	for ; Thu, 31 Jul 2003 09:38:43 -0400
Received: (qmail 30388 invoked by uid 65534); 31 Jul 2003 13:38:35 -0000
Received: from unknown (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp015) with SMTP; 31 Jul 2003 15:38:35 +0200
From: "Julian Reschke" 
To: "Nevermann, Dr., Peter" ,
        
Date: Thu, 31 Jul 2003 15:38:31 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C35779.CB8360B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: RE: BIND: 
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEHHIAAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List:  archive/latest/7768
X-Loop: 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: 


This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C35779.CB8360B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

BIND:Hi.

You can use a URN: scheme if you find one that satisifies the uniqueness
constraints. You could also register your own URN NID and come up with a
custom scheme.

I personally would recommend just to use the RFC2518 "opaquelocktoken"
scheme because it already has what you need.

Finally, the BIND spec isn't defining a new scheme for the simple reason we
don't need one.

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 Nevermann, Dr., Peter
  Sent: Thursday, July 31, 2003 3:18 PM
  To: 'w3c-dist-auth@w3.org'
  Subject: BIND:


  The BIND spec (draft-ietf-webdav-bind-02) states at 3.1 DAV:resource-id
property:

  "The value of DAV:resource-id is a URI, and may use any registered URI
scheme that guarantees the uniqueness of the value across all resources for
all time (e.g. the opaquelocktoken: scheme defined in [RFC2518])."

  I found registered URI schemes at:
http://www.iana.org/assignments/uri-schemes. So, can I choose one of them,
e.g. urn: ? Or should I invent my own? :-)

  Why doesn't the BIND spec define the URI scheme to be used?

  Thanks,
  Peter

------=_NextPart_000_002F_01C35779.CB8360B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


BIND:




Hi.


 


You can use a URN: scheme if you find one that satisifies the =
uniqueness=20
constraints. You could also register your own URN NID and come up with a =
custom=20
scheme.


 


I personally would recommend just to use the RFC2518 =
"opaquelocktoken"=20
scheme because it already has what you need.


 


Finally, the BIND spec isn't defining a new scheme for the =
simple reason=20
we don't need one.


 


Julian


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



  
-----Original Message-----
From: =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, =
Dr.,=20
  Peter
Sent: Thursday, July 31, 2003 3:18 PM
To:=20
  'w3c-dist-auth@w3.org'
Subject: BIND: 


  
The BIND spec (draft-ietf-webdav-bind-02) states at =
3.1=20
  DAV:resource-id property: 

  
"The value of DAV:resource-id is a URI, and may use =
any=20
  registered URI scheme that guarantees the uniqueness of the value =
across all=20
  resources for all time (e.g. the opaquelocktoken: scheme defined in=20
  [RFC2518])."

  
I found registered URI schemes at: http://www.iana.org/assignments/uri-schemes. So, =
can I=20
  choose one of them, e.g. urn: ? Or should I invent my own? =
:-)

  
Why doesn't the BIND spec define the URI scheme to =
be=20
  used? 

  
Thanks, 
Peter=20



------=_NextPart_000_002F_01C35779.CB8360B0--