From w3c-dist-auth-request@w3.org Wed Oct 1 11:01: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 LAA16863 for ; Wed, 1 Oct 2003 11:01:19 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7A64FA0B4A; Wed, 1 Oct 2003 11:01:10 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BD0B1A0B62 for ; Wed, 1 Oct 2003 11:01:05 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A93D51396B; Wed, 1 Oct 2003 10:58:36 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id DAB6813935 for ; Wed, 1 Oct 2003 10:58:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16679; Wed, 1 Oct 2003 10:58:28 -0400 (EDT) Message-Id: <200310011458.KAA16679@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, 01 Oct 2003 10:58:28 -0400 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-05.txt X-Archived-At: http://www.w3.org/mid/200310011458.KAA16679@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7922 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031001150110.7A64FA0B4A@frink.w3.org> Resent-Date: Wed, 1 Oct 2003 11:01:10 -0400 (EDT) --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 Filename : draft-ietf-webdav-redirectref-protocol-05.txt Pages : 61 Date : 2003-10-1 This 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. 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-05.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-05.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-05.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-10-1103452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1103452.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Oct 2 12:29:16 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 MAA29478 for ; Thu, 2 Oct 2003 12:29:15 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 5D354A0CC1; Thu, 2 Oct 2003 12:29:24 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DF276A0F8B for ; Thu, 2 Oct 2003 12:29:21 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 63427137BC; Thu, 2 Oct 2003 12:29:21 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id EDA4914C8B for ; Thu, 2 Oct 2003 12:29:20 -0400 (EDT) Received: (qmail 7217 invoked by uid 65534); 2 Oct 2003 16:29:20 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp026) with SMTP; 02 Oct 2003 18:29:20 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Thu, 2 Oct 2003 18:29:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: redirect ref draft issues resolution X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDNILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7923 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031002162924.5D354A0CC1@frink.w3.org> Resent-Date: Thu, 2 Oct 2003 12:29:24 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, changes in : Resolved issues: - : accepted (statement removed) - : added proposed resolution from 2000 - : accepted (sentence removed) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 3 03:01: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 DAA24882 for ; Fri, 3 Oct 2003 03:01:23 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 19554A0553; Fri, 3 Oct 2003 03:01:30 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DAFE0A0553 for ; Fri, 3 Oct 2003 03:01:28 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 8EA0E134CF; Fri, 3 Oct 2003 03:01:28 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ns1.mindcube.biz (unknown [194.255.126.252]) by dr-nick.w3.org (Postfix) with SMTP id B05D41342C for ; Fri, 3 Oct 2003 03:01:17 -0400 (EDT) Received: (qmail 16196 invoked from network); 3 Oct 2003 06:52:31 -0000 Received: from port55.ds1-sdb.adsl.cybercity.dk (HELO cinatit.com) (jan@cinatit.biz@212.242.166.120) by ns1.mindcube.biz with SMTP; 3 Oct 2003 06:52:31 -0000 Message-ID: <3F7D1E7E.40203@cinatit.com> Date: Fri, 03 Oct 2003 09:00:14 +0200 From: Jan Wrang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: da, en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <3F7BE19B.9050606@mindcube.biz> In-Reply-To: <3F7BE19B.9050606@mindcube.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Windows XP Webdav redirector X-Archived-At: http://www.w3.org/mid/3F7D1E7E.40203@cinatit.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7924 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003070130.19554A0553@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 03:01:30 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I've been struggling for some days with the Windows XP webdav redirector. I want to map a network drive to my webDAV server, but keep getting "error 67 - The network name cannot be found" from win XP. Access to the server through webfolders work on both Win XP and W2000!. Below is the communication between Server and XP (collected through Ethereal): Any input appreciated, Best regards Jan PROPFIND /folder HTTP/1.1 Depth: 0 translate: f User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 Host: dev1.cinatit.biz Content-Length: 0 Connection: Keep-Alive Authorization: Basic YW5ha2luOmFuYWtpbg== HTTP/1.1 301 Moved Permanently Server: Resin/2.1.11 Cache-Control: private Location: http://dev1.cinatit.biz/folder/shared/ Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder Set-Cookie: JSESSIONID=aZpBUuyWC4ld; path=/ Content-Length: 0 Date: Tue, 30 Sep 2003 07:53:07 GMT PROPFIND /folder/shared/ HTTP/1.1 Depth: 0 translate: f User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 Host: dev1.cinatit.biz Content-Length: 0 Connection: Keep-Alive Authorization: Basic YW5ha2luOmFuYWtpbg== HTTP/1.1 207 Multi-Status Server: Resin/2.1.11 Cache-Control: private Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder Set-Cookie: JSESSIONID=a8WzepGZeh1_; path=/ Content-Type: text/xml; charset="utf-8" Content-Length: 860 Date: Tue, 30 Sep 2003 07:53:07 GMT /folder/shared/ 1970-01-01Thu12:00:00Z 0_48563_0 Thu, 1 Jan 1970 12:00:00 GMT HTTP/1.1 200 OK error 67 - The network name cannot be found From w3c-dist-auth-request@w3.org Fri Oct 3 04:41:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27393 for ; Fri, 3 Oct 2003 04:41:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C7D7CA07A8; Fri, 3 Oct 2003 04:41:08 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 71B84A0680 for ; Fri, 3 Oct 2003 04:41:04 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 76C89135C0; Fri, 3 Oct 2003 04:38:25 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id D8C1C1343D for ; Fri, 3 Oct 2003 04:38:24 -0400 (EDT) Received: (qmail 25874 invoked by uid 65534); 3 Oct 2003 08:38:16 -0000 Received: from p3EE24701.dip.t-dialin.net (HELO lisa) (62.226.71.1) by mail.gmx.net (mp007) with SMTP; 03 Oct 2003 10:38:16 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Jan Wrang" , Date: Fri, 3 Oct 2003 10:37:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <3F7D1E7E.40203@cinatit.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Windows XP Webdav redirector X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFDILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7925 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003084108.C7D7CA07A8@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 04:41:08 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I can't really tell why the client is failing (there are a lot of known issues with it and Microsoft is obviously unwilling to do any bugfixing before the next major Windows release). However, looking at the lost PROPFIND response, I can't help noticing: > xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > > > /folder/shared/ > > > > > > > > > > > > > > > > > > > > > > > b:dt="dateTime.tz">1970-01-01Thu12:00:00Z This timestamp doesn't use the ISO format (note the string "Thu"). This one may be breaking the client. > > 0_48563_0 Value of ETag doesn't conform to HTTP header syntax (see RFC2616, section 14.19). > Thu, 1 Jan 1970 > 12:00:00 GMT > > > HTTP/1.1 200 OK > > > 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 Jan Wrang > Sent: Friday, October 03, 2003 9:00 AM > To: w3c-dist-auth@w3.org > Subject: Windows XP Webdav redirector > > > > Hi, > I've been struggling for some days with the Windows XP webdav redirector. > I want to map a network drive to my webDAV server, > but keep getting "error 67 - The network name cannot be found" > from win XP. > Access to the server through webfolders work on both Win XP and W2000!. > > Below is the communication between Server and XP (collected through > Ethereal): > > Any input appreciated, > > Best regards > Jan > > PROPFIND /folder HTTP/1.1 > Depth: 0 translate: f > User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 > Host: dev1.cinatit.biz > Content-Length: 0 Connection: Keep-Alive > Authorization: Basic YW5ha2luOmFuYWtpbg== > > HTTP/1.1 301 Moved Permanently > Server: Resin/2.1.11 > Cache-Control: private > Location: http://dev1.cinatit.biz/folder/shared/ > Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder > Set-Cookie: JSESSIONID=aZpBUuyWC4ld; path=/ > Content-Length: 0 Date: Tue, 30 Sep 2003 07:53:07 GMT > > PROPFIND /folder/shared/ HTTP/1.1 > Depth: 0 translate: f > User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 > Host: dev1.cinatit.biz > Content-Length: 0 > Connection: Keep-Alive > Authorization: Basic YW5ha2luOmFuYWtpbg== > > HTTP/1.1 207 Multi-Status > Server: Resin/2.1.11 > Cache-Control: private > Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder > Set-Cookie: JSESSIONID=a8WzepGZeh1_; path=/ > Content-Type: text/xml; charset="utf-8" > Content-Length: 860 Date: Tue, 30 Sep 2003 07:53:07 GMT > > xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > > > /folder/shared/ > > > > > > > > > > > > > > > > > > > > > > > b:dt="dateTime.tz">1970-01-01Thu12:00:00Z > > 0_48563_0 > Thu, 1 Jan 1970 > 12:00:00 GMT > > > HTTP/1.1 200 OK > > > > > > error 67 - The network name cannot be found > > > From w3c-dist-auth-request@w3.org Fri Oct 3 05:20: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 FAA28203 for ; Fri, 3 Oct 2003 05:20:54 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C150FA0647; Fri, 3 Oct 2003 05:21:02 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9360CA088A for ; Fri, 3 Oct 2003 05:21:00 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 23F3813606; Fri, 3 Oct 2003 05:21:00 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ns1.mindcube.biz (unknown [194.255.126.252]) by dr-nick.w3.org (Postfix) with SMTP id 7CE6713494 for ; Fri, 3 Oct 2003 05:20:59 -0400 (EDT) Received: (qmail 16586 invoked from network); 3 Oct 2003 09:12:13 -0000 Received: from port55.ds1-sdb.adsl.cybercity.dk (HELO cinatit.com) (jan@cinatit.biz@212.242.166.120) by ns1.mindcube.biz with SMTP; 3 Oct 2003 09:12:13 -0000 Message-ID: <3F7D3F73.8010805@cinatit.com> Date: Fri, 03 Oct 2003 11:20:51 +0200 From: Jan Wrang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: da, en-us, en MIME-Version: 1.0 To: Julian Reschke Cc: Jan Wrang , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060906050709000305030909" Subject: Re: Windows XP Webdav redirector X-Archived-At: http://www.w3.org/mid/3F7D3F73.8010805@cinatit.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7926 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003092102.C150FA0647@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 05:21:02 -0400 (EDT) This is a multi-part message in MIME format. --------------060906050709000305030909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Julian, Thanks for a very fast response. Fixing the bug in the date actually did it :-)) Thanks a lot! Best regards, Jan Julian Reschke wrote: >Hi, > >I can't really tell why the client is failing (there are a lot of known >issues with it and Microsoft is obviously unwilling to do any bugfixing >before the next major Windows release). > >However, looking at the lost PROPFIND response, I can't help noticing: > > > >>>xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > >> >> /folder/shared/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >b:dt="dateTime.tz">1970-01-01Thu12:00:00Z >> >> > >This timestamp doesn't use the ISO format (note the string "Thu"). This one >may be breaking the client. > > > >> >> 0_48563_0 >> >> > >Value of ETag doesn't conform to HTTP header syntax (see RFC2616, section >14.19). > > > >> Thu, 1 Jan 1970 >>12:00:00 GMT >> >> >> HTTP/1.1 200 OK >> >> >> >> >> > >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 Jan Wrang >>Sent: Friday, October 03, 2003 9:00 AM >>To: w3c-dist-auth@w3.org >>Subject: Windows XP Webdav redirector >> >> >> >>Hi, >>I've been struggling for some days with the Windows XP webdav redirector. >>I want to map a network drive to my webDAV server, >>but keep getting "error 67 - The network name cannot be found" >>from win XP. >>Access to the server through webfolders work on both Win XP and W2000!. >> >>Below is the communication between Server and XP (collected through >>Ethereal): >> >>Any input appreciated, >> >>Best regards >>Jan >> >>PROPFIND /folder HTTP/1.1 >>Depth: 0 translate: f >>User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 >>Host: dev1.cinatit.biz >>Content-Length: 0 Connection: Keep-Alive >>Authorization: Basic YW5ha2luOmFuYWtpbg== >> >>HTTP/1.1 301 Moved Permanently >>Server: Resin/2.1.11 >>Cache-Control: private >>Location: http://dev1.cinatit.biz/folder/shared/ >>Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder >>Set-Cookie: JSESSIONID=aZpBUuyWC4ld; path=/ >>Content-Length: 0 Date: Tue, 30 Sep 2003 07:53:07 GMT >> >>PROPFIND /folder/shared/ HTTP/1.1 >>Depth: 0 translate: f >>User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600 >>Host: dev1.cinatit.biz >>Content-Length: 0 >>Connection: Keep-Alive >>Authorization: Basic YW5ha2luOmFuYWtpbg== >> >>HTTP/1.1 207 Multi-Status >>Server: Resin/2.1.11 >>Cache-Control: private >>Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder >>Set-Cookie: JSESSIONID=a8WzepGZeh1_; path=/ >>Content-Type: text/xml; charset="utf-8" >>Content-Length: 860 Date: Tue, 30 Sep 2003 07:53:07 GMT >> >>>xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" > >> >> /folder/shared/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >b:dt="dateTime.tz">1970-01-01Thu12:00:00Z >> >> 0_48563_0 >> Thu, 1 Jan 1970 >>12:00:00 GMT >> >> >> HTTP/1.1 200 OK >> >> >> >> >> >>error 67 - The network name cannot be found >> >> >> >> >> > > > --------------060906050709000305030909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Julian,

Thanks for a very fast response.
Fixing the bug in the date actually did it :-))

Thanks a lot!

Best regards,

Jan

Julian Reschke wrote:
Hi,

I can't really tell why the client is failing (there are a lot of known
issues with it and Microsoft is obviously unwilling to do any bugfixing
before the next major Windows release).

However, looking at the lost PROPFIND response, I can't help noticing:

  
<D:multistatus xmlns:D="DAV:"
xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" >
<D:response>
    <D:href>/folder/shared/</D:href>
    <D:propstat>
        <D:prop>
            <D:supportedlock>
                <D:lockentry>
                    <D:lockscope>
                        <D:exclusive/>
                    </D:lockscope>
                <D:locktype>
                    <D:write/>
                </D:locktype>
                </D:lockentry>
                <D:lockentry>
                    <D:lockscope>
                        <D:shared/>
                    </D:lockscope>
                    <D:locktype>
                        <D:write/>
                    </D:locktype>
                </D:lockentry>
            </D:supportedlock>
            <D:displayname><![CDATA[root]]></D:displayname>
            <D:getcontenttype/>
            <D:creationdate
b:dt="dateTime.tz">1970-01-01Thu12:00:00Z</D:creationdate>
    

This timestamp doesn't use the ISO format (note the string "Thu"). This one
may be breaking the client.

  
            <D:lockdiscovery/>
            <D:getetag>0_48563_0</D:getetag>
    

Value of ETag doesn't conform to HTTP header syntax (see RFC2616, section
14.19).

  
            <D:getlastmodified b:dt="dateTime.rfc1123">Thu, 1 Jan 1970
12:00:00 GMT</D:getlastmodified>
            <D:resourcetype><D:collection/></D:resourcetype>
        </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
</D:response>
</D:multistatus>
    

Julian

--
<green/>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 Jan Wrang
Sent: Friday, October 03, 2003 9:00 AM
To: w3c-dist-auth@w3.org
Subject: Windows XP Webdav redirector



Hi,
I've been struggling for some days with the Windows XP webdav redirector.
I want to map a network drive to my webDAV server,
but keep getting "error 67 - The network name cannot be found"
from win XP.
Access to the server through webfolders work on both Win XP and W2000!.

Below is the communication between Server and XP (collected through
Ethereal):

Any input appreciated,

Best regards
Jan

PROPFIND /folder HTTP/1.1
Depth: 0 translate: f
User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600
Host: dev1.cinatit.biz
Content-Length: 0 Connection: Keep-Alive
Authorization: Basic YW5ha2luOmFuYWtpbg==

HTTP/1.1 301 Moved Permanently
Server: Resin/2.1.11
Cache-Control: private
Location: http://dev1.cinatit.biz/folder/shared/
Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder
Set-Cookie: JSESSIONID=aZpBUuyWC4ld; path=/
Content-Length: 0 Date: Tue, 30 Sep 2003 07:53:07 GMT

PROPFIND /folder/shared/ HTTP/1.1
Depth: 0 translate: f
User-Agent: Microsoft-WebDAV-MiniRedir/5.1.2600
Host: dev1.cinatit.biz
Content-Length: 0
Connection: Keep-Alive
Authorization: Basic YW5ha2luOmFuYWtpbg==

HTTP/1.1 207 Multi-Status
Server: Resin/2.1.11
Cache-Control: private
Set-Cookie: mindcubeWebDAV=LkFkNkGkHkBkCnAhMhChPhMhIh; path=/folder
Set-Cookie: JSESSIONID=a8WzepGZeh1_; path=/
Content-Type: text/xml; charset="utf-8"
Content-Length: 860 Date: Tue, 30 Sep 2003 07:53:07 GMT
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" >
<D:response>
    <D:href>/folder/shared/</D:href>
    <D:propstat>
        <D:prop>
            <D:supportedlock>
                <D:lockentry>
                    <D:lockscope>
                        <D:exclusive/>
                    </D:lockscope>
                <D:locktype>
                    <D:write/>
                </D:locktype>
                </D:lockentry>
                <D:lockentry>
                    <D:lockscope>
                        <D:shared/>
                    </D:lockscope>
                    <D:locktype>
                        <D:write/>
                    </D:locktype>
                </D:lockentry>
            </D:supportedlock>
            <D:displayname><![CDATA[root]]></D:displayname>
            <D:getcontenttype/>
            <D:creationdate
b:dt="dateTime.tz">1970-01-01Thu12:00:00Z</D:creationdate>
            <D:lockdiscovery/>
            <D:getetag>0_48563_0</D:getetag>
            <D:getlastmodified b:dt="dateTime.rfc1123">Thu, 1 Jan 1970
12:00:00 GMT</D:getlastmodified>
            <D:resourcetype><D:collection/></D:resourcetype>
        </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
</D:response>
</D:multistatus>


error 67 - The network name cannot be found
--------------060906050709000305030909-- From w3c-dist-auth-request@w3.org Fri Oct 3 11:39: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 LAA12620 for ; Fri, 3 Oct 2003 11:39:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E1C00A08F5; Fri, 3 Oct 2003 11:39:19 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0E82DA08F5 for ; Fri, 3 Oct 2003 11:39:19 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DD14913455; Fri, 3 Oct 2003 11:39:18 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from natsmtp01.webmailer.de (natsmtp01.webmailer.de [192.67.198.81]) by dr-nick.w3.org (Postfix) with ESMTP id 7151E13438 for ; Fri, 3 Oct 2003 11:39:18 -0400 (EDT) Received: from x.oberon.ethz.ch (p5083C23A.dip0.t-ipconnect.de [80.131.194.58]) by post.webmailer.de (8.12.10/8.12.10) with SMTP id h93FdE83022160; Fri, 3 Oct 2003 17:39:16 +0200 (MEST) Date: Fri, 3 Oct 2003 17:39:14 +0200 (MEST) Message-Id: <200310031539.h93FdE83022160@post.webmailer.de> From: edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 16.04.2003 To: w3c-dist-auth@w3.org Cc: edgar@edgarschwarz.de Subject: MS Webfolders POST X-Archived-At: http://www.w3.org/mid/200310031539.h93FdE83022160@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7927 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003153919.E1C00A08F5@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 11:39:19 -0400 (EDT) Hi, today I managed to access my server using W98 Webfolders: BEGIN HTTP-Request Header information (03.10.03 10:18:06 ) Request: POST /_vti_bin/shtml.exe/_vti_rpc Host: webdav.ethz.ch User-Agent: MSFrontPage/4.0 Accept: auth/sicily Connection: Keep-Alive X-Vermeer-Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded Content-Length: 41 MIME-Version: 1.0 Date: Fri, 03 Oct 2003 09:15:43 GMT Connection: Keep-Alive Content-Length: 0 MIME-Version: 1.0 Date: Fri, 03 Oct 2003 09:15:43 GMT END HTTP-Request Header information BEGIN HTTP-Reply Header information (03.10.03 10:18:07 ) Status Code: 501 Reason: Operation not implemented Server: Aos HTTP Server/0.3 Date: Fri, 03 Oct 2003 10:18:07 GMT Content-Length: -1 END HTTP-Reply Header information As you see I reject a POST. That ok or should I react differently ? BTW, are there still Webfolders in XP or do I have to use this DAV Redirector somebody was already talking today ? Regards, Edgar -- edgar@edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein From w3c-dist-auth-request@w3.org Fri Oct 3 11:46: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 LAA13021 for ; Fri, 3 Oct 2003 11:46:55 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id DBCF1A07D0; Fri, 3 Oct 2003 11:46:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8C2AAA0573 for ; Fri, 3 Oct 2003 11:46:53 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 547FA13514; Fri, 3 Oct 2003 11:46:53 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id E6B89134B4 for ; Fri, 3 Oct 2003 11:46:52 -0400 (EDT) Received: (qmail 31262 invoked by uid 65534); 3 Oct 2003 15:46:43 -0000 Received: from p3EE24701.dip.t-dialin.net (HELO lisa) (62.226.71.1) by mail.gmx.net (mp012) with SMTP; 03 Oct 2003 17:46:43 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , Date: Fri, 3 Oct 2003 17:46:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200310031539.h93FdE83022160@post.webmailer.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: MS Webfolders POST X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEGAILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7928 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003154654.DBCF1A07D0@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 11:46:54 -0400 (EDT) Content-Transfer-Encoding: 7bit Rejecting POST is ok. XP has two clients -- the old webfolder client and the new (and broken beyond belief) "mini redirector". 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 edgar@edgarschwarz.de > Sent: Friday, October 03, 2003 5:39 PM > To: w3c-dist-auth@w3.org > Cc: edgar@edgarschwarz.de > Subject: MS Webfolders POST > > > > Hi, > today I managed to access my server using W98 Webfolders: > > BEGIN HTTP-Request Header information (03.10.03 10:18:06 ) > Request: POST /_vti_bin/shtml.exe/_vti_rpc > Host: webdav.ethz.ch > User-Agent: MSFrontPage/4.0 > Accept: auth/sicily > Connection: Keep-Alive > X-Vermeer-Content-Type: application/x-www-form-urlencoded > Content-Type: application/x-www-form-urlencoded > Content-Length: 41 > MIME-Version: 1.0 > Date: Fri, 03 Oct 2003 09:15:43 GMT > Connection: Keep-Alive > Content-Length: 0 > MIME-Version: 1.0 > Date: Fri, 03 Oct 2003 09:15:43 GMT > END HTTP-Request Header information > > > BEGIN HTTP-Reply Header information (03.10.03 10:18:07 ) > Status Code: 501 Reason: Operation not implemented > Server: Aos HTTP Server/0.3 > Date: Fri, 03 Oct 2003 10:18:07 GMT > Content-Length: -1 > END HTTP-Reply Header information > > As you see I reject a POST. That ok or should I react differently ? > > BTW, are there still Webfolders in XP or do I have to use > this DAV Redirector somebody was already talking today ? > > Regards, Edgar > > > > > > -- > edgar@edgarschwarz.de "http://www.edgarschwarz.de" > "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon > Make it as simple as possible, but not simpler. Albert Einstein > From w3c-dist-auth-request@w3.org Fri Oct 3 18:46: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 SAA03170 for ; Fri, 3 Oct 2003 18:46:08 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0A656A057C; Fri, 3 Oct 2003 18:46:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 062F7A057C for ; Fri, 3 Oct 2003 18:46:16 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C889E13A2E; Fri, 3 Oct 2003 18:46:15 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id 4B47613A2D for ; Fri, 3 Oct 2003 18:46:15 -0400 (EDT) Received: from Tycho (dhcp-63-196.cse.ucsc.edu [128.114.63.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h93Mgja09790 for ; Fri, 3 Oct 2003 15:42:46 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 3 Oct 2003 15:44:39 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: RE: Future direction for DASL/WebDAV SEARCH X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEHGJJAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7929 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031003224617.0A656A057C@frink.w3.org> Resent-Date: Fri, 3 Oct 2003 18:46:17 -0400 (EDT) Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Kevin Wiggen [mailto:kwiggen@xythos.com] Sent: Thursday, October 02, 2003 7:39 PM To: Jim Whitehead; WebDAV; www-webdav-dasl@w3.org Subject: [Moderator Action] RE: Future direction for DASL/WebDAV SEARCH I agree with Jim that the current implementation is very useful in its current form. Although there are holes, it is very useful in many circumstances. Given the lack of work going on with this specification, I do not believe it useful to put some of the "nice to haves" into the specification now. There are a number of production systems being used today without extra features and I believe we should get the work that is done issued. I believe we should make this a Proposed standard. Julian recently wrote that the remaining issues are marshaling and data typing. Let's go through the marshaling on this list quickly and get consensus on those issues. Data Typing. If the Webdav WG can't get a consensus on this topic in all these years, I don't think DASL should be held up on it. In the last week I have only seen Julian answer this email, so I don't think a lot of people will work on the data typing just to get DASL done. Let's simply get what work has been done into an RFC. I believe a NEW WG can be made to improve on DASL and bring together web searching, XPath, data typing etc. for not only Webdav resources but others as well (can you say web service for Google, Verity, etc). Kevin Wiggen Xythos Software Inc. -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Monday, September 29, 2003 2:00 PM To: WebDAV; www-webdav-dasl@w3.org Subject: Future direction for DASL/WebDAV SEARCH All, I'm interested in people's thoughts on how to proceed with the DASL specification. The DASL protocol, in its current form, has a great deal of effort and maturity. Its well-specified enough such that there are multiple interoperating implementations. Though it has limitations, it is very useful in its current form. This argues for issuing the current specification as an RFC, either standards track or experimental. On the other hand, there are many features that would be nice to have added. Some imply significant changes, as with proper sort ordering and comparator evaluation of dead properties which implies adding a type system to WebDAV properties. As well, handling XML querying intelligently would be a plus, but would also require much work. This argues for creating a new working group to address further development of DASL. It might make sense to involve a wider audience, perhaps by including people in the W3C community interested in protocols for XML searching. So, there are a couple of choices: a) Do we issue current specification more-or-less as-is? i) as Proposed ii) as Experimental b) Do we continue development of the specification? i) within WebDAV community only - as new WG? in DAV WG? ii) expand community to address Web/XML searching in general, not necessarily focused on WebdAV - as IETF WG? as W3C activity? There are probably other choices as well. Let me know what your thoughts are. Thanks! - Jim From w3c-dist-auth-request@w3.org Sat Oct 4 05: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 FAA01233 for ; Sat, 4 Oct 2003 05:59:29 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B1CE1A0648; Sat, 4 Oct 2003 05:59:31 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7BEDDA05AC for ; Sat, 4 Oct 2003 05:59:29 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 2E01913B87; Sat, 4 Oct 2003 05:59:29 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id B8FBD13312 for ; Sat, 4 Oct 2003 05:59:28 -0400 (EDT) Received: (qmail 16570 invoked by uid 65534); 4 Oct 2003 09:59:18 -0000 Received: from p3EE24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp002) with SMTP; 04 Oct 2003 11:59:18 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "WebDAV" , Date: Sat, 4 Oct 2003 11:58:50 +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 Importance: Normal In-Reply-To: Subject: RE: RE: Future direction for DASL/WebDAV SEARCH X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEHOILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7930 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031004095931.B1CE1A0648@frink.w3.org> Resent-Date: Sat, 4 Oct 2003 05:59:31 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: Kevin Wiggen [mailto:kwiggen@xythos.com] > Sent: Thursday, October 02, 2003 7:39 PM > To: Jim Whitehead; WebDAV; www-webdav-dasl@w3.org > Subject: [Moderator Action] RE: Future direction for DASL/WebDAV SEARCH > > > > > > > I agree with Jim that the current implementation is very useful in its > current form. Although there are holes, it is very useful in many > circumstances. Yes. However, where these holes affect the predictability of search results, we need to close them. > Given the lack of work going on with this specification, I do not As a matter of fact, I've seen little progress with any of the WebDAV specs in the last months. Progress occurs when people decide to spend time to improve the draft. The SEARCH spec has been (albeit slowly) progressing, mainly because of feedback from Software AG (Tamino) and the Catacomb developers. If we can get all interested parties (probably that would include Xythos and Oracle) to concentrate on the remaining issues, then we can probably get the spec out within a few weeks. > believe it useful to put some of the "nice to haves" into the > specification now. There are a number of production systems being used > today without extra features and I believe we should get the work that > is done issued. Yes. However I don't think that anybody is doing that. Almost all open issues aren't about nice-to-have additions but about problems with the existing functionality (for instance, the missing ability to relaibly query on non-string typed properties, such as DAV:getcontentlength). > I believe we should make this a Proposed standard. ...when we've closed these issues. > Julian recently wrote that the remaining issues are marshaling and data > typing. > > Let's go through the marshaling on this list quickly and get consensus > on those issues. That would be good. > Data Typing. If the Webdav WG can't get a consensus on this topic in > all these years, I don't think DASL should be held up on it. In the > last week I have only seen Julian answer this email, so I don't think a > lot of people will work on the data typing just to get DASL done. Let's > simply get what work has been done into an RFC. However, without data typing the grammer simply is incomplete. Could you please explain how you're going to query for resources where DAV:getcontentlength is between 1000 and 5000 without somehow introducing a distinction between strings and numbers. And what about queries on dates? If the spec doesn't answer how queries can be made against the basic RFC2518 live properties, there's no point in submitting it. This is currently covered in section 5.10. The remaining questions are summarized here: ). > I believe a NEW WG can be made to improve on DASL and bring together web > searching, XPath, data typing etc. for not only Webdav resources but > others as well (can you say web service for Google, Verity, etc). Julian From w3c-dist-auth-request@w3.org Mon Oct 6 09:31: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 JAA29449 for ; Mon, 6 Oct 2003 09:31:28 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 603D2A06FD; Mon, 6 Oct 2003 09:31:36 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6D2BCA06FD for ; Mon, 6 Oct 2003 09:31:35 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 54D5213CD9; Mon, 6 Oct 2003 09:31:35 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by dr-nick.w3.org (Postfix) with ESMTP id 4699213BEC for ; Mon, 6 Oct 2003 09:31:35 -0400 (EDT) Received: from 207-38-191-162.c3-0.wsd-ubr2.qens-wsd.ny.cable.rcn.com ([207.38.191.162] helo=unit12.net) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1A6VSY-0005mT-00 for w3c-dist-auth@w3.org; Mon, 06 Oct 2003 09:31:34 -0400 Date: Mon, 6 Oct 2003 09:31:36 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Christian Niles To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit Message-Id: <685C94B7-F801-11D7-853C-000A9590B78E@unit12.net> X-Mailer: Apple Mail (2.552) Subject: WebDAV Packaging Format X-Archived-At: http://www.w3.org/mid/685C94B7-F801-11D7-853C-000A9590B78E@unit12.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7931 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006133136.603D2A06FD@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 09:31:36 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi All, I'm curious to know if anyone has ever worked on a zip/tar-like file format for packaging a WebDAV repository. Essentially, this would allow someone to backup a WebDAV repository and move it to a different server. In my case, I need to preserve dead properties since the CMS I'm developing uses them in some cases to mark files for specific processing. I'd also like to be able to package administration files used by my web-based interface in a generic way for easy installation. I don't need to support versioning at this stage, though at a later stage import/export without loss of versioning histories would be nice. My first stab at such a format would be to simply use the zip format with a standard layout for properties and resources. Support for versioning, I imagine, would be harder for various reasons, and be less portable between servers using just the WebDAV protocol. However, a common format might allow greater interoperability if each implementation supported import and export. Thanks for any comments or links to existing projects dealing with this issue. I'm obviously curious to know how others have dealt with moving their repositories around. best, christian. From w3c-dist-auth-request@w3.org Mon Oct 6 13:03: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 NAA12325 for ; Mon, 6 Oct 2003 13:03:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6810DA0993; Mon, 6 Oct 2003 13:04:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 38953A0993 for ; Mon, 6 Oct 2003 13:03:58 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DB229144B8; Mon, 6 Oct 2003 13:03:57 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 920D913531; Mon, 6 Oct 2003 13:03:57 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A6Ym4-0008NP-00; Mon, 06 Oct 2003 17:03:56 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A6Ym4-0008NE-00; Mon, 06 Oct 2003 17:03:56 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'WebDAV'" , Date: Mon, 6 Oct 2003 10:04:08 -0700 Message-ID: <019201c38c2b$dbac2440$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org, www-webdav-dasl@w3.org Subject: RE: RE: Future direction for DASL/WebDAV SEARCH X-Archived-At: http://www.w3.org/mid/019201c38c2b$dbac2440$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7932 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006170400.6810DA0993@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 13:04:00 -0400 (EDT) Content-Transfer-Encoding: 7bit > > > Data Typing. If the Webdav WG can't get a consensus on > this topic in > > all these years, I don't think DASL should be held up on > it. In the > > last week I have only seen Julian answer this email, so I > don't think > > a lot of people will work on the data typing just to get > DASL done. > > Let's simply get what work has been done into an RFC. > > However, without data typing the grammer simply is > incomplete. Could you please explain how you're going to > query for resources where DAV:getcontentlength is between > 1000 and 5000 without somehow introducing a distinction > between strings and numbers. And what about queries on dates? It's easy. Let's say a client presents a GUI allowing the user to select this kind of search and to select a directory to search on. The user can fill in a file size, say 1 MB. - Find files larger than [_____] MB [SEARCH] The client then issues a SEARCH against that scope with a where clause including 1048576 For an example of this kind of GUI implemented as a Web-based UI, see Sharemation's search function. This is an implementation proof that DASL is useful without data-typing support in the protocol. The reason why this works without data-typing support in the protocol is because data typing is done first in specifications. RFC2518 specifies that the getcontentlength property is an integer, and that getlastmodified is a date. Therefore clients presenting searches against known properties have no problems - they know that for searches on length the user should only be allowed to enter an integer whereas for searches against 'getlastmodified' the user should be allowed to select a date to compare. What data typing doesn't work for, of course, is searches against unknown properties -- custom properties, for example. THat's why WFS supports only string compares on dead properties. The DASL grammar is "incomplete" in that it doesn't contain every function we can imagine. I'd prefer to standardize it that way and work on data typing (for both property get/set and DASL) separately. Lisa From w3c-dist-auth-request@w3.org Mon Oct 6 13:14: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 NAA12882 for ; Mon, 6 Oct 2003 13:14:28 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B9141A08EA; Mon, 6 Oct 2003 13:14:35 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0A11EA09D8 for ; Mon, 6 Oct 2003 13:14:33 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D098C14517; Mon, 6 Oct 2003 13:14:12 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 6B091144F0 for ; Mon, 6 Oct 2003 13:14:12 -0400 (EDT) Received: (qmail 8781 invoked by uid 65534); 6 Oct 2003 17:14:12 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 06 Oct 2003 19:14:12 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'WebDAV'" , Date: Mon, 6 Oct 2003 19:14:10 +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: <019201c38c2b$dbac2440$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: RE: Future direction for DASL/WebDAV SEARCH X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAELIILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006171435.B9141A08EA@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 13:14:35 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, October 06, 2003 7:04 PM > To: 'Julian Reschke'; 'WebDAV'; www-webdav-dasl@w3.org > Subject: RE: RE: Future direction for DASL/WebDAV SEARCH > > ... > > It's easy. Let's say a client presents a GUI allowing the user to > select this kind of search and to select a directory to search on. > The user can fill in a file size, say 1 MB. > > - Find files larger than [_____] MB [SEARCH] > > The client then issues a SEARCH against that scope with a where > clause including > > > 1048576 > > > For an example of this kind of GUI implemented as a Web-based UI, > see Sharemation's search function. This is an implementation proof > that DASL is useful without data-typing support in the protocol. > > The reason why this works without data-typing support in the protocol > is because data typing is done first in specifications. RFC2518 > specifies that the getcontentlength property is an integer, and > that getlastmodified is a date. Therefore clients presenting searches > against known properties have no problems - they know that for searches > on length the user should only be allowed to enter an integer whereas > for searches against 'getlastmodified' the user should be allowed to > select a date to compare. Well, the only reason why this works is because Sharemation *happens* to make the assumption that a query against DAV:getcontentlength is meant to be numeric. Of course this is what common sense dictates, and probably all other implementations do the same (our's does). However, nothing in the original spec said anything about that, so clients couldn't really rely on that behaviour. This has been fixed in one of the previous drafts, but I think it illustrates why the spec can't simple be silent on that issue (similar questions arise with the date-typed properties from RFC2518). > What data typing doesn't work for, of course, is searches against > unknown properties -- custom properties, for example. THat's why > WFS supports only string compares on dead properties. > > The DASL grammar is "incomplete" in that it doesn't contain every > function we can imagine. I'd prefer to standardize it that way and > work on data typing (for both property get/set and DASL) separately. Of course that's possible. I'd agree with you if this part was completely unfinished. However, it's almost there (as optional grammar element), so I'd prefer to get it finished (instead of removing it). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 6 14:08: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 OAA15225 for ; Mon, 6 Oct 2003 14:08:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A92D1A055F; Mon, 6 Oct 2003 14:09:04 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EC707A055F for ; Mon, 6 Oct 2003 14:09:02 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9015F13905; Mon, 6 Oct 2003 14:09:02 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 5EFF613903 for ; Mon, 6 Oct 2003 14:09:02 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A6Zmz-0000rY-00; Mon, 06 Oct 2003 18:08:57 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A6Zmz-0000rN-00; Mon, 06 Oct 2003 18:08:57 +0000 From: "Lisa Dusseault" To: "'Lisa Dusseault'" , , "'Webdav WG'" Cc: "'Ted Hardie'" , "'Jim Whitehead'" Date: Mon, 6 Oct 2003 11:09:09 -0700 Message-ID: <001001c38c34$f05ed280$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 In-Reply-To: <01f601c3820f$95724480$f8cb90c6@lisalap> Old-X-Envelope-To: acl@webdav.org, ejw@cse.ucsc.edu, hardie@qualcomm.com, lisa@xythos.com, w3c-dist-auth@w3c.org Subject: RE: ANNOUNCE: ACL draft to WebDAV working group last call X-Archived-At: http://www.w3.org/mid/001001c38c34$f05ed280$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006180904.A92D1A055F@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 14:09:04 -0400 (EDT) Content-Transfer-Encoding: 7bit This last call period ends tomorrow. There have been a few questions: what are the permissions on a bound resource --> This question appears to be answered - inherited permissions are not transitive whether a principal resource is a HTTP resource --> answered: yes how the server maps from login to principal resource --> answered: implementation dependent suggestion to add write-collection --> no support voiced in response I don't think any of these prevent the document from going forward after last call finishes so if there is disagreement please raise it on the acl list. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > Sent: Tuesday, September 23, 2003 1:17 PM > To: acl@webdav.org; Webdav WG > Cc: Ted Hardie; 'Jim Whitehead' > Subject: ANNOUNCE: ACL draft to WebDAV working group last call > > > > > It's time to last-call ACL again. If you recall, ACL was > brought to last call a year ago. IESG review brought up a > couple issues with how carefully delete privilege was defined > and suggested simplification among the server options > (particularly in the order-of-evaluation of ACEs). These > changes have been made and we've now spent quite a long time > discussing those changes and other ideas. I'm not aware of > any outstanding issues besides one nit in acl-restrictions > which Geoff probably already dealt with. > > So, this begins a two-week period in which anybody can make > comments on the ACL draft. After this period if we've only > found minor issues/nits, we'll resubmit it to the IESG. I > don't know yet if that will involve another IETF last call so > I recommend you review ACL now. > > Various formats available here: http://www.webdav.org/acl/ > Official draft location: > http://www.ietf.org/internet-drafts/draft-> ietf-webdav-acl-11.txt > > Lisa > > > From w3c-dist-auth-request@w3.org Mon Oct 6 14:17:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15642 for ; Mon, 6 Oct 2003 14:17:16 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7DF9EA099D; Mon, 6 Oct 2003 14:17:23 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 726F8A099D for ; Mon, 6 Oct 2003 14:17:22 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 0B5F7144AD; Mon, 6 Oct 2003 14:17:22 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 937C313D48 for ; Mon, 6 Oct 2003 14:17:21 -0400 (EDT) Received: (qmail 27672 invoked by uid 65534); 6 Oct 2003 18:17:11 -0000 Received: from pD950C250.dip.t-dialin.net (HELO lisa) (217.80.194.80) by mail.gmx.net (mp015) with SMTP; 06 Oct 2003 20:17:11 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , , "'Webdav WG'" Cc: "'Ted Hardie'" , "'Jim Whitehead'" Date: Mon, 6 Oct 2003 20:16:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: <001001c38c34$f05ed280$f8cb90c6@lisalap> Subject: RE: ANNOUNCE: ACL draft to WebDAV working group last call X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGELLILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006181723.7DF9EA099D@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 14:17:23 -0400 (EDT) Content-Transfer-Encoding: quoted-printable > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, October 06, 2003 8:09 PM > To: 'Lisa Dusseault'; acl@webdav.org; 'Webdav WG' > Cc: 'Ted Hardie'; 'Jim Whitehead' > Subject: RE: ANNOUNCE: ACL draft to WebDAV working group last call >=20 >=20 >=20 > This last call period ends tomorrow. There have been a few questions: >=20 > what are the permissions on a bound resource > --> This question appears to be answered - inherited permissions are > not transitive > whether a principal resource is a HTTP resource=20 > --> answered: yes (it has at least one HTTP URI, but can have other URIs as well) > how the server maps from login to principal resource=20 > --> answered: implementation dependent > suggestion to add write-collection > --> no support voiced in response I may have missed this one: isn't this simply DAV:bind? > I don't think any of these prevent the document from going forward = after > last call finishes so if there is disagreement please raise it on the > acl list. Agreed. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760=20 From w3c-dist-auth-request@w3.org Mon Oct 6 15:11:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17861 for ; Mon, 6 Oct 2003 15:11:54 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 921F2A07A3; Mon, 6 Oct 2003 15:12:01 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 13093A07A3 for ; Mon, 6 Oct 2003 15:12:00 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A9CAA1380D; Mon, 6 Oct 2003 15:11:59 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by dr-nick.w3.org (Postfix) with ESMTP id 43EA7136E1 for ; Mon, 6 Oct 2003 15:11:59 -0400 (EDT) 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 h96JBvt24193; Mon, 6 Oct 2003 12:11:57 -0700 (PDT) Message-ID: <3F81BE8B.6030001@nasa.gov> Date: Mon, 06 Oct 2003 12:12:11 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Niles Cc: w3c-dist-auth@w3.org References: <685C94B7-F801-11D7-853C-000A9590B78E@unit12.net> In-Reply-To: <685C94B7-F801-11D7-853C-000A9590B78E@unit12.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WebDAV Packaging Format X-Archived-At: http://www.w3.org/mid/3F81BE8B.6030001@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006191201.921F2A07A3@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 15:12:01 -0400 (EDT) Content-Transfer-Encoding: 7bit Christian Niles wrote: > I'm curious to know if anyone has ever worked on a zip/tar-like file > format for packaging a WebDAV repository. Essentially, this would > allow someone to backup a WebDAV repository and move it to a different > server. In my case, I need to preserve dead properties since the CMS > I'm developing uses them in some cases to mark files for specific > processing. I'd also like to be able to package administration files > used by my web-based interface in a generic way for easy installation. > I don't need to support versioning at this stage, though at a later > stage import/export without loss of versioning histories would be nice. > > My first stab at such a format would be to simply use the zip format > with a standard layout for properties and resources. Support for > versioning, I imagine, would be harder for various reasons, and be > less portable between servers using just the WebDAV protocol. However, > a common format might allow greater interoperability if each > implementation supported import and export. > > Thanks for any comments or links to existing projects dealing with > this issue. I'm obviously curious to know how others have dealt with > moving their repositories around. Take a look at sitecopy? It might be a good starting point... http://www.lyra.org/sitecopy/ From w3c-dist-auth-request@w3.org Mon Oct 6 18:23: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 SAA26281 for ; Mon, 6 Oct 2003 18:23:53 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A036CA0533; Mon, 6 Oct 2003 18:24:02 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 912C9A0533 for ; Mon, 6 Oct 2003 18:24:01 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 1F2AA14468; Mon, 6 Oct 2003 18:24:01 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id 00B3A1448E for ; Mon, 6 Oct 2003 18:23:57 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id h96MNuHe485292; Mon, 6 Oct 2003 18:23:56 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h96MNtYO210394; Mon, 6 Oct 2003 18:23:56 -0400 In-Reply-To: To: "Julian Reschke" Cc: acl@webdav.org, acl-bounces@webdav.org, "'Jim Whitehead'" , "'Ted Hardie'" , "Lisa Dusseault" , "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 6 Oct 2003 18:23:50 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/06/2003 18:23:55, Serialize complete at 10/06/2003 18:23:55 Content-Type: multipart/alternative; boundary="=_alternative 007B080385256DB7_=" Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call X-Archived-At: http://www.w3.org/mid/OF9B66E28D.E147C033-ON85256DB7.007ABC69-85256DB7.007B0808@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006222402.A036CA0533@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 18:24:02 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 007B080385256DB7_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 10/06/2003 02:16:32 PM: > > From: Lisa Dusseault ... > > suggestion to add write-collection > > --> no support voiced in response > > I may have missed this one: isn't this simply DAV:bind? The proposed "write-collection" was DAV:bind + DAV:unbind. This is easily achieved by having the client just specify DAV:bind and DAV:unbind, and so does not warrant its own privilege. > > I don't think any of these prevent the document from going forward after > > last call finishes so if there is disagreement please raise it on the > > acl list. > > Agreed. +1 Cheers, Geoff --=_alternative 007B080385256DB7_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 10/06/2003 02:16:32 PM:

> > From: Lisa Dusseault
...
> > suggestion to add write-collection
> >    --> no support voiced in response
>
> I may have missed this one: isn't this simply DAV:bind?

The proposed "write-collection" was DAV:bind + DAV:unbind.
This is easily achieved by having the client just specify
DAV:bind and DAV:unbind, and so does not warrant its own
privilege.

> > I don't think any of these prevent the document from going forward after
> > last call finishes so if there is disagreement please raise it on the
> > acl list.
>
> Agreed.

+1

Cheers,
Geoff
--=_alternative 007B080385256DB7_=-- From w3c-dist-auth-request@w3.org Mon Oct 6 19:54:16 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 TAA28546 for ; Mon, 6 Oct 2003 19:54:16 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 39A0BA0627; Mon, 6 Oct 2003 19:54:23 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A1A8EA0627 for ; Mon, 6 Oct 2003 19:54:21 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 03CA113702; Mon, 6 Oct 2003 19:51:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by dr-nick.w3.org (Postfix) with ESMTP id AFEFF1361F for ; Mon, 6 Oct 2003 19:51:23 -0400 (EDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail1.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h96NpEit029748; Mon, 6 Oct 2003 16:51:15 -0700 (PDT) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h96NpEr08406; Mon, 6 Oct 2003 17:51:14 -0600 (MDT) Received: from esedlarlap1 (dhcp-4op7-4op8-east-130-35-171-18.us.oracle.com [130.35.171.18]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h96NpDr08383; Mon, 6 Oct 2003 17:51:13 -0600 (MDT) Message-ID: <00e401c38c64$b481ce90$12ab2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" , "Geoffrey M Clemm" Cc: "'Ted Hardie'" , , , "Lisa Dusseault" , "'Webdav WG'" , "'Jim Whitehead'" References: Date: Mon, 6 Oct 2003 16:51:04 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01C38C2A.07CA4F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call X-Archived-At: http://www.w3.org/mid/00e401c38c64$b481ce90$12ab2382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031006235423.39A0BA0627@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 19:54:23 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_00E1_01C38C2A.07CA4F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 ----- Original Message -----=20 From: Geoffrey M Clemm=20 To: Julian Reschke=20 Cc: 'Ted Hardie' ; acl@webdav.org ; acl-bounces@webdav.org ; Lisa = Dusseault ; 'Webdav WG' ; 'Jim Whitehead'=20 Sent: Monday, October 06, 2003 3:23 PM Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group = last call Julian wrote on 10/06/2003 02:16:32 PM: > > From: Lisa Dusseault ... > > suggestion to add write-collection > > --> no support voiced in response >=20 > I may have missed this one: isn't this simply DAV:bind?=20 The proposed "write-collection" was DAV:bind + DAV:unbind.=20 This is easily achieved by having the client just specify=20 DAV:bind and DAV:unbind, and so does not warrant its own=20 privilege.=20 > > I don't think any of these prevent the document from going forward = after > > last call finishes so if there is disagreement please raise it on = the > > acl list. >=20 > Agreed.=20 +1=20 Cheers,=20 Geoff=20 -------------------------------------------------------------------------= ----- _______________________________________________ acl mailing list acl@webdav.org http://mailman.webdav.org/mailman/listinfo/acl ------=_NextPart_000_00E1_01C38C2A.07CA4F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1
----- Original Message -----
From:=20 Geoffrey M Clemm
Cc: 'Ted Hardie' ; acl@webdav.org ; acl-bounces@webdav.org ; Lisa = Dusseault ; 'Webdav=20 WG' ; 'Jim=20 Whitehead'
Sent: Monday, October 06, 2003 = 3:23=20 PM
Subject: Re: [ACL] RE: = ANNOUNCE: ACL=20 draft to WebDAV working group last call


Julian wrote on 10/06/2003 = 02:16:32=20 PM:

> > From: Lisa Dusseault
...
> > = suggestion to=20 add write-collection
> >    --> no support = voiced in=20 response
>
> I may have missed this one: isn't this = simply=20 DAV:bind?

The proposed = "write-collection"=20 was DAV:bind + DAV:unbind.
This is = easily=20 achieved by having the client just specify
DAV:bind and DAV:unbind, and so does not warrant its=20 own
privilege. =

> > I don't think any of these prevent the = document from=20 going forward after
> > last call finishes so if there is=20 disagreement please raise it on the
> > acl list.
> =
>=20 Agreed.

+1 =

Cheers,
Geoff

_______________________________________________
acl mailing=20 list
acl@webdav.org
http://mailman.we= bdav.org/mailman/listinfo/acl
------=_NextPart_000_00E1_01C38C2A.07CA4F40-- From w3c-dist-auth-request@w3.org Mon Oct 6 21:17: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 VAA00850 for ; Mon, 6 Oct 2003 21:17:51 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 770E1A0600; Mon, 6 Oct 2003 21:17:58 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B1D06A0600 for ; Mon, 6 Oct 2003 21:17:55 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 969A71461A; Mon, 6 Oct 2003 21:16:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by dr-nick.w3.org (Postfix) with ESMTP id 4138A14617 for ; Mon, 6 Oct 2003 21:16:48 -0400 (EDT) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h971Gkqe006709; Mon, 6 Oct 2003 18:16:46 -0700 (PDT) Received: from [192.168.1.101] (h209.240.40.162.ip.alltel.net [162.40.240.209]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id h971FwA2017823; Mon, 6 Oct 2003 18:16:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: In-Reply-To: <00e401c38c64$b481ce90$12ab2382@us.oracle.com> References: <00e401c38c64$b481ce90$12ab2382@us.oracle.com> Date: Mon, 6 Oct 2003 21:15:58 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV on BEA WebLogic (in support of WebCT Vista) X-Archived-At: http://www.w3.org/mid/p0600200cbba7c2036b4b@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007011758.770E1A0600@frink.w3.org> Resent-Date: Mon, 6 Oct 2003 21:17:58 -0400 (EDT) We use a Courseware Management System (CMS) called WebCT Vista which relies on the BEA WebLogic webserver and an Oracle DB. One platform-specific problem that we've seen with WebDAV in this environment is that files uploaded via WebDAV from MacOS X machines using the OS-level WebDAV support is that the file arrives in two parts as per this report: > when I use the OS X built in WebDAV feature to upload files, a > "ghost" is created of the files I upload. For example, I uploaded a > file called rcurry.greece.doc. > > This file is a 28 KB file on my computer. In the File Manager of > Vista it says the file I uploaded is 0Bytes and a second file, > ._rcurry.greece.doc was also created and is listed as being 82Bytes. The explanation offered by WebCT support uses a reference to webdav.org as follows: >In the MacOS every file has two components, a data fork and a >resource fork. This extra file that you are seeing is not a bug >within Vista (in fact you would have this extra file in almost any >WebDAV connection when you are using the MacOS (X or otherwise). The >specifics of what is occurring here is very well explained in this >web page: > >http://www.webdav.org/goliath/help0.9/chaps/rezforks.htm > >I say that you would have this is "almost any" WebDAV connection >because Goliath, a WebDAV client for the MacOS does have a >preference which allows you to turn off the copying of the resource >fork over to a WebDAV server which will prevent this file from >showing up. However, I am curious about whether this reasoning applies equally to MacOS X as it does to the preceeding operating system called MacOS Classic. Can anyone here comment on the aptness of this "reason" for this phenomena. After all, the built-in MacOS X facility for WebDAV does not exhibit these symptoms under Apache or WebSTAR webservers. I was of the impression that MacOS X did not use forked files as Classic did. -- ===================================================================== Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. Please note that my new e-mail address is: frank.lowney@gcsu.edu From w3c-dist-auth-request@w3.org Tue Oct 7 00:41: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 AAA05648 for ; Tue, 7 Oct 2003 00:41:41 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 57A39A0993; Tue, 7 Oct 2003 00:41:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2F9B4A0993 for ; Tue, 7 Oct 2003 00:41:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id F34FC13797; Tue, 7 Oct 2003 00:41:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by dr-nick.w3.org (Postfix) with ESMTP id D81891376F for ; Tue, 7 Oct 2003 00:41:48 -0400 (EDT) Received: from panix1.panix.com (panix1.panix.com [166.84.1.1]) by mail3.panix.com (Postfix) with ESMTP id 4D8BC98AC2; Tue, 7 Oct 2003 00:41:43 -0400 (EDT) Received: (from atlunde@localhost) by panix1.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id h974fhb29728; Tue, 7 Oct 2003 00:41:43 -0400 (EDT) Date: Tue, 7 Oct 2003 00:41:43 -0400 From: Albert Lunde To: Frank Lowney Cc: w3c-dist-auth@w3.org Message-ID: <20031007044143.GA24449@panix.com> References: <00e401c38c64$b481ce90$12ab2382@us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: WebDAV on BEA WebLogic (in support of WebCT Vista)me X-Archived-At: http://www.w3.org/mid/20031007044143.GA24449@panix.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007044150.57A39A0993@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 00:41:50 -0400 (EDT) On Mon, Oct 06, 2003 at 09:15:58PM -0400, Frank Lowney wrote: > However, I am curious about whether this reasoning applies equally to > MacOS X as it does to the preceeding operating system called MacOS > Classic. > > Can anyone here comment on the aptness of this "reason" for this > phenomena. After all, the built-in MacOS X facility for WebDAV does > not exhibit these symptoms under Apache or WebSTAR webservers. I was > of the impression that MacOS X did not use forked files as Classic > did. MacOSX still supports the use of resource forks and Finder meta-data (Type/Creator codes and a number of bits), it's just somewhat depreciated going forward. Applications ported to OSX using the Carbon Framework are more likely to use them for backwards-compatability, though that's not a hard-and-fast rule. "Bundles" out of the NeXT heritage, are the flat-file construct that is trying to superceed resource forks, etc. HFS+ has native support for Unix permissions, Finder-like attributes, and resource forks. I think the hack you cite is invoked to support them on some other file systems. However, examination of the mkisofs man page reveals the existence of a dozen or so incompatible schemes for supporting resource forks and Finder meta-data on non-Apple filesystems. so a lack of consistency is hardly surprising, I'm afraid... From w3c-dist-auth-request@w3.org Tue Oct 7 14: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 OAA16220 for ; Tue, 7 Oct 2003 14:48:37 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F24F6A0C16; Tue, 7 Oct 2003 14:48:43 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EEA4CA0CD1 for ; Tue, 7 Oct 2003 14:48:41 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B901013EF2; Tue, 7 Oct 2003 14:48:41 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 7118913EE8 for ; Tue, 7 Oct 2003 14:48:41 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A6wsw-0006Rq-00; Tue, 07 Oct 2003 18:48:38 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A6wsw-0006Rf-00; Tue, 07 Oct 2003 18:48:38 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Tue, 7 Oct 2003 11:48:51 -0700 Message-ID: <011d01c38d03$a6ecf030$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/011d01c38d03$a6ecf030$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007184843.F24F6A0C16@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 14:48:43 -0400 (EDT) Content-Transfer-Encoding: 7bit > > What if we ditched the DTD entirely and simply use English? > > I'd prefer to keep them and continue to use them the same way > as currently done in RFC2518, RFC3253 and the various drafts > closing completion. Does that mean we go back to what was in RFC2518 before the 'bis' changes started? Then we've failed to address the issue where we had interoperability problems because implementations did not allow extension elements in places where the spec ought to allow them. I know this is a failure of the implementors to follow the text in the spec to its logical conclusion, but as we've seen a clear spec is crucial to easing the way to interoperability. I can't tell what the consensus is here. I thought originally there was a consensus to clarify which elements could be extended and in what way. I attempted to do this by altering the DTD, and I also proposed doing this by replacing DTDs with English. The third option is to go back to RFC2518 DTDs and ignore the problem. I haven't seen a fourth concrete option. > All that's needed is the following general clarification: > > "This document uses XML DTD fragments as a purely notational > convention. WebDAV request and response bodies can not be > validated due to the specific extensibility rules defined in > section 23 of [RFC2518] and due to the fact that all XML > elements defined by this specification use the XML namespace > name "DAV:". In particular: > > - element names use the "DAV:" namespace, > - element ordering is irrelevant, > - extension elements (elements not already defined as valid > child elements) may be added anywhere, except when explicitly > stated otherwise, > - extension attributes (attributes not already defined as > valid for this > element) may be added anywhere, except when explicitly stated > otherwise." This doesn't seem sufficient to me unless we simply decide not to address the problem. RFC2518 already had general language of this sort to say that generally extensibility should be allowed. To solve the problem, we need to specify for every element how it may be extended, and what it means to extend it. Or we can decide not to solve the problem. > > This would tend to drive us, the spec writers, to include more > > information, more > > guidance, rather than less. That's because the DTDs don't provide an easy > > place to say whether an element may be extended with new > > elements, or under > > what conditions an element is required. > If this is the main issue, clarifying that an "ANY" content model > indicates that the element is *not* extensible (contrary to the > default case) may suffice (note that this would apply to the > content of the DAV:prop element in PROPFIND marshalling). This seems opposite to what I'd expect "ANY" would mean. The prop element is the *most* extensible because all implementations know you can put any element child in here, as long as it is a property name. Lisa From w3c-dist-auth-request@w3.org Tue Oct 7 15:14:39 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 PAA18035 for ; Tue, 7 Oct 2003 15:14:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 8C688A0CA4; Tue, 7 Oct 2003 15:14:20 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E9F8AA0CB6 for ; Tue, 7 Oct 2003 15:14:18 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 87FF513EEE; Tue, 7 Oct 2003 15:14:18 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 208451379F for ; Tue, 7 Oct 2003 15:14:18 -0400 (EDT) Received: (qmail 28171 invoked by uid 65534); 7 Oct 2003 19:14:17 -0000 Received: from p3EE2473D.dip.t-dialin.net (HELO lisa) (62.226.71.61) by mail.gmx.net (mp022) with SMTP; 07 Oct 2003 21:14:17 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Tue, 7 Oct 2003 21:14:11 +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: <011d01c38d03$a6ecf030$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEOFILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007191420.8C688A0CA4@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 15:14:20 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, October 07, 2003 8:49 PM > To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org > Subject: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > > > > > > What if we ditched the DTD entirely and simply use English? > > > > I'd prefer to keep them and continue to use them the same way > > as currently done in RFC2518, RFC3253 and the various drafts > > closing completion. > > Does that mean we go back to what was in RFC2518 before the 'bis' > changes started? Then we've failed to address the issue where > we had interoperability problems because implementations did not > allow extension elements in places where the spec ought to allow > them. Nobody suggested not doing anything at all. However, I also don't remember any agreement about removing all formal definitions (be it DTD or a different syntax) in favor of just using plain English. In fact, there doesn't seem to be an issue on the RFC2518 issues list related to this at all. > I know this is a failure of the implementors to follow the text > in the spec to its logical conclusion, but as we've seen a clear > spec is crucial to easing the way to interoperability. > > I can't tell what the consensus is here. I thought originally > there was a consensus to clarify which elements could be extended > and in what way. I attempted to do this by altering the DTD, > and I also proposed doing this by replacing DTDs with English. > The third option is to go back to RFC2518 DTDs and ignore the > problem. I haven't seen a fourth concrete option. Then you've missed it :-). I've been trying to come up with language that absolutely clarifies what the DTD fragments say. It's in the ordering draft that we all discussed just 3 months ago. I think the very same language should be used in all WebDAV specs (this may be somthing we want to sneak into the ACL spec during the AUTH period...). In fact, you're quoting that fourth option below :-). > > All that's needed is the following general clarification: > > > > "This document uses XML DTD fragments as a purely notational > > convention. WebDAV request and response bodies can not be > > validated due to the specific extensibility rules defined in > > section 23 of [RFC2518] and due to the fact that all XML > > elements defined by this specification use the XML namespace > > name "DAV:". In particular: > > > > - element names use the "DAV:" namespace, > > - element ordering is irrelevant, > > - extension elements (elements not already defined as valid > > child elements) may be added anywhere, except when explicitly > > stated otherwise, > > - extension attributes (attributes not already defined as > > valid for this > > element) may be added anywhere, except when explicitly stated > > otherwise." > > This doesn't seem sufficient to me unless we simply decide not > to address the problem. RFC2518 already had general language of > this sort to say that generally extensibility should be allowed. > To solve the problem, we need to specify for every element how > it may be extended, and what it means to extend it. Or we can > decide not to solve the problem. Again: no, we don't need to specify that, and we can't. If an element is extensible, there's no point in discussing what an extension could mean. It could mean anything, that's the point of an extension. On the other hand, if an element can't be extended (in RFC2518, that seems to be just and ), then that's all we need to say as well. > > If this is the main issue, clarifying that an "ANY" content model > > indicates that the element is *not* extensible (contrary to the > > default case) may suffice (note that this would apply to the > > content of the DAV:prop element in PROPFIND marshalling). > > This seems opposite to what I'd expect "ANY" would mean. The prop > element is the *most* extensible because all implementations know > you can put any element child in here, as long as it is a property name. Sorry, Lisa, but this is just plain wrong. is not extensible *because* it already has a defined semantics for each possible child element. That's *why* the content model say's "ANY". It means: you could put any element here, and the spec defines what that means. On the other hand, elements with closed content models (such as ) are the elements that *can* be extended. Looking at the DTD in RFC2518, "ANY" is used exactly three times: prop: whatever child element you put here, it identifies a property resourcetype: whatever child element you put here, it identifies a resource type owner: content model is completely by definition So, with the exception of DAV:owner, "ANY" is used exactly in those cases, where the element can *not* be extended, and I'd be really surprised to hear that this wasn't on purpose. Hmm. Maybe the issue is that there's a disagreement about what "extensible" mean. When I say "extensible", I'm talking about the thing described in RFC2518, Appendix "Example - Unknown XML Element"... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 7 17:11:39 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 RAA22664 for ; Tue, 7 Oct 2003 17:11:38 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C58FFA0CD0; Tue, 7 Oct 2003 17:11:44 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 92512A0CD0 for ; Tue, 7 Oct 2003 17:11:43 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 33E0C13F17; Tue, 7 Oct 2003 17:11:43 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id DE46213448 for ; Tue, 7 Oct 2003 17:11:42 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A6z7O-0007yt-00; Tue, 07 Oct 2003 21:11:42 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A6z7N-0007yi-00; Tue, 07 Oct 2003 21:11:41 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Tue, 7 Oct 2003 14:11:55 -0700 Message-ID: <014401c38d17$a30b3210$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/014401c38d17$a30b3210$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007211144.C58FFA0CD0@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 17:11:44 -0400 (EDT) Content-Transfer-Encoding: 7bit > Nobody suggested not doing anything at all. However, I also > don't remember any agreement about removing all formal > definitions (be it DTD or a different syntax) in favor of > just using plain English. In fact, there doesn't seem to be > an issue on the RFC2518 issues list related to this at all. That's not what I said - I also don't recall any agreement about removing all formal definitions. Instead, I believe we decided to address a certain problem, which was interoperability problems due to implementations having trouble accepting extensions in some elements. Assuming we still have consensus about addressing this problem, I'm trying to determine consensus about *how* to address this problem. > Then you've missed it :-). I've been trying to come up with > language that absolutely clarifies what the DTD fragments > say. It's in the ordering draft that we all discussed just 3 > months ago. I think the very same language should be used in > all WebDAV specs (this may be somthing we want to sneak into > the ACL spec during the AUTH period...). I'm sorry, I don't see how the ordering draft does anything signficantly different here. For example, this is from the ordering draft: This is exactly like RFC2518, and I couldn't find additional text to specify whether orderpatch can have custom child elements. > To solve > > the problem, we need to specify for every element how it may be > > extended, and what it means to extend it. Or we can decide not to > > solve the problem. > > Again: no, we don't need to specify that, and we can't. If an > element is extensible, there's no point in discussing what an > extension could mean. It could mean anything, that's the > point of an extension. On the other hand, if an element can't > be extended (in RFC2518, that seems to be just and > ), then that's all we need to say as well. Yes, we can do that. For example, the text for RFC2518bis says: The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element. That's an example of a "negative" restriction, where the element being defined can't be extended in just any way. The opposite example might be to define the element as extensible in the DTD: And we could add more text for example (made up on the spot: it is expected that resourcetype will be extended with new standard or custom child elements when new resourcetypes are defined. Resources types that are unrecognized should be treated as regular resources. Resource type values that contain DAV:collection as well as additional unrecognized elements or child elements within DAV:collection should be treated as collections. Yes, it's a lot of work to do this thinking, but I think we ought to do it -- and perhaps throw away the DTD if it gets in our way or confuses readers. > Sorry, Lisa, but this is just plain wrong. is not extensible > *because* it already has a defined semantics for each > possible child element. That's *why* the content model say's > "ANY". It means: you could put any element here, and the spec > defines what that means. We must have different meanings of the word extensible. I'm trying to adapt DTDs to our XML usage here. Since the list of elements you can put in the 'prop' element is not limited, I call it extensible. Would you like me to use a different word for this? I use this word in this way to distinguish from the element which is not extensible because it can only contain URIs. > On the other hand, elements with closed content models (such > as ) are the elements that *can* be extended. > Looking at the DTD in RFC2518, "ANY" is used exactly three times: > > prop: whatever child element you put here, it identifies a property > resourcetype: whatever child element you put here, it > identifies a resource type > owner: content model is completely by definition > > So, with the exception of DAV:owner, "ANY" is used exactly in > those cases, where the element can *not* be extended, and I'd > be really surprised to hear that this wasn't on purpose. Would it have been any different if the element had been defined in a DTD like this: This would be very much in spirit with the rest of RFC2518, because it defines the known elements from the rest of the spec that can appear in the 'prop' element. Because of the general extensibility rules it doesn't change the way it can be used. Does that change the 'prop' element from what you call unextensible to what you call extensible? I think you're making a distinction without a difference here. > Hmm. Maybe the issue is that there's a disagreement about > what "extensible" mean. When I say "extensible", I'm talking > about the thing described in RFC2518, Appendix "Example - > Unknown XML Element"... Heh heh- I said the same thing before I read so far. So perhaps we can agree on some more helpful terminology: - *fully extensible* elements like 'response' can contain any elements not defined in RFC2518 and their meaning is not pre-defined. - *partially extensible* elements like 'prop' aren't limited to a known set of child elements but the meaning of child elements is strictly defined. - *unextensible* elements (possibly lockscope should be?) have a known and limited set of child elements allowed. Given that elements like 'response' and 'prop' are extended (by adding currently unknown child elements) in different ways - one has a known meaning, and one has an unknown meaning - surely we can say more about this in RFC2518bis. Because otherwise, implementors tend to assume that the 'resourcetype' element can only contain 'collection' or nothing. Back to the question I'm trying to ask: how should we make it clearer to implementors that an element like 'resourcetype' can have more than just 'collection' sub-element or nothing? Should we attempt to do this in the DTD (if so how) or in English? If we do so in English, does the DTD become misleading, drawing the reader away from the important parts of the element's definition? Lisa From w3c-dist-auth-request@w3.org Tue Oct 7 17:45: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 RAA23656 for ; Tue, 7 Oct 2003 17:45:32 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D2F6AA0D0F; Tue, 7 Oct 2003 17:45:41 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id CDBAFA0D0F for ; Tue, 7 Oct 2003 17:45:39 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9BEFE13F3D; Tue, 7 Oct 2003 17:45:39 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by dr-nick.w3.org (Postfix) with ESMTP id 7C82813F28 for ; Tue, 7 Oct 2003 17:45:39 -0400 (EDT) Received: from panix1.panix.com (panix1.panix.com [166.84.1.1]) by mail1.panix.com (Postfix) with ESMTP id 6A8A448726; Tue, 7 Oct 2003 17:45:31 -0400 (EDT) Received: (from atlunde@localhost) by panix1.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id h97LjVI10497; Tue, 7 Oct 2003 17:45:31 -0400 (EDT) Date: Tue, 7 Oct 2003 17:45:31 -0400 From: Albert Lunde To: Frank Lowney Cc: w3c-dist-auth@w3.org Message-ID: <20031007214531.GA20456@panix.com> References: <00e401c38c64$b481ce90$12ab2382@us.oracle.com> <20031007044143.GA24449@panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: WebDAV on BEA WebLogic (in support of WebCT Vista)me X-Archived-At: http://www.w3.org/mid/20031007214531.GA20456@panix.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7944 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007214541.D2F6AA0D0F@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 17:45:41 -0400 (EDT) On Tue, Oct 07, 2003 at 11:30:21AM -0400, Frank Lowney wrote: > Albert, > > I appreciate your reply and your point about carbon apps such as > Goliath having to support legacy file systems is well taken but our > issue was with the use of the MacOS X built-in WebDAV client, a > native (coco) app I believe. This client does well with Apache and > WebSTAR V but not with BEA Weblogic. We haven't yet tested other > native coco apps such as Adobe GoLive and Macromedia Dreamweaver but > I would imagine that they are also quite independent of and do not > use forked files. > > Are you saying that the "hack" is in BEA Weblogic or elsewhere? If > it's in BEA WebLogic, then their hack is breaking a > standards-compliant client. 1) I am saying OS X still supports resource forks at the file system level, independent of statements about specific applications. 2) Cocoa applications can do resource folks too, they are just less likely to need do so for their own sake. But Apple is probably continuing to build resource fork support into GUI file manipulation tools regardless of what development tools they are written with. (The Carbon/Cocoa divide is getting more fuzzy over time, too.) 3) The "hack" is a matter of how well-integrated resource fork support is in a given filesystem: it's a low-level feature of HFS+, but it's a more visible layer on top of some other file systems. The problem with being "standards-compliant" in this context, is there are so many options to choose from: a number of defacto ways to represent resource forks, plus the options of throwing away resource forks and/or finder metadata entirely. I think IETF standards like HTTP and WEBDAV are silent about Apple-specific file system features like resource forks. Throwing away resource forks plays nicely with the non-Apple web world, but starts get messy if you mix general purpose file servers with web servers, as I think Apple has done with its .Mac service. I think the prior usage of this particular representation of resource forks on Mac OSX was with UFS and NFS filesystems. I don't claim to be an expert on this subject so take this with some reservations. From w3c-dist-auth-request@w3.org Tue Oct 7 18:37:39 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 SAA26317 for ; Tue, 7 Oct 2003 18:37:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CAA22A0CDE; Tue, 7 Oct 2003 18:37:47 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id CF792A0D4E for ; Tue, 7 Oct 2003 18:37:46 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A98E313AB1; Tue, 7 Oct 2003 18:37:46 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id 2C1C51358E for ; Tue, 7 Oct 2003 18:37:46 -0400 (EDT) Received: from Tycho (dhcp-63-196.cse.ucsc.edu [128.114.63.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h97MYHa15962 for ; Tue, 7 Oct 2003 15:34:17 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 7 Oct 2003 15:36:14 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMECHJKAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007223747.CAA22A0CDE@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 18:37:47 -0400 (EDT) Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Sung Kim [mailto:hunkim@soe.ucsc.edu] Sent: Monday, October 06, 2003 7:26 PM To: Eric Sedlar Cc: Julian Reschke; Geoffrey M Clemm; 'Ted Hardie'; acl@webdav.org; acl-bounces@webdav.org; Lisa Dusseault; 'Webdav WG'; 'Jim Whitehead' Subject: [Moderator Action] Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call +1 -- Sung Kim http://www.cse.ucsc.edu/~hunkim "Dreams become reality!" On Mon, 6 Oct 2003, Eric Sedlar wrote: > +1 > ----- Original Message ----- > From: Geoffrey M Clemm > To: Julian Reschke > Cc: 'Ted Hardie' ; acl@webdav.org ; acl-bounces@webdav.org ; Lisa Dusseault ; 'Webdav WG' ; 'Jim Whitehead' > Sent: Monday, October 06, 2003 3:23 PM > Subject: Re: [ACL] RE: ANNOUNCE: ACL draft to WebDAV working group last call > > > > Julian wrote on 10/06/2003 02:16:32 PM: > > > > From: Lisa Dusseault > ... > > > suggestion to add write-collection > > > --> no support voiced in response > > > > I may have missed this one: isn't this simply DAV:bind? > > The proposed "write-collection" was DAV:bind + DAV:unbind. > This is easily achieved by having the client just specify > DAV:bind and DAV:unbind, and so does not warrant its own > privilege. > > > > I don't think any of these prevent the document from going forward after > > > last call finishes so if there is disagreement please raise it on the > > > acl list. > > > > Agreed. > > +1 > > Cheers, > Geoff > > > > -------------------------------------------------------------------------- ---- > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > From w3c-dist-auth-request@w3.org Tue Oct 7 19:21: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 TAA27361 for ; Tue, 7 Oct 2003 19:21:09 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 69E4BA083D; Tue, 7 Oct 2003 19:21:18 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 43995A0A8E for ; Tue, 7 Oct 2003 19:21:17 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C3B7713F79; Tue, 7 Oct 2003 19:21:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 32E5613F49 for ; Tue, 7 Oct 2003 19:21:16 -0400 (EDT) Received: (qmail 20349 invoked by uid 65534); 7 Oct 2003 23:21:05 -0000 Received: from p3EE2473D.dip.t-dialin.net (HELO lisa) (62.226.71.61) by mail.gmx.net (mp007) with SMTP; 08 Oct 2003 01:21:05 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Wed, 8 Oct 2003 01:20:47 +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: <014401c38d17$a30b3210$f8cb90c6@lisalap> Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEOOILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031007232118.69E4BA083D@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 19:21:18 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, October 07, 2003 11:12 PM > To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > > > > Nobody suggested not doing anything at all. However, I also > > don't remember any agreement about removing all formal > > definitions (be it DTD or a different syntax) in favor of > > just using plain English. In fact, there doesn't seem to be > > an issue on the RFC2518 issues list related to this at all. > > That's not what I said - I also don't recall any agreement about > removing all formal definitions. Instead, I believe we decided to > address a certain problem, which was interoperability problems due > to implementations having trouble accepting extensions in some > elements. Assuming we still have consensus about addressing this > problem, I'm trying to determine consensus about *how* to address > this problem. OK, we're in agreement. In particular, one issue I do remember are certain clients that insist in popping up warning messages when a server extends a response in an unexpected way. However, I fear that RFC2518 already was very clear about the extensibility rules, so I'm not sure that any amount of additional language would have avoided that. The main issue is that we are (were) using DTD fragments, but we also state(d) that WebDAV messages can't be validated. Many people seem to be confused about that. The options here some to be: - try harder to explain it - choose a schema language that allows to express RFC2518's extensibility rules (as far as I understand, that would require Relax NG, XML Schema *won't* do that) - do not use any formal language at all (this I think would be a mistake) > > Then you've missed it :-). I've been trying to come up with > > language that absolutely clarifies what the DTD fragments > > say. It's in the ordering draft that we all discussed just 3 > > months ago. I think the very same language should be used in > > all WebDAV specs (this may be somthing we want to sneak into > > the ACL spec during the AUTH period...). > > I'm sorry, I don't see how the ordering draft does anything > signficantly different here. For example, this is from the > ordering draft: > > > > This is exactly like RFC2518, and I couldn't find additional text > to specify whether orderpatch can have custom child elements. - The additional language about what DTD fragments mean is in section 1 (Notational Conventions) - In fact, the standard RFC2518 rules apply, so all of these can have custom child elements -- just like in RFC3253 and ACL. > > To solve > > > the problem, we need to specify for every element how it may be > > > extended, and what it means to extend it. Or we can decide not to > > > solve the problem. > > > > Again: no, we don't need to specify that, and we can't. If an > > element is extensible, there's no point in discussing what an > > extension could mean. It could mean anything, that's the > > point of an extension. On the other hand, if an element can't > > be extended (in RFC2518, that seems to be just and > > ), then that's all we need to say as well. > > Yes, we can do that. For example, the text for RFC2518bis says: > > The prop XML element is a generic container for > properties defined on resources. All elements inside a > prop XML element MUST define properties related to the > resource. No other elements may be used inside of a prop > element. > > That's an example of a "negative" restriction, where the element > being defined can't be extended in just any way. The opposite example Yes. It's not extensible. The DTD should state ANY, and probably the description should state explicitly what this means. > might be to define the element as extensible in the DTD: > > No no no. This does not mean that the element is extensible. It means that the DTD already expects "ANY" content, thus meaning already has been assigned to arbitrary child elements. Thus the element is *not* extensible. What's extensible here is the set of valid resource types, but whatever you put into DAV:resourcetype will always identify a resource type. > And we could add more text for example (made up on the spot: > > it is expected that resourcetype will be extended with new > standard or custom child elements when new resourcetypes are > defined. Resources types that are unrecognized should > be treated as regular resources. Resource type values that > contain DAV:collection as well as additional unrecognized > elements or child elements within DAV:collection should be > treated as collections. > > Yes, it's a lot of work to do this thinking, but I think we ought to do > it -- and perhaps throw away the DTD if it gets in our way or confuses > readers. I think we should both keep the DTDs as formal (and normative definition with the known caveats), *and* explain what it means (when there's a chance it's not clear). > > Sorry, Lisa, but this is just plain wrong. is not extensible > > *because* it already has a defined semantics for each > > possible child element. That's *why* the content model say's > > "ANY". It means: you could put any element here, and the spec > > defines what that means. > > We must have different meanings of the word extensible. I'm > trying to adapt DTDs to our XML usage here. Since the list of > elements you can put in the 'prop' element is not limited, I call > it extensible. Would you like me to use a different word for this? Yes. It is definitively not extensible in the way described by the "RFC2518 extensibility rules", described in the appendix (which state that any element you don't know must be ignored). > I use this word in this way to distinguish from the element > which is not extensible because it can only contain URIs. Fascinating. I'd say it's extensible. For instance, I client should handle foo the same way as foo (I'm not saying that I'd expect many clients to handle this gracefully, but RFC2518 definitively allows this -- maybe that's a candidate for the issues list). > > On the other hand, elements with closed content models (such > > as ) are the elements that *can* be extended. > > Looking at the DTD in RFC2518, "ANY" is used exactly three times: > > > > prop: whatever child element you put here, it identifies a property > > resourcetype: whatever child element you put here, it > > identifies a resource type > > owner: content model is completely by definition > > > > So, with the exception of DAV:owner, "ANY" is used exactly in > > those cases, where the element can *not* be extended, and I'd > > be really surprised to hear that this wasn't on purpose. > > Would it have been any different if the element had been > defined in a DTD like this: > > getcontentlanguage?, getcontentlength?, > getcontenttype?, getetag?, getlastmodified?, > lockdiscovery?)> Yes. That would mean that I could do a PROPFIND/prop/foobar and the server would be allowed to ignore the foobar element (which would be wrong). > This would be very much in spirit with the rest of RFC2518, > because it defines the known elements from the rest of the spec > that can appear in the 'prop' element. Because of the general > extensibility rules it doesn't change the way it can be used. Yes it does. A server must respect *all* child elements of prop, whether known or unknown. Thus is one of the few protocol elements that are *not* extensible, because the spec already assigns meaning to all possible child elements (ANY!). > Does that change the 'prop' element from what you call unextensible > to what you call extensible? I think you're making a distinction > without a difference here. Yes it does, and I just described the difference. > > Hmm. Maybe the issue is that there's a disagreement about > > what "extensible" mean. When I say "extensible", I'm talking > > about the thing described in RFC2518, Appendix "Example - > > Unknown XML Element"... (actually, I should have been referring to section 14) > Heh heh- I said the same thing before I read so far. > > So perhaps we can agree on some more helpful terminology: > > - *fully extensible* elements like 'response' can contain any > elements not defined in RFC2518 and their meaning is not pre-defined. > - *partially extensible* elements like 'prop' aren't limited to > a known set of child elements but the meaning of child elements is > strictly defined. > - *unextensible* elements (possibly lockscope should be?) have a > known and > limited set of child elements allowed. Agreed, except I'd prefer something different than "partially extensible", and I'm not sure that the class of "unextensible" actually exists. > Given that elements like 'response' and 'prop' are extended (by adding > currently unknown child elements) in different ways - one has a > known meaning, and one has an unknown meaning - surely we can say more > about this in RFC2518bis. Because otherwise, implementors tend to > assume that the 'resourcetype' element can only contain 'collection' > or nothing. OK, so we just need to find a good name. > Back to the question I'm trying to ask: how should we make it clearer > to implementors that an element like 'resourcetype' can have more than > just 'collection' sub-element or nothing? Should we attempt to do this > in the DTD (if so how) or in English? If we do so in English, does the > DTD become misleading, drawing the reader away from the important parts > of the element's definition? Both. The DTD should be normative and just say "ANY" (like it did in RFC2518). We also should clearly state what "ANY" means regarding extensibility (it means that the extensibility rules from section 14 do NOT apply). In addition, it won't hurt to restate it in plain english -- but I think the DTDs should stay (unless we can replace them with a better *formal* definition). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 7 20:32:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29323 for ; Tue, 7 Oct 2003 20:32:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 01E0BA0ADB; Tue, 7 Oct 2003 20:32:12 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C5F77A0ADB for ; Tue, 7 Oct 2003 20:32:11 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id ABC7F13F66; Tue, 7 Oct 2003 20:32:11 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 7AE0C13EEA for ; Tue, 7 Oct 2003 20:32:11 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A72FM-0001u4-00; Wed, 08 Oct 2003 00:32:08 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A72FM-0001tt-00; Wed, 08 Oct 2003 00:32:08 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Tue, 7 Oct 2003 17:32:21 -0700 Message-ID: <017c01c38d33$a339ab60$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/017c01c38d33$a339ab60$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008003212.01E0BA0ADB@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 20:32:12 -0400 (EDT) Content-Transfer-Encoding: 7bit > Both. The DTD should be normative and just say "ANY" (like it > did in RFC2518). We also should clearly state what "ANY" > means regarding extensibility (it means that the > extensibility rules from section 14 do NOT apply). In > addition, it won't hurt to restate it in plain english -- but > I think the DTDs should stay (unless we can replace them with a better > *formal* definition). The DTD cannot be normative - it doesn't give the whole picture. An appendix can't be normative. The DTD fragments in subsections of section 12 could be normative in combination with the XML extension rules *and* the specific element value rules, but the spec doesn't specifically say this. What if we omitted the summary DTD in appendix 1 (23.1), and instead had only DTD fragments with each property? THen the reader of the spec would be more likley to read the whole definition, rather than the shortcut of going to the appendix and only seeing part of the whole picture. Another idea. As long as we're stating what ANY means, why limit ourslves. Eg. we could use pseudo-DTD syntax -- extending the definitions to say more of what we want them to say. We could call it a WebDAV-DTD if it offends people to redefine XML DTD. E.g. I don't know how we'd go about formally extending DTDs to do this or if that's important, but since the DTD in appendix 23.1 isn't normative presumably that would not be illegal. In my opinion the important thing to keep our eyes on here is to make the spec as readable, as implementable, and as conducive to interoperability, as we can. "Rules" about DTDs or definitions are there as our tools, to reshape into better tools if we can, to achieve our main goals in this spec. Lisa From w3c-dist-auth-request@w3.org Tue Oct 7 20:46: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 UAA29709 for ; Tue, 7 Oct 2003 20:46:31 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 85786A0585; Tue, 7 Oct 2003 20:46:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DE630A0585 for ; Tue, 7 Oct 2003 20:46:14 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id AC982136F3; Tue, 7 Oct 2003 20:46:14 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 92EB713452 for ; Tue, 7 Oct 2003 20:46:14 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A72T0-00020M-00 for w3c-dist-auth@w3c.org; Wed, 08 Oct 2003 00:46:14 +0000 Received: from [192.168.1.151] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A72T0-00020B-00 for w3c-dist-auth@w3c.org; Wed, 08 Oct 2003 00:46:14 +0000 From: "Lisa Dusseault" To: "'Webdav WG'" Date: Tue, 7 Oct 2003 17:46:27 -0700 Message-ID: <017e01c38d35$9b72c900$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: WebDAV resources must be in collections? (CONSISTENCY) X-Archived-At: http://www.w3.org/mid/017e01c38d35$9b72c900$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7948 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008004617.85786A0585@frink.w3.org> Resent-Date: Tue, 7 Oct 2003 20:46:17 -0400 (EDT) Content-Transfer-Encoding: quoted-printable This is the CONSISTENCY issue in = http://www.webdav.org/wg/rfcdev/issues.htm. RFC2518 says: " An HTTP URL namespace is said to be consistent if it meets the following conditions: for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member. The root, or top-level collection of the namespace under consideration is exempt from the previous rule." Roy Fielding - = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html: "There is no need for that requirement and it is the root of many terminology issues. Any individual resource is capable of being or not being DAVable, as determined by either the capabilities described by an OPTIONS response" I've been thinking of a use case for WebDAV resources that may not=20 be in WebDAV-capable collections. The SIMPLE WG has discussed=20 making Buddy lists be (in one model) a WebDAV resource. This would=20 mean that the buddy list could be locked, unlocked, could support PROPFIND and PROPPATCH, could support the basic WebDAV properties=20 to know when the content changed and what the ETag is. It could=20 have an owner and support the ACL method and the acl property. Should we remove this consistency requirement from RFC2518bis? Lisa From w3c-dist-auth-request@w3.org Wed Oct 8 03:54:16 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 DAA05446 for ; Wed, 8 Oct 2003 03:54:16 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 59534A094B; Wed, 8 Oct 2003 03:54:21 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id F15DEA094B for ; Wed, 8 Oct 2003 03:54:15 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id E6CFB14018; Wed, 8 Oct 2003 03:51:14 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 7D84413362 for ; Wed, 8 Oct 2003 03:51:14 -0400 (EDT) Received: (qmail 8168 invoked by uid 65534); 8 Oct 2003 07:51:13 -0000 Received: from p3EE2473D.dip.t-dialin.net (HELO lisa) (62.226.71.61) by mail.gmx.net (mp004) with SMTP; 08 Oct 2003 09:51:13 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Webdav WG'" Date: Wed, 8 Oct 2003 09:51:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <017e01c38d35$9b72c900$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: WebDAV resources must be in collections? (CONSISTENCY) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPGILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7949 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008075421.59534A094B@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 03:54:21 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Lisa, what you are talking about is the consistency *definition*. Of course = it's possible to have WebDAV-compliant resources in non-consistent = namespaces. What we'll have to look fot is where the term is *used*. If it isn't, = the definition can go. However, I think we need it to define the = behaviour of namespace operations such as MOVE? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760=20 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 08, 2003 2:46 AM > To: 'Webdav WG' > Subject: WebDAV resources must be in collections? (CONSISTENCY) >=20 >=20 >=20 >=20 > This is the CONSISTENCY issue in=20 > http://www.webdav.org/wg/rfcdev/issues.htm. >=20 > RFC2518 says: >=20 > " An HTTP URL namespace is said to be consistent if it meets the > following conditions: for every URL in the HTTP hierarchy there > exists a collection that contains that URL as an internal member. > The root, or top-level collection of the namespace under > consideration is exempt from the previous rule." >=20 > Roy Fielding -=20 > = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html: >=20 > "There is no need for that requirement and it > is the root of many terminology issues. Any individual resource is > capable of being or not being DAVable, as determined by either the > capabilities described by an OPTIONS response" >=20 > I've been thinking of a use case for WebDAV resources that may not=20 > be in WebDAV-capable collections. The SIMPLE WG has discussed=20 > making Buddy lists be (in one model) a WebDAV resource. This would=20 > mean that the buddy list could be locked, unlocked, could support > PROPFIND and PROPPATCH, could support the basic WebDAV properties=20 > to know when the content changed and what the ETag is. It could=20 > have an owner and support the ACL method and the acl property. >=20 > Should we remove this consistency requirement from RFC2518bis? >=20 > Lisa >=20 >=20 From w3c-dist-auth-request@w3.org Wed Oct 8 04:01:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05743 for ; Wed, 8 Oct 2003 04:01:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 39399A055A; Wed, 8 Oct 2003 04:01:41 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 23957A0799 for ; Wed, 8 Oct 2003 04:01:39 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id CB72F134C9; Wed, 8 Oct 2003 04:01:38 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 653A3134B2 for ; Wed, 8 Oct 2003 04:01:38 -0400 (EDT) Received: (qmail 29427 invoked by uid 65534); 8 Oct 2003 08:01:37 -0000 Received: from p3EE2473D.dip.t-dialin.net (HELO lisa) (62.226.71.61) by mail.gmx.net (mp023) with SMTP; 08 Oct 2003 10:01:37 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Wed, 8 Oct 2003 10:01:34 +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: <017c01c38d33$a339ab60$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEPHILAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7950 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008080141.39399A055A@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 04:01:41 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 08, 2003 2:32 AM > To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > > > > > Both. The DTD should be normative and just say "ANY" (like it > > did in RFC2518). We also should clearly state what "ANY" > > means regarding extensibility (it means that the > > extensibility rules from section 14 do NOT apply). In > > addition, it won't hurt to restate it in plain english -- but > > I think the DTDs should stay (unless we can replace them with a better > > *formal* definition). > > The DTD cannot be normative - it doesn't give the whole picture. I can be *made* normative. That's what I'm trying to do. > An appendix can't be normative. The DTD fragments in subsections Yes it can. Quoting from RFC223bis (07): 4.7e Appendixes Many RFC documents have appendices, some of which may be very extensive. Common practice is to position Appendixes at the very end of a document, after the references. However, a significant set of RFCs have large and dense Appendix sections for technical details, which are actually an integral part of the document. In this case, it can be difficult to locate the references. We therefore recommend that, in general, references follow the Appendixes in an RFC. I agree that informative parts are usually in the appendix, but that doesn't mean that any appendix is automatically non-normative. > of section 12 could be normative in combination with the XML > extension rules *and* the specific element value rules, but > the spec doesn't specifically say this. That's what we should fix. > What if we omitted the summary DTD in appendix 1 (23.1), > and instead had only DTD fragments with each property? THen the > reader of the spec would be more likley to read the whole > definition, rather than the shortcut of going to the appendix and > only seeing part of the whole picture. That sounds like a good idea. > Another idea. As long as we're stating what ANY means, why limit > ourslves. Eg. we could use pseudo-DTD syntax -- extending the definitions > to say more of what we want them to say. We could call it a WebDAV-DTD > if it offends people to redefine XML DTD. > > E.g. > locktoken?, *) > > > > > > I don't know how we'd go about formally extending DTDs to do this > or if that's important, but since the DTD in appendix 23.1 isn't > normative presumably that would not be illegal. We could, but I'm not sure why we would want to do that. The DTD fragments define allowable *syntax*. The allowable content model for PROP *is* ANY. > In my opinion the important thing to keep our eyes on here is to > make the spec as readable, as implementable, and as conducive to > interoperability, as we can. "Rules" about DTDs or definitions are > there as our tools, to reshape into better tools if we can, to > achieve our main goals in this spec. Yes. IMHO the basis should be a formal description that is normative, and in those cases where we feel that people may not "get it", add additional English language. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 8 04:20: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 EAA06136 for ; Wed, 8 Oct 2003 04:20:30 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A1D36A0885; Wed, 8 Oct 2003 04:20:36 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3D2DCA0526 for ; Wed, 8 Oct 2003 04:20:33 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C297613FFE; Wed, 8 Oct 2003 04:20:32 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id E255F14000 for ; Wed, 8 Oct 2003 04:20:31 -0400 (EDT) Received: from greenbytes.de ([192.168.1.23]) (authenticated user se@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v6.8.5.R) with ESMTP id 20-md50000000010.tmp for ; Wed, 08 Oct 2003 10:19:25 +0200 Date: Wed, 8 Oct 2003 10:19:22 +0200 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Lisa Dusseault" , "'Webdav WG'" To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: <1F6C98EA-F968-11D7-94B3-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Wed, 08 Oct 2003 10:19:25 +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@w3c.org Subject: Re: WebDAV resources must be in collections? (CONSISTENCY) X-Archived-At: http://www.w3.org/mid/1F6C98EA-F968-11D7-94B3-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7951 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008082036.A1D36A0885@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 04:20:36 -0400 (EDT) Content-Transfer-Encoding: 7bit A quick scan of 2518 revealed that the "consistent namespace" definition is used with COPY/MOVE/DELETE to define restrictions on the outcome of the operation. E.g. that the copied/moved/deleted resource created a consistent namespace, especially in case of collections. I think that definition and the restrictions on COPY/MOVE/DELETE are necessary and, in particular, do allow single WebDAV resources on a server without an embedding, WebDAV-enabled collection. Regards, Stefan Am Mittwoch, 08.10.03, um 09:51 Uhr (Europe/Berlin) schrieb Julian Reschke: > > Lisa, > > what you are talking about is the consistency *definition*. Of course > it's possible to have WebDAV-compliant resources in non-consistent > namespaces. > > What we'll have to look fot is where the term is *used*. If it isn't, > the definition can go. However, I think we need it to define the > behaviour of namespace operations such as MOVE? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault >> Sent: Wednesday, October 08, 2003 2:46 AM >> To: 'Webdav WG' >> Subject: WebDAV resources must be in collections? (CONSISTENCY) >> >> >> >> >> This is the CONSISTENCY issue in >> http://www.webdav.org/wg/rfcdev/issues.htm. >> >> RFC2518 says: >> >> " An HTTP URL namespace is said to be consistent if it meets the >> following conditions: for every URL in the HTTP hierarchy there >> exists a collection that contains that URL as an internal member. >> The root, or top-level collection of the namespace under >> consideration is exempt from the previous rule." >> >> Roy Fielding - >> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/ >> 0155.html: >> >> "There is no need for that requirement and it >> is the root of many terminology issues. Any individual resource is >> capable of being or not being DAVable, as determined by either the >> capabilities described by an OPTIONS response" >> >> I've been thinking of a use case for WebDAV resources that may not >> be in WebDAV-capable collections. The SIMPLE WG has discussed >> making Buddy lists be (in one model) a WebDAV resource. This would >> mean that the buddy list could be locked, unlocked, could support >> PROPFIND and PROPPATCH, could support the basic WebDAV properties >> to know when the content changed and what the ETag is. It could >> have an owner and support the ACL method and the acl property. >> >> Should we remove this consistency requirement from RFC2518bis? >> >> Lisa >> >> From w3c-dist-auth-request@w3.org Wed Oct 8 12:07:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25208 for ; Wed, 8 Oct 2003 12:07:24 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 54972A0BED; Wed, 8 Oct 2003 12:06:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 292B5A0BDD for ; Wed, 8 Oct 2003 12:06:50 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C820B13499; Wed, 8 Oct 2003 12:06:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (Postfix) with ESMTP id 64FF1138D5 for ; Wed, 8 Oct 2003 12:06:49 -0400 (EDT) Received: from Tycho (dhcp-63-196.cse.ucsc.edu [128.114.63.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h98G4Ia00679 for ; Wed, 8 Oct 2003 09:04:18 -0700 (PDT) From: "Jim Whitehead" To: "'Webdav WG'" Date: Wed, 8 Oct 2003 09:06:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: <017e01c38d35$9b72c900$f8cb90c6@lisalap> X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: WebDAV resources must be in collections? (CONSISTENCY) X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEDKJKAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7952 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008160654.54972A0BED@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 12:06:54 -0400 (EDT) Content-Transfer-Encoding: quoted-printable I'm OK with this. Implementors tend to do the "right" thing wrt = consistency when it matters, and the current language has caused = confusion far beyond its worth. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, October 07, 2003 5:46 PM > To: 'Webdav WG' > Subject: WebDAV resources must be in collections? (CONSISTENCY) >=20 >=20 >=20 >=20 > This is the CONSISTENCY issue in=20 > http://www.webdav.org/wg/rfcdev/issues.htm. >=20 > RFC2518 says: >=20 > " An HTTP URL namespace is said to be consistent if it meets the > following conditions: for every URL in the HTTP hierarchy there > exists a collection that contains that URL as an internal member. > The root, or top-level collection of the namespace under > consideration is exempt from the previous rule." >=20 > Roy Fielding -=20 > = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html: >=20 > "There is no need for that requirement and it > is the root of many terminology issues. Any individual resource is > capable of being or not being DAVable, as determined by either the > capabilities described by an OPTIONS response" >=20 > I've been thinking of a use case for WebDAV resources that may not=20 > be in WebDAV-capable collections. The SIMPLE WG has discussed=20 > making Buddy lists be (in one model) a WebDAV resource. This would=20 > mean that the buddy list could be locked, unlocked, could support > PROPFIND and PROPPATCH, could support the basic WebDAV properties=20 > to know when the content changed and what the ETag is. It could=20 > have an owner and support the ACL method and the acl property. >=20 > Should we remove this consistency requirement from RFC2518bis? >=20 > Lisa >=20 >=20 From w3c-dist-auth-request@w3.org Wed Oct 8 12:14: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 MAA25597 for ; Wed, 8 Oct 2003 12:14:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 79F39A0BF1; Wed, 8 Oct 2003 12:14:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 69431A0D80 for ; Wed, 8 Oct 2003 12:14:32 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5613813420; Wed, 8 Oct 2003 12:14:17 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id E3A99137B1 for ; Wed, 8 Oct 2003 12:14:16 -0400 (EDT) Received: (qmail 30317 invoked by uid 65534); 8 Oct 2003 16:14:16 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012) with SMTP; 08 Oct 2003 18:14:16 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Jim Whitehead" , "'Webdav WG'" Date: Wed, 8 Oct 2003 18:14:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: WebDAV resources must be in collections? (CONSISTENCY) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEAHIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7953 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008161450.79F39A0BF1@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 12:14:50 -0400 (EDT) Content-Transfer-Encoding: quoted-printable It's causing confusion right now :-) Looking at Roy's original complaint...: "My comment was regarding the requirement that DAV capable resources be within a DAV collection. There is no need for that requirement and it is the root of many terminology issues. Any individual resource is capable of being or not being DAVable, as determined by either the capabilities described by an OPTIONS response or by the error response received when attempting to do a WebDAV operation on a non-DAV resource. "Save as..." dialogs are cool, but not necessary, for authoring." So it's not about the term "consistent namespace", it's about = "DAV-capable resource". I don't think that what Roy actually complained = about is (section 5): "All DAV compliant resources MUST support the HTTP URL namespace model = specified herein." This seems to be what needs to go, not the definition of consistency. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760=20 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, October 08, 2003 6:06 PM > To: 'Webdav WG' > Subject: RE: WebDAV resources must be in collections? (CONSISTENCY) >=20 >=20 >=20 > I'm OK with this. Implementors tend to do the "right" thing wrt=20 > consistency when it matters, and the current language has caused=20 > confusion far beyond its worth. >=20 > - Jim >=20 > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, October 07, 2003 5:46 PM > > To: 'Webdav WG' > > Subject: WebDAV resources must be in collections? (CONSISTENCY) > >=20 > >=20 > >=20 > >=20 > > This is the CONSISTENCY issue in=20 > > http://www.webdav.org/wg/rfcdev/issues.htm. > >=20 > > RFC2518 says: > >=20 > > " An HTTP URL namespace is said to be consistent if it meets the > > following conditions: for every URL in the HTTP hierarchy there > > exists a collection that contains that URL as an internal member. > > The root, or top-level collection of the namespace under > > consideration is exempt from the previous rule." > >=20 > > Roy Fielding -=20 > > = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html: > >=20 > > "There is no need for that requirement and it > > is the root of many terminology issues. Any individual resource is > > capable of being or not being DAVable, as determined by either the > > capabilities described by an OPTIONS response" > >=20 > > I've been thinking of a use case for WebDAV resources that may not=20 > > be in WebDAV-capable collections. The SIMPLE WG has discussed=20 > > making Buddy lists be (in one model) a WebDAV resource. This would=20 > > mean that the buddy list could be locked, unlocked, could support > > PROPFIND and PROPPATCH, could support the basic WebDAV properties=20 > > to know when the content changed and what the ETag is. It could=20 > > have an owner and support the ACL method and the acl property. > >=20 > > Should we remove this consistency requirement from RFC2518bis? > >=20 > > Lisa > >=20 > >=20 >=20 From w3c-dist-auth-request@w3.org Wed Oct 8 12:27:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26200 for ; Wed, 8 Oct 2003 12:27:46 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F19BAA086F; Wed, 8 Oct 2003 12:27:53 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 096DBA06CE for ; Wed, 8 Oct 2003 12:27:52 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 44C1E13416; Wed, 8 Oct 2003 12:24:33 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 05ACE13337 for ; Wed, 8 Oct 2003 12:24:33 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1A7H72-0007bd-00; Wed, 08 Oct 2003 16:24:32 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1A7H71-0007bS-00; Wed, 08 Oct 2003 16:24:32 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Wed, 8 Oct 2003 09:24:45 -0700 Message-ID: <024a01c38db8$afec8c80$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/024a01c38db8$afec8c80$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7954 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008162753.F19BAA086F@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 12:27:53 -0400 (EDT) Content-Transfer-Encoding: 7bit > I agree that informative parts are usually in the appendix, > but that doesn't mean that any appendix is automatically > non-normative. > > > of section 12 could be normative in combination with the > XML extension > > rules *and* the specific element value rules, but the spec doesn't > > specifically say this. > > That's what we should fix. Got any suggestions? I'll try to come up with something here. > > What if we omitted the summary DTD in appendix 1 (23.1), > > and instead had only DTD fragments with each property? THen the > > reader of the spec would be more likley to read the whole > definition, > > rather than the shortcut of going to the appendix and only > seeing part > > of the whole picture. > > That sounds like a good idea. I'll do that, then. > > Another idea. As long as we're stating what ANY means, why limit > > ourslves. Eg. we could use pseudo-DTD syntax -- extending the > > definitions to say more of what we want them to say. We > could call it > > a WebDAV-DTD if it offends people to redefine XML DTD. > > > > E.g. > > owner?, timeout?, > > locktoken?, *) > > > > > > > > > > > I don't know how we'd go about formally extending DTDs to > do this or > > if that's important, but since the DTD in appendix 23.1 isn't > > normative presumably that would not be illegal. > > We could, but I'm not sure why we would want to do that. The > DTD fragments define allowable *syntax*. The allowable > content model for PROP *is* ANY. Sure, but you could also say the allowable content model for 'response' element is ANY. I will attempt to make this clearer with English alongside the regular DTD although I still think the spec could be clearer without something else formal or semi-formal that worked better for us than DTDs. lisa From w3c-dist-auth-request@w3.org Wed Oct 8 17:11:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09533 for ; Wed, 8 Oct 2003 17:11:59 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 8E2D4A073E; Wed, 8 Oct 2003 17:11:18 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E862CA0B45 for ; Wed, 8 Oct 2003 17:11:12 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 4136A139D2; Wed, 8 Oct 2003 17:10:32 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C40C113909 for ; Wed, 8 Oct 2003 17:10:31 -0400 (EDT) Received: (qmail 20755 invoked by uid 65534); 8 Oct 2003 21:10:31 -0000 Received: from pD950C3AD.dip.t-dialin.net (HELO lisa) (217.80.195.173) by mail.gmx.net (mp001) with SMTP; 08 Oct 2003 23:10:31 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Wed, 8 Oct 2003 23:10:28 +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: <024a01c38db8$afec8c80$f8cb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEBGIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7955 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008211118.8E2D4A073E@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 17:11:18 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 08, 2003 6:25 PM > To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > .. > > Sure, but you could also say the allowable content model for > 'response' element is ANY. I will attempt to make this clearer We could, but we shouldn't. The spec should use ANY if and only if it assigns a meaning to ANY type of content. This is the case for (what ever child element you find, it identifies a property) or . It is not the case for . > with English alongside the regular DTD although I still think > the spec could be clearer without something else formal or > semi-formal that worked better for us than DTDs. Options: 1) keep the DTDs as they are and clarify what they mean (that's what I've been trying to do), 2) extend the DTD syntax somehow, 3) switch to something that may allow to formally express what we need (as far as I understand, only Relax NG can do this). If there's interest in option 3), I can test that. However, I have my serious doubts that people are willing to learn yet another syntax just to fix a very minor issue with the DTD notation. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 8 17:39:07 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 RAA10533 for ; Wed, 8 Oct 2003 17:39:07 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F237DA0871; Wed, 8 Oct 2003 17:39:15 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DAA99A06B9 for ; Wed, 8 Oct 2003 17:39:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B519D1370D; Wed, 8 Oct 2003 17:39:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 8AAA813545 for ; Wed, 8 Oct 2003 17:39:13 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h98LdDGd739774 for ; Wed, 8 Oct 2003 17:39:13 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98LdA5V211990 for ; Wed, 8 Oct 2003 17:39:12 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 8 Oct 2003 17:39:10 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/08/2003 17:39:12, Serialize complete at 10/08/2003 17:39:12 Content-Type: text/plain; charset="US-ASCII" Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/OF242A86EF.3F0287A0-ON85256DB9.00764408-85256DB9.0076F19A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7956 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031008213915.F237DA0871@frink.w3.org> Resent-Date: Wed, 8 Oct 2003 17:39:15 -0400 (EDT) I guess I'd go with (1), with (3) as a backup choice. In particular, (2) is likely to cause more confusion than clarity. If you're going to do new things, I think it's better to select a standard new thing, rather than define a non-standard extension to a standard. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 10/08/2003 05:10:28 PM: > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, October 08, 2003 6:25 PM > > To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org > > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > > > .. > > > > Sure, but you could also say the allowable content model for > > 'response' element is ANY. I will attempt to make this clearer > > We could, but we shouldn't. The spec should use ANY if and only if it > assigns a meaning to ANY type of content. This is the case for (what > ever child element you find, it identifies a property) or . It > is not the case for . > > > with English alongside the regular DTD although I still think > > the spec could be clearer without something else formal or > > semi-formal that worked better for us than DTDs. > > Options: > > 1) keep the DTDs as they are and clarify what they mean (that's what I've > been trying to do), > > 2) extend the DTD syntax somehow, > > 3) switch to something that may allow to formally express what we need (as > far as I understand, only Relax NG can do this). > > If there's interest in option 3), I can test that. However, I have my > serious doubts that people are willing to learn yet another syntax just to > fix a very minor issue with the DTD notation. > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Oct 9 11:35: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 LAA24749 for ; Thu, 9 Oct 2003 11:35:15 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C44F7A0E8F; Thu, 9 Oct 2003 11:34:41 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 10DF4A0EAB for ; Thu, 9 Oct 2003 11:34:23 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3F39F14043; Thu, 9 Oct 2003 11:31:35 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id 7FC7A14038 for ; Thu, 9 Oct 2003 11:31:34 -0400 (EDT) Received: from lisa ([192.168.1.23]) (authenticated user jr@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 17-md50000000017.tmp for ; Thu, 09 Oct 2003 17:31:30 +0200 From: "Julian Reschke" To: Date: Thu, 9 Oct 2003 17:31: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 X-Authenticated-Sender: jr@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 09 Oct 2003 17:31:30 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDAIMAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7957 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009153441.C44F7A0E8F@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 11:34:41 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, rfc2518bis currently states: -- 12.1 Responses requiring Location in Multi-Status The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax does not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. -- There are two issues here that I'd like to be resolved both in rfc2518bis and draft-ietf-webdav-redirect-ref: 1) Are servers allowed not to report redirects as 3xx? I think I myself made the proposal to allow this because in practice returning 3xx responses in multistatus breaks a lot of clients (for instance, the Microsoft Webfolder client). However, if we allow this, there should be an explicit way for a client to force the server to return 3xx responses (that would then be defined in draft-ietf-webdav-redirect-ref). 2) I think we also should say that if a 3xx is returned, that the Location information must be returned as well. draft-ietf-webdav-redirect-ref uses a pseudo-property for that, but during Last Call in 2000 this was already discussed and it seems that there was a consensus to just extend the DAV:response element instead. So here's my proposal: a) Allow servers to report redirects with a 200 status. Thus will cause redirects to appear as regular resources, however an attempt to GET them will result in a HTTP redirect (which indeed will work fine with the MS webfolder client). b) In draft-ietf-webdav-redirect-ref, extend "Apply-To-Redirect-Ref" to have the values "T" or "F". In presence of this header, require the server not do to the 2xx workaround described in a). ("F" would mean that the server MUST NOT apply the request to the redirect target but also signals that the client knows about the various extensions in the redirect spec) c) In both RFC2518bis and draft-ietf-webdav-redirect-ref, define an extension element for DAV:response holding the Location header for the redirect, such as: (this takes care of the various issues inherent in "pseudo" properties). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 9 12:46: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 MAA28336 for ; Thu, 9 Oct 2003 12:46:35 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 61F38A0858; Thu, 9 Oct 2003 12:46:29 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B852AA0858 for ; Thu, 9 Oct 2003 12:46:27 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 8609413A59; Thu, 9 Oct 2003 12:46:27 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (Postfix) with ESMTP id 6AAF913971 for ; Thu, 9 Oct 2003 12:46:27 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h99GkQiu428640 for ; Thu, 9 Oct 2003 12:46:27 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h99GkPo1226832 for ; Thu, 9 Oct 2003 12:46:26 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 9 Oct 2003 12:46:27 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/09/2003 12:46:26, Serialize complete at 10/09/2003 12:46:26 Content-Type: text/plain; charset="US-ASCII" Subject: Re: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/OFF6CBD80B.D1C39432-ON85256DBA.005B87E5-85256DBA.005C252E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7958 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009164629.61F38A0858@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 12:46:29 -0400 (EDT) For (1), I could go either way on this, but if we did give a client a way to say this, I suggest that it be in the form of a request DAV header, and that we introduce a symbol that means "the redirect-ref standard", e.g. something like: DAV: 1, 2, redirect Note that I am bundling this into the general "I understand the redirect spec" token, since I'd rather not introduce a new token for each detailed bit of functionality. For (2), Julian's suggestion is fine, but shouldn't the Location node be optional (i.e. "Location?"). Cheers, Geoff Julian wrote on 10/09/2003 11:31:29 AM: > > Hi, > > rfc2518bis currently states: > > -- > 12.1 Responses requiring Location in Multi-Status > > The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take > a Location header to indicate where the client should make the > request. The Multi-Status response syntax does not allow for the > Location header information to be included in an unambiguous way, so > servers MAY choose not to use these status codes in Multi-Status > responses. If a clients receives this status code in Multi-Status, > the client MAY reissue the request to the individual resource, so > that the server can issue a response with a Location header for each > resource. > -- > > There are two issues here that I'd like to be resolved both in rfc2518bis > and draft-ietf-webdav-redirect-ref: > > 1) Are servers allowed not to report redirects as 3xx? I think I myself made > the proposal to allow this because in practice returning 3xx responses in > multistatus breaks a lot of clients (for instance, the Microsoft Webfolder > client). However, if we allow this, there should be an explicit way for a > client to force the server to return 3xx responses (that would then be > defined in draft-ietf-webdav-redirect-ref). > > 2) I think we also should say that if a 3xx is returned, that the Location > information must be returned as well. draft-ietf-webdav-redirect-ref uses a > pseudo-property for that, but during Last Call in 2000 this was already > discussed and it seems that there was a consensus to just extend the > DAV:response element instead. > > > So here's my proposal: > > a) Allow servers to report redirects with a 200 status. Thus will cause > redirects to appear as regular resources, however an attempt to GET them > will result in a HTTP redirect (which indeed will work fine with the MS > webfolder client). > > b) In draft-ietf-webdav-redirect-ref, extend "Apply-To-Redirect-Ref" to have > the values "T" or "F". In presence of this header, require the server not do > to the 2xx workaround described in a). ("F" would mean that the server MUST > NOT apply the request to the redirect target but also signals that the > client knows about the various extensions in the redirect spec) > > c) In both RFC2518bis and draft-ietf-webdav-redirect-ref, define an > extension element for DAV:response holding the Location header for the > redirect, such as: > > responsedescription?, location) > > > > (this takes care of the various issues inherent in "pseudo" properties). > > > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Oct 9 12:58: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 MAA29307 for ; Thu, 9 Oct 2003 12:58:42 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 890E2A076E; Thu, 9 Oct 2003 12:58:49 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7374FA076E for ; Thu, 9 Oct 2003 12:58:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 7D74813C6C; Thu, 9 Oct 2003 12:55:00 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 0DBED138FD for ; Thu, 9 Oct 2003 12:55:00 -0400 (EDT) Received: (qmail 27910 invoked by uid 65534); 9 Oct 2003 16:54:59 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015) with SMTP; 09 Oct 2003 18:54:59 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Thu, 9 Oct 2003 18:54:58 +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: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDFIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7959 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009165849.890E2A076E@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 12:58:49 -0400 (EDT) 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: Thursday, October 09, 2003 6:46 PM > To: w3c-dist-auth@w3.org > Subject: Re: 3xx vs RFC2518 vs redirect-ref spec > > > > For (1), I could go either way on this, but if we did give a client > a way to say this, I suggest that it be in the form of a request DAV > header, and that we introduce a symbol that means "the redirect-ref > standard", e.g. something like: > DAV: 1, 2, redirect Well, I'd rather not do that unless it's in the base spec (RFC2518bis). The redirect draft already defines a new header, so that one can easily be used.... > Note that I am bundling this into the general "I understand the > redirect spec" token, since I'd rather not introduce a new token for > each detailed bit of functionality. > > For (2), Julian's suggestion is fine, but shouldn't the Location > node be optional (i.e. "Location?"). Of course :-) Julian From w3c-dist-auth-request@w3.org Thu Oct 9 13:24: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 NAA00247 for ; Thu, 9 Oct 2003 13:24:30 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 85BC3A055E; Thu, 9 Oct 2003 13:24:13 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4E712A055E for ; Thu, 9 Oct 2003 13:24:12 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D192F135BD; Thu, 9 Oct 2003 13:24:11 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id 2392613574 for ; Thu, 9 Oct 2003 13:24:11 -0400 (EDT) Received: from lisa ([192.168.1.23]) (authenticated user jr@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 63-md50000000017.tmp for ; Thu, 09 Oct 2003 19:23:51 +0200 From: "Julian Reschke" To: Date: Thu, 9 Oct 2003 19:23:50 +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 X-Authenticated-Sender: jr@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 09 Oct 2003 19:23:51 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Updates in draft-ietf-webdav-redirectref-protocol-latest X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEDJIMAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7960 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009172413.85BC3A055E@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 13:24:13 -0400 (EDT) Content-Transfer-Encoding: 7bit Changes in: - Close (accept) issue "lc-79-accesscontrol". - Add issue "rfc2606-compliance". - Close issues "lc-50-blindredirect", "lc-71-relative", "lc-74-terminology". - Update contact info for Geoff Clemm. - Add and close issue "9-MKRESOURCE-vs-relative-URI". Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 9 13:56: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 NAA01547 for ; Thu, 9 Oct 2003 13:56:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id DCD93A0524; Thu, 9 Oct 2003 13:56:09 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A43EBA0524 for ; Thu, 9 Oct 2003 13:56:06 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 61EC5134B1; Thu, 9 Oct 2003 13:56:06 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id 470DD13434 for ; Thu, 9 Oct 2003 13:56:06 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id h99Hu5He426764 for ; Thu, 9 Oct 2003 13:56:05 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h99Hu4aT188798 for ; Thu, 9 Oct 2003 13:56:04 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 9 Oct 2003 13:56:04 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/09/2003 13:56:04, Serialize complete at 10/09/2003 13:56:04 Content-Type: text/plain; charset="US-ASCII" Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/OFCD7C10D9.C6333B96-ON85256DBA.00624057-85256DBA.006284F8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7961 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009175609.DCD93A0524@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 13:56:09 -0400 (EDT) My first choice is to get this in the base spec, since I think it is a bug that the server can register what options it supports, but a client cannot. I could live with Julian's approach, but I'd rather not, since I think this is a general problem that merits a clean extensible solution (as opposed to a one-off hack :-). Cheers, Geoff "Julian Reschke" wrote on 10/09/2003 12:54:58 PM: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > > Sent: Thursday, October 09, 2003 6:46 PM > > To: w3c-dist-auth@w3.org > > Subject: Re: 3xx vs RFC2518 vs redirect-ref spec > > > > > > > > For (1), I could go either way on this, but if we did give a client > > a way to say this, I suggest that it be in the form of a request DAV > > header, and that we introduce a symbol that means "the redirect-ref > > standard", e.g. something like: > > DAV: 1, 2, redirect > > Well, I'd rather not do that unless it's in the base spec (RFC2518bis). The > redirect draft already defines a new header, so that one can easily be > used.... > > > Note that I am bundling this into the general "I understand the > > redirect spec" token, since I'd rather not introduce a new token for > > each detailed bit of functionality. > > > > For (2), Julian's suggestion is fine, but shouldn't the Location > > node be optional (i.e. "Location?"). > > > Of course :-) > > Julian > From w3c-dist-auth-request@w3.org Thu Oct 9 14:01: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 OAA01742 for ; Thu, 9 Oct 2003 14:01:02 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A6A77A06DE; Thu, 9 Oct 2003 14:01:07 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2AD90A0937 for ; Thu, 9 Oct 2003 14:01:02 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5137A13800; Thu, 9 Oct 2003 14:00:09 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id DC2BB137F6 for ; Thu, 9 Oct 2003 14:00:08 -0400 (EDT) Received: (qmail 31109 invoked by uid 65534); 9 Oct 2003 18:00:08 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp002) with SMTP; 09 Oct 2003 20:00:08 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Thu, 9 Oct 2003 20:00: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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEDMIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7962 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009180107.A6A77A06DE@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 14:01:07 -0400 (EDT) Content-Transfer-Encoding: 7bit OK, so we probably should put it onto the issues list (so that it doesn't get lost). 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, October 09, 2003 7:56 PM > To: w3c-dist-auth@w3.org > Subject: RE: 3xx vs RFC2518 vs redirect-ref spec > > > > My first choice is to get this in the base spec, since I think it is > a bug that the server can register what options it supports, but a > client cannot. > > I could live with Julian's approach, but I'd rather not, since I think > this is a general problem that merits a clean extensible solution > (as opposed to a one-off hack :-). > > Cheers, > Geoff > > > "Julian Reschke" wrote on 10/09/2003 12:54:58 PM: > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm > > > Sent: Thursday, October 09, 2003 6:46 PM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: 3xx vs RFC2518 vs redirect-ref spec > > > > > > > > > > > > For (1), I could go either way on this, but if we did give a client > > > a way to say this, I suggest that it be in the form of a request DAV > > > header, and that we introduce a symbol that means "the redirect-ref > > > standard", e.g. something like: > > > DAV: 1, 2, redirect > > > > Well, I'd rather not do that unless it's in the base spec (RFC2518bis). > The > > redirect draft already defines a new header, so that one can easily be > > used.... > > > > > Note that I am bundling this into the general "I understand the > > > redirect spec" token, since I'd rather not introduce a new token for > > > each detailed bit of functionality. > > > > > > For (2), Julian's suggestion is fine, but shouldn't the Location > > > node be optional (i.e. "Location?"). > > > > > > Of course :-) > > > > Julian > > > From w3c-dist-auth-request@w3.org Thu Oct 9 15:47: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 PAA07224 for ; Thu, 9 Oct 2003 15:47:15 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 05AC7A0E04; Thu, 9 Oct 2003 15:47:21 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 90075A0E04 for ; Thu, 9 Oct 2003 15:47:19 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5ABD213701; Thu, 9 Oct 2003 15:47:19 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id 9E0A0136D4 for ; Thu, 9 Oct 2003 15:47:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07198; Thu, 9 Oct 2003 15:47:04 -0400 (EDT) Message-Id: <200310091947.PAA07198@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: Thu, 09 Oct 2003 15:47:04 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-12.txt X-Archived-At: http://www.w3.org/mid/200310091947.PAA07198@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7963 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009194721.05AC7A0E04@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 15:47:21 -0400 (EDT) --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-12.txt Pages : 59 Date : 2003-10-9 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-12.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-12.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-12.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-10-9142627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142627.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Oct 9 18:03: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 SAA12911 for ; Thu, 9 Oct 2003 18:03:49 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C7DBBA0F33; Thu, 9 Oct 2003 18:02:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id AEBDFA0F2D for ; Thu, 9 Oct 2003 18:02:15 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 60CBC13725; Thu, 9 Oct 2003 18:02:15 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail4.atl.registeredsite.com (mail4.atl.registeredsite.com [64.224.219.78]) by dr-nick.w3.org (Postfix) with ESMTP id 4084013376 for ; Thu, 9 Oct 2003 18:02:15 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail4.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h99M1RUG015380; Thu, 9 Oct 2003 18:01:27 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id PAA19698; Thu, 9 Oct 2003 15:00:56 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Thu, 9 Oct 2003 15:00:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <011d01c38d03$a6ecf030$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAGEBJDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7964 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031009220217.C7DBBA0F33@frink.w3.org> Resent-Date: Thu, 9 Oct 2003 18:02:17 -0400 (EDT) Content-Transfer-Encoding: quoted-printable I looked at where this current conversation was going and I thought it = best to respond here, where it seems to have started. I am arriving in = the middle of a long-running discussion of DTDs, but I thought these = observations might help to calibrate the discussion. (I finally took a = course on XML and Web Services and used the occasion to dig into the = specifications more than I had up until now.) 1. ARRANGING FOR DTD VALIDITY OF A WebDAV XML 1.0 "document"=20 The key thing to keep in mind is that=20 If you intend for a WebDAV "document" to be an XML 1.0 document that is = [DTD] valid, (a) the ANY case in an element markup declaration means any element = that is declared in the DTD, not some undeclared or unspecified element. (b) Elements having no markup declaration in the DTD are not permitted = in [DTD] valid XML 1.0 documents. (This is specific technical language = around what it means for an XML 1.0 document to be valid as opposed to = simply well-formed.) 2. What that might mean, generally, is that the best external DTD that = can be created for WebDAV is one that is a skeleton that must be = supplemented by additional markup declarations (perhaps in an internal = DTD subset) to account for any extensions. If no extensions are used = (e.g., no elements and attributes from any other namespace), the = external DTD will work fine by itself.=20 3. When it gets too difficult to handle that, or there is too much = variability to deal with, I recommend simply not providing a Document = Type Declaration (the structure) and fall back to the = WebDAV XML being merely well-formed (and conforming to the WebDAV rules = but without asserting [DTD] validity). =20 4. NAMESPACES I notice that "DAV:" is referred to as the namespace, when, according to = the Namespace specification and other specifications since (such as XML = Schema), it is technically a prefix. That is, attribute xmlns:DAV=3D"some-URI-for-the-WebDAV-namespace" establishes the "DAV:" prefix for QNames that refer to local names of = the WebDAV namespace. It is possible to deal with this (a namespace known in advance) and not = even require that the prefix be "dav:" in creation of a WebDAV DTD. = This is done, for example, in the DTD that exists for XML Schema = documents. The XML Schema DTD can be used to validate schema documents = and provides a way to select alternatives to the exemplar namespace = prefixes "xs": and "xsi:". This is done in a way that requires no = modification to the DTD. 5. RUNNING OUT OF GAS If a DTD is used for validation of a document, the DTD must account for = all of the QNames that can be used for elements and attributes. That = includes all of the namespace declarations and the prefixes that they = will declare. (xmlns:prefix attributes are often declared to be #FIXED = and the namespace URI is then regulated too.) Because of the requirement to rigidly and completely define a document's = structural vocabulary, even with the promiscuous allowance of ANY = elements, there are times when it doesn't work to have a DTD. One = certainly can't be required if there is meant to be tolerance for = arbitrary addition of attributes and elements in any document instance. = The ideas of a fixed, known-in-advance DTD and arbitrary additions of = elements and attributes to documents are incompatible. The alternative, = as in the case of RDF, is just too difficult because there basically has = to be a custom DTD per RDF document instance, and they have to be = maintained together as new versions of the document are created. (I've = actually done that but only for simple cases.) I find DTDs very useful and often create one simply as a design device = when building XML documents. It is very helpful to have the support of = my validating XML editor to let me know when I have something to clean = up. I've even found it useful to use DTDs and XML Schema together. =20 Does this shed any light or have I just muddied a situation that you = have already struggled through many times? Regards, -- Dennis Dennis E. Hamilton ------------------ AIIM DMware Technical Coordinator mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 http://DMware.info ODMA Support: http://ODMA.info OpenPGP public key fingerprint BFE5 EFB8 CB51 8781 5274 C056 D80D 0C3F = A393 27EC -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Tuesday, October 07, 2003 11:49 To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org Subject: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > What if we ditched the DTD entirely and simply use English? >=20 > I'd prefer to keep them and continue to use them the same way=20 > as currently done in RFC2518, RFC3253 and the various drafts=20 > closing completion. Does that mean we go back to what was in RFC2518 before the 'bis' changes started? Then we've failed to address the issue where we had interoperability problems because implementations did not allow extension elements in places where the spec ought to allow them. =20 I know this is a failure of the implementors to follow the text=20 in the spec to its logical conclusion, but as we've seen a clear spec is crucial to easing the way to interoperability. I can't tell what the consensus is here. I thought originally there was a consensus to clarify which elements could be extended and in what way. I attempted to do this by altering the DTD,=20 and I also proposed doing this by replacing DTDs with English. The third option is to go back to RFC2518 DTDs and ignore the=20 problem. I haven't seen a fourth concrete option. > All that's needed is the following general clarification: >=20 > "This document uses XML DTD fragments as a purely notational=20 > convention. WebDAV request and response bodies can not be=20 > validated due to the specific extensibility rules defined in=20 > section 23 of [RFC2518] and due to the fact that all XML=20 > elements defined by this specification use the XML namespace=20 > name "DAV:". In particular: >=20 > - element names use the "DAV:" namespace, > - element ordering is irrelevant, > - extension elements (elements not already defined as valid=20 > child elements) may be added anywhere, except when explicitly=20 > stated otherwise, > - extension attributes (attributes not already defined as=20 > valid for this > element) may be added anywhere, except when explicitly stated=20 > otherwise." This doesn't seem sufficient to me unless we simply decide not to address the problem. RFC2518 already had general language of this sort to say that generally extensibility should be allowed. To solve the problem, we need to specify for every element how it may be extended, and what it means to extend it. Or we can=20 decide not to solve the problem. > > This would tend to drive us, the spec writers, to include more=20 > > information, more > > guidance, rather than less. That's because the DTDs don't provide = an easy > > place to say whether an element may be extended with new > > elements, or under > > what conditions an element is required. > If this is the main issue, clarifying that an "ANY" content model=20 > indicates that the element is *not* extensible (contrary to the=20 > default case) may suffice (note that this would apply to the=20 > content of the DAV:prop element in PROPFIND marshalling). This seems opposite to what I'd expect "ANY" would mean. The prop element is the *most* extensible because all implementations know you can put any element child in here, as long as it is a property name. Lisa From w3c-dist-auth-request@w3.org Fri Oct 10 05:44: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 FAA15569 for ; Fri, 10 Oct 2003 05:44:31 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4B47CA053A; Fri, 10 Oct 2003 05:44:14 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5F9B5A055E for ; Fri, 10 Oct 2003 05:44:10 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3150713462; Fri, 10 Oct 2003 05:44:10 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id B7BA4133A1 for ; Fri, 10 Oct 2003 05:44:09 -0400 (EDT) Received: (qmail 6616 invoked by uid 65534); 10 Oct 2003 09:44:08 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003) with SMTP; 10 Oct 2003 11:44:08 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Lisa Dusseault" , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Fri, 10 Oct 2003 11:44:07 +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: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEFCIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7965 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031010094414.4B47CA053A@frink.w3.org> Resent-Date: Fri, 10 Oct 2003 05:44:14 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 10, 2003 12:01 AM > To: Lisa Dusseault; 'Julian Reschke'; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) Hi Dennis, just a few line-comments. > ... > (a) the ANY case in an element markup declaration means any > element that is declared in the DTD, not some undeclared or > unspecified element. > ... Thanks for the reminder. I had forgotten about that. It basically means that by definition you can't express the content model of using a DTD. > ... > I notice that "DAV:" is referred to as the namespace, when, > according to the Namespace specification and other specifications > since (such as XML Schema), it is technically a prefix. That is, > attribute > > xmlns:DAV="some-URI-for-the-WebDAV-namespace" > > establishes the "DAV:" prefix for QNames that refer to local > names of the WebDAV namespace. > ... No, no. "DAV:" is indeed the namespace URI for WebDAV. There are some cases where it's *also* used as prefix, but that's just a coincidence. > ... Regards, Julian From w3c-dist-auth-request@w3.org Fri Oct 10 16:45: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 QAA22168 for ; Fri, 10 Oct 2003 16:45:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D484AA0676; Fri, 10 Oct 2003 16:45:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5C600A06BA for ; Fri, 10 Oct 2003 16:45:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 24EFD136DE; Fri, 10 Oct 2003 16:45:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail2.atl.registeredsite.com (mail2.atl.registeredsite.com [64.224.219.76]) by dr-nick.w3.org (Postfix) with ESMTP id F03881368F for ; Fri, 10 Oct 2003 16:45:48 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail2.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9AKjNWI017017; Fri, 10 Oct 2003 16:45:23 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id NAA15055; Fri, 10 Oct 2003 13:45:15 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , "Lisa Dusseault" , "'Geoffrey M Clemm'" , Date: Fri, 10 Oct 2003 13:45:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAGECLDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7966 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031010204550.D484AA0676@frink.w3.org> Resent-Date: Fri, 10 Oct 2003 16:45:50 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Ah well, I have learned just enough to be dangerous. Julian, thanks for the response. =20 I have continued to look at this since I wrote yesterday's note. Here = are responses to your points, followed by a brain dump about = reconciliation of DAV and XML: 1. Yes, I forgot that DAV: is also the URI that is spoken of as the "DAV = namespace."=20 1.1 I find it better to refer to the "DAV namespace" or "DAV namespace = URI" rather than the "DAV: namespace" especially because namespaces are = often versioned (rather than revised [;<), so the identification in XML = will be with different URIs over time. Ditto for the lock-token = namespace. 1.2 In the context of this discussion, the DAV namespace is not a = barrier to having a DTD. It is prefixes (that is QNames) that must be = dealt with carefully when a DTD is used. However, this is completely = possible, as the XML Schema folk demonstrated. 2. You have your finger on a critical and important point. =20 2.1 It is not possible to create a generic DTD that can be used for = validation of any DAV XML 1.0 "document". That's specifically because = of the RDF hack and the ability to ad lib property QNames. (I call = anything where there is an application technique that maps QNames to = URIs as the RDF hack, since RDF seems to have been the first to do it. = This creates a variety of problems, some of which are noted in a recent = review of the latest RDF working documents. See = . I don't want to go deeper into this, though it has become an = interoperability concern because of a problem concerning when the = special application knowledge has to be applied to handle an RDF (or any = RDF hack) correctly. [Aside: There is now an approach to (lexical) = datatypes in the latest RDF working documents that could well be adapted = to DAV property values at some point.] 2.2 It is possible to create a DTD for some specific (family of) DAV XML = 1.0 "document". It might be a loose DTD, in that there are more XML 1.0 = documents that satisfy it than are acceptable as DAV XML "documents." =20 2.3 It might not be possible to express the content model of = for other reasons, at least as an accurately-constrained grammar. XML = is rather limited in the power of language that can be defined by markup = declarations. Although it looks equivalent to BNF, it isn't. There are = further constraints that limit XML markup vocabularies to ones that can = always be handled by greedy, non-backtracking parsers. The limitations = on mixed content models reflect these required simplifications. = Nevertheless, (2.1) is compelling in the case of DAV application of XML = 1.0. 2.4 It is important to keep case (2.1) and case (2.2) distinct. With = regard to wanting valid XML documents, if that is indeed the desire, = there is a broader question. Namely, 3. What's a DAV XML 1.0 "document"? 3.1 I have been using quotes because there is the notion of an XML 1.0 = document, and then there are notions of applications where XML, = including XML documents, may occur. =20 3.2 What I don't find in WebDAV (I haven't looked at 2518bis) is any = clear specification of the relationship of DAV request bodies, DAV = response bodies, and, for that matter, DAV documents-as-content, as an = application of XML 1.0. 3.3 In the examples in the DAV specification, an XML declaration () is always present. Although not required by the = XML 1.0 Specification, this is tantamount to a declaration that an XML = 1.0 document is present (or something equivalent to an XML external = entity). This is a strong statement with regard to what one can count = on: 3.3.1 The only entity declarations that may be presumed by default=20 3.3.2 The well-formedness condition (and existence of a single, though = un-named, root element) 3.3.3 The reservation of attributes and elements with names of the form = xml... (including all capitalizations) as exclusively defined by the XML = specification or other approved specifications by the XML authority = (whoever that might be) -- that is, use of xmlns in all of its variants, = use of xml:lang, xml:base the one for whitespace control, etc. 3.3.4 The definition of what a Document Type Declaration (the structure) is and the rules for markup declarations (for element = types, attribute types, entity references, ...). 3.4 An example of (3.2) is the fact that it is not clear that the XML = declaration is required for DAV XML documents and whether a Document = Type Declaration is forbidden (as it is for SOAP, if I recall = correctly). I can't find where the DAV specification settles the = matter, so I don't know if a DAV processor is expected to deal with it = if it is there, and whether or not validation is expected or not. 3.5 Because DAV XML 1.0 documents are for an application of XML, and DAV = processors are expected to deal with some specific things (such as the = DAV version of the RDF hack), there are further considerations. 3.5.1 These are out-of-band agreements that are not part of XML 1.0 = compliance but that impact how the DAV use of XML is to be interpreted. = An important consideration is whether the application is presumed to = follow the basic XML processing. That is, the application could be = viewed as fed by an XML processor that is designed to operate in an = application-ignorant manner. =20 3.5.2 There is some application context of a transport nature that = applies even to the XML 1.0 embedding in HTTP header and response = bodies. This is a problem that SOAP has addressed (I am not sure "dealt = with" holds, though) and the SOAP HTTP binding and the WS-I Base Profile = 1.0a are worthy of review with regard to coherence between HTTP, MIME = types, and DAV XML 1.0 bodies. (I keep thinking there is a mistake in = the WS-I conclusion about byte-order marks, but it is more valuable to = have a standard that can be consistently followed than be right about = that. There is a miss-reading of the XML 1.0 specification about this, = and it has been perpetuated in the folklore around SOAP.) =20 3.5.3 Side Note: There is no prohibition on unusual encodings for XML = documents. The DAV specification goes too far in presuming there is a = limitation. There is a requirement that a processor always support = utf-8 and utf-16. In the absence of an encoding declaration [in the XML = declaration or from context] it must be one or the other. Note that the = default encoding for MIME content type text/xml is ASCII. Note further = that encoding=3D"ASCII" does not entail encoding=3D"utf-8". And all of = the DAV specification examples do match up encodings properly. = Whatever the encoding methodology, XML 1.0 documents are always taken to = be expressed in Unicode: That is, the abstraction of the character = stream out of the medium is always Unicode. This means that encoding = characters that have no counterpart in (the XML-specified subset of) = Unicode may not be used. This is important with regard to XML 1.0 = processors which should probably only see Unicode, on the way in and on = the way out. It would seem that there is a minimum subset of Unicode = that any encoding must have corresponding character codes for in order = to carry arbitrary XML 1.0 documents at all. 3.5.4 Because DAV XML 1.0 is an application of XML, it is wise to = consider that all XML well-formedness and any DTD validation (if = invited) or non-validation (even with a Document Type Declaration = present) rules will have been carried out first, before the XML stream = is delivered for further application employment (e.g, via a validating = DOM processor). And there may be a desire to carry DAV XML 1.0 in some = neutral way as pure XML 1.0 documents. So there is need for care here. 3.5.5 I am unclear on its status, but there is a proposal (at least an = I-D) to use MIME-type designations like application/xml+DAV as a way to = signify that there is an application-processing agreement applicable to = the XML being carried in the medium. This, by the way, would be useful = as a type for DAV XML 1.0 documents as content, as well as an useful = signal in content-type headers. (Something for the DAV job jar.) 3.6 Coming back to the specific case of DTD,=20 3.6.1 It might be more appropriate to specifically reject the use of = Document Type Declarations in DAV XML 1.0 documents that are used in = HTTP bodies and headers and certainly for a MIME type that asserts DAV = application. =20 3.6.2 This deals with section 17.7 of the specification too, because = there are therefore no external entities and a DAV processor does not = have to accommodate such things (or any internal entities other than the = standard default ones, & <, ..., plus the encoding notation for = Unicode characters). [You might want to review the XML 1.1 Working = Draft in this regard too, just to see if there is anything to anticipate = here.] 3.6.3 Although a Document Type Declaration might be prohibited, it is = still possible to describe what the validity is expected to be if a DAV = XML 1.0 document were submitted to an XML validator with a DTD = constructed according to some prescribed scheme. There is a hack for = this by treating the DAV XML 1.0 document, separated out into a file = with its XML declaration, as an external entity of a tiny document that = validates the DAV XML 1.0 document by inclusion. I have used that to = apply different XSL transformations to the same XML document without = modifying the XML document to add XSL processing instructions. I know I saw this trick demonstrated in a W3C document, but I have been = unsuccessful finding it again. (I remember the trick, just not the = source.) OK, end of brain dump. Relax. My next class starts on October 16 and I will quiet down for = another 8 weeks ... -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, October 10, 2003 02:44 To: dennis.hamilton@acm.org; Lisa Dusseault; 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 10, 2003 12:01 AM > To: Lisa Dusseault; 'Julian Reschke'; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and = lockdiscovery) Hi Dennis, just a few line-comments. > ... > (a) the ANY case in an element markup declaration means any > element that is declared in the DTD, not some undeclared or > unspecified element. > ... Thanks for the reminder. I had forgotten about that. It basically means = that by definition you can't express the content model of using a DTD. > ... > I notice that "DAV:" is referred to as the namespace, when, > according to the Namespace specification and other specifications > since (such as XML Schema), it is technically a prefix. That is, > attribute > > xmlns:DAV=3D"some-URI-for-the-WebDAV-namespace" > > establishes the "DAV:" prefix for QNames that refer to local > names of the WebDAV namespace. > ... No, no. "DAV:" is indeed the namespace URI for WebDAV. There are some = cases where it's *also* used as prefix, but that's just a coincidence. > ... Regards, Julian From w3c-dist-auth-request@w3.org Sat Oct 11 07:04: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 HAA29095 for ; Sat, 11 Oct 2003 07:04:12 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 81277A05E4; Sat, 11 Oct 2003 07:04:20 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0A3D4A05E4 for ; Sat, 11 Oct 2003 07:04:19 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id AC97D14B1C; Sat, 11 Oct 2003 07:04:18 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 1285814AFB for ; Sat, 11 Oct 2003 07:04:18 -0400 (EDT) Received: (qmail 19416 invoked by uid 65534); 11 Oct 2003 11:04:06 -0000 Received: from p3EE2470D.dip.t-dialin.net (HELO lisa) (62.226.71.13) by mail.gmx.net (mp022) with SMTP; 11 Oct 2003 13:04:06 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , Date: Sat, 11 Oct 2003 13:04:03 +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: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEILIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7967 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031011110420.81277A05E4@frink.w3.org> Resent-Date: Sat, 11 Oct 2003 07:04:20 -0400 (EDT) Content-Transfer-Encoding: 7bit Comments inline... > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 10, 2003 10:45 PM > To: Julian Reschke; Lisa Dusseault; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > .. > > 1.1 I find it better to refer to the "DAV namespace" or "DAV > namespace URI" rather than the "DAV: namespace" especially > because namespaces are often versioned (rather than revised [;<), > so the identification in XML will be with different URIs over > time. Ditto for the lock-token namespace. > .. Well. There are no plans to change the namespace URI for DAV:. Doing that would be an incompatible change breaking all existing code (see for instance how XSLT deals with versioning). > 1.2 In the context of this discussion, the DAV namespace is not > a barrier to having a DTD. It is prefixes (that is QNames) that > must be dealt with carefully when a DTD is used. However, this > is completely possible, as the XML Schema folk demonstrated. Is it worth the effort? Can you supply (a link to) an example? > 2. You have your finger on a critical and important point. > > 2.1 It is not possible to create a generic DTD that can be used > for validation of any DAV XML 1.0 "document". That's > specifically because of the RDF hack and the ability to ad lib > property QNames. (I call anything where there is an application > technique that maps QNames to URIs as the RDF hack, since RDF > seems to have been the first to do it. This creates a variety of > problems, some of which are noted in a recent review of the > latest RDF working documents. See > 017.html>. I don't want to go deeper into this, though it has > become an interoperability concern because of a problem > concerning when the special application knowledge has to be > applied to handle an RDF (or any RDF hack) correctly. [Aside: > There is now an approach to (lexical) datatypes in the latest RDF > working documents that could well be adapted to DAV property > values at some point.] I'm not sure where the hack is. In WebDAV, property names are identified by namespaced XML names (as a pair of namespace URI and local name), not as URI. > ... > > 3.2 What I don't find in WebDAV (I haven't looked at 2518bis) > is any clear specification of the relationship of DAV request > bodies, DAV response bodies, and, for that matter, DAV > documents-as-content, as an application of XML 1.0. Some WebDAV methods use XML documents as request/response bodies. There is no notion of DAV-documents-as-content. That's it. > 3.3 In the examples in the DAV specification, an XML > declaration () is always present. > Although not required by the XML 1.0 Specification, this is > tantamount to a declaration that an XML 1.0 document is present > (or something equivalent to an XML external entity). This is a > strong statement with regard to what one can count on: Actually the content types we use indicate that as well, therefore the XML declaration is not necessary. However there are clients/servers that fail (or did fail) in absence of the XML declaration. > ... > > 3.4 An example of (3.2) is the fact that it is not clear that > the XML declaration is required for DAV XML documents and whether As the spec doesn't say that it is required, it isn't. > a Document Type Declaration is forbidden (as it is for SOAP, if I > recall correctly). I can't find where the DAV specification As the spec doesn't say it's forbidden, it's allowed. Hoewever it does say that servers/clients must not attempt to validate the documents. > ... > > 3.5.1 These are out-of-band agreements that are not part of > XML 1.0 compliance but that impact how the DAV use of XML is to > be interpreted. An important consideration is whether the > application is presumed to follow the basic XML processing. That > is, the application could be viewed as fed by an XML processor > that is designed to operate in an application-ignorant manner. Of course. Section 8 states: "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]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response then it MUST NOT assume anything about the outcome of the executed method and SHOULD treat the server as malfunctioning." > 3.5.2 There is some application context of a transport > nature that applies even to the XML 1.0 embedding in HTTP header > and response bodies. This is a problem that SOAP has addressed > (I am not sure "dealt with" holds, though) and the SOAP HTTP > binding and the WS-I Base Profile 1.0a are worthy of review with > regard to coherence between HTTP, MIME types, and DAV XML 1.0 > bodies. (I keep thinking there is a mistake in the WS-I > conclusion about byte-order marks, but it is more valuable to > have a standard that can be consistently followed than be right > about that. There is a miss-reading of the XML 1.0 specification > about this, and it has been perpetuated in the folklore around SOAP.) I'm not sure to what you're referring here... > 3.5.3 Side Note: There is no prohibition on unusual > encodings for XML documents. The DAV specification goes too far > in presuming there is a limitation. There is a requirement that Where...? > a processor always support utf-8 and utf-16. In the absence of > an encoding declaration [in the XML declaration or from context] > it must be one or the other. Note that the default encoding for > MIME content type text/xml is ASCII. Note further that > encoding="ASCII" does not entail encoding="utf-8". And all of > the DAV specification examples do match up encodings properly. > Whatever the encoding methodology, XML 1.0 documents are always > taken to be expressed in Unicode: That is, the abstraction of > the character stream out of the medium is always Unicode. This > means that encoding characters that have no counterpart in (the > XML-specified subset of) Unicode may not be used. This is ...such as control characters other then CR, LF and TAB... > important with regard to XML 1.0 processors which should probably > only see Unicode, on the way in and on the way out. It would > seem that there is a minimum subset of Unicode that any encoding > must have corresponding character codes for in order to carry > arbitrary XML 1.0 documents at all. An encoding that can carry arbitrary XML documents must support all Unicode characters allowed in XML names (as those can't be escaped). > 3.5.4 Because DAV XML 1.0 is an application of XML, it is > wise to consider that all XML well-formedness and any DTD > validation (if invited) or non-validation (even with a Document > Type Declaration present) rules will have been carried out first, > before the XML stream is delivered for further application > employment (e.g, via a validating DOM processor). And there may A processor is allowed to deliver data to the application before it has finished checking wellformed-ness. Otherwise XML processors could not be used in streaming contexts. However, if a wf-error is detected, it must be signalled and the application must abort processing. > be a desire to carry DAV XML 1.0 in some neutral way as pure XML > 1.0 documents. So there is need for care here. > > ... > > 3.6 Coming back to the specific case of DTD, > > 3.6.1 It might be more appropriate to specifically reject > the use of Document Type Declarations in DAV XML 1.0 documents > that are used in HTTP bodies and headers and certainly for a MIME > type that asserts DAV application. Why does it matter? The spec says that they must be ignored, and in real life I haver never seen a client or server sending a DOCTYPE. I don't think there's an issue here. > 3.6.2 This deals with section 17.7 of the specification > too, because there are therefore no external entities and a DAV > processor does not have to accommodate such things (or any > internal entities other than the standard default ones, & > <, ..., plus the encoding notation for Unicode characters). > [You might want to review the XML 1.1 Working Draft in this > regard too, just to see if there is anything to anticipate here.] --> > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Oct 11 17:30: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 RAA13388 for ; Sat, 11 Oct 2003 17:30:55 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 23791A06A5; Sat, 11 Oct 2003 17:31:04 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E097FA06A5 for ; Sat, 11 Oct 2003 17:31:01 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C6AA313905; Sat, 11 Oct 2003 17:31:01 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail8.atl.registeredsite.com (mail8.atl.registeredsite.com [64.224.219.82]) by dr-nick.w3.org (Postfix) with ESMTP id A70CE13805 for ; Sat, 11 Oct 2003 17:31:01 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail8.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9BLUwPi013806; Sat, 11 Oct 2003 17:30:58 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id OAA25921; Sat, 11 Oct 2003 14:30:57 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Sat, 11 Oct 2003 14:30:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Ignoring Versus Not Validating X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEDKDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7968 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031011213104.23791A06A5@frink.w3.org> Resent-Date: Sat, 11 Oct 2003 17:31:04 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Hi Julian, I am responding to your last comment first, since I think this is an = issue to have be clear right away. This is one of the places where I = see missing precision in definition of the DAV reliance on XML 1.0: 1. Accepting that the WebDAV specification says that WebDAV XML is not = to be validated, that is not the same as saying that any = Document Type Declaration can be ignored.=20 2. XML 1.0 gives specific instructions about what must be done with a = Document Type Declaration even for a non-validating processor. The key = statement is in XML 1.0 Recommendation section 5.1, Validating and = Non-Validating Processors . =20 3. The use of Document Type Declarations in non-validating situations is = illustrated in the RDF Primer. See = and the = discussion immediately preceding the example. The official (candidate) = RDF Schema for OWL uses this very technique = ().=20 (These illustrate the RDF hack, by the way. In some parts of RDF, = (adlib) QNames *are* mapped to URIs by concatenation of the namespace = URI that the prefix stands for, plus the local-name part, into a new = URI. The is used to set up entity declarations that are = used in xmlns:... attributes and in directly writing the URI form in = literals and attribute values.) 4. Rather than have so much sensitivity to out-of-band nuances, I think = it would be cleaner and more interoperable (for DAV, not arbitrary XML) = to have the DAV application of XML 1.0 specify that a Document Type = Declaration must not be present. Then (1) the XML can't be presumed to = be validatable, and (2) there is no confusion about the validating = versus non-validating use as there is when one is provided. Since, as you say, it doesn't seem to be used, it might be a good idea = to simplify here and say that it is not meant to be. I don't have any skin in this particular game. I just think it is a = good idea, especially since there doesn't seem to be any demonstration = of interoperability with Document Type Declarations present. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, October 11, 2003 04:04 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) Comments inline... [ ... ] > > 3.4 An example of (3.2) is the fact that it is not clear that > the XML declaration is required for DAV XML documents and whether As the spec doesn't say that it is required, it isn't. > a Document Type Declaration is forbidden (as it is for SOAP, if I > recall correctly). I can't find where the DAV specification As the spec doesn't say it's forbidden, it's allowed. Hoewever it does = say that servers/clients must not attempt to validate the documents. [ ... ] > > 3.6 Coming back to the specific case of DTD, > > 3.6.1 It might be more appropriate to specifically reject > the use of Document Type Declarations in DAV XML 1.0 documents > that are used in HTTP bodies and headers and certainly for a MIME > type that asserts DAV application. Why does it matter? The spec says that they must be ignored, and in real life I haver never seen a client or server sending a DOCTYPE. I don't = think there's an issue here. > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Oct 12 02:21:06 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 CAA09295 for ; Sun, 12 Oct 2003 02:21:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 37FFDA0888; Sun, 12 Oct 2003 02:21:10 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 825F5A0A7F for ; Sun, 12 Oct 2003 02:20:55 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 1AB4914579; Sun, 12 Oct 2003 02:19:19 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail9.atl.registeredsite.com (mail9.atl.registeredsite.com [64.224.219.83]) by dr-nick.w3.org (Postfix) with ESMTP id CEC5313CD6 for ; Sun, 12 Oct 2003 02:19:15 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail9.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9C6JEbA012351; Sun, 12 Oct 2003 02:19:14 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id XAA23301; Sat, 11 Oct 2003 23:19:13 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Sat, 11 Oct 2003 23:19:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAOEDODDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7969 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031012062110.37FFDA0888@frink.w3.org> Resent-Date: Sun, 12 Oct 2003 02:21:10 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Gee, Namespaces are versioned all of the time without breaking any = existing code. I didn't mean to suggest obsolescing anything, only that = it is useful to speak in a way where a new URI might be usable for a = *later* namespace. The existing namespace URI would still work, and = refer to the current namespace. A future namespace might have the = current one as a proper subset and that would work too, even though = there is a different URI for it. I realize that there are DAV headers for this, as part of feature = coordination and leveling, It is often handy to also rev the namespace = for anything specific to the use of XML. For example, with the SOAP XML = binding to HTTP, a closer analog to WebDAV, I would think, the SOAP 1.2 = Recommendation establishes a different namespace than is used for the = SOAP 1.1 level, and the SOAP 1.2 specification deals with how to deal = properly with SOAP 1.1 as a legacy. This supports the versioning of XML = Schema definitions too, since XML Schema definitions tend to be targeted = to specific namespaces. So I wasn't anticipating any kind of versioning of namespace URIs that = would break compatibility with or even usage of the current = specification. I see it as keeping a namespace stable and known, = whether or not it is a proper subset of a future one. Namespace versions will already have to be dealt with when properties, = for example, are taken from other XML-mapped vocabularies, such as = Dublin Core, which has a specific namespace for its current 1.1 level of = element definitions. Something like that will doubtless happen with = RDF, if it isn't underway already in Friday's Last-Call Working Draft = documents. Having said that, I am not wedded to the idea. I was just suggesting a = way of speaking that would allow for specific-namespace versioning with = minimal editorial impact in future revisions of the DAV specification. = I assume that 2518bis is far enough along that one would not want to = mess with it. In any case, it is an editorial nuance, nothing = substantive. I do think of namespace versioning as a key provision for preservation = of interoperability over time, like versioning COM interfaces (and their = UUIDs), and never changing them. Or providing for versioning in Java = package names. Or even like W3C specification URLs where you can refer = to a specific edition or simply the current latest of the progression. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, October 11, 2003 04:04 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) Comments inline... > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 10, 2003 10:45 PM > To: Julian Reschke; Lisa Dusseault; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and = lockdiscovery) > > .. > > 1.1 I find it better to refer to the "DAV namespace" or "DAV > namespace URI" rather than the "DAV: namespace" especially > because namespaces are often versioned (rather than revised [;<), > so the identification in XML will be with different URIs over > time. Ditto for the lock-token namespace. > .. Well. There are no plans to change the namespace URI for DAV:. Doing = that would be an incompatible change breaking all existing code (see for = instance how XSLT deals with versioning). [ ... ] From w3c-dist-auth-request@w3.org Sun Oct 12 09:34: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 JAA17350 for ; Sun, 12 Oct 2003 09:34:13 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CB4B5A0A18; Sun, 12 Oct 2003 09:34:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 163A0A0A2C for ; Sun, 12 Oct 2003 09:34:09 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 74DCF13A3D; Sun, 12 Oct 2003 09:30:14 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id 44757139F7 for ; Sun, 12 Oct 2003 09:30:14 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9CDUDGd696832 for ; Sun, 12 Oct 2003 09:30:13 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9CDUCa6108132 for ; Sun, 12 Oct 2003 09:30:12 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 12 Oct 2003 09:30:05 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/12/2003 09:30:12, Serialize complete at 10/12/2003 09:30:12 Content-Type: multipart/alternative; boundary="=_alternative 004A1EB185256DBD_=" Subject: Re: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/OFB05ED238.9C70037D-ON85256DBD.004926AF-85256DBD.004A2A40@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7970 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031012133417.CB4B5A0A18@frink.w3.org> Resent-Date: Sun, 12 Oct 2003 09:34:17 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 004A1EB185256DBD_= Content-Type: text/plain; charset="US-ASCII" By "breaking all existing code", I believe Julian was referring to the result that no client that only understands V1 of the namespace can work against a server that only understands V2 of the namespace, and vica versa. This means that each time you rev the namespace, you introduce an interoperability nightmare for both clients and servers, because inevitably, new clients and servers will be written that only understand the "current" version of the namespace, which means that client and server implementors that care about interoperability will have to implement variant code for every new rev of the namespace. A significant percentage (possibly even a majority) of the hard design work of WebDAV and its extensions has been how to add in functionality in a way that is compatible with the previous standards. So I agree with Julian that the DAV namespace should never be "rev"ed, but rather every new WebDAV protocol has to figure out how to live within the single existing DAV namespace. Cheers, Geoff Dennis wrote on 10/12/2003 02:19:08 AM: > > Gee, Namespaces are versioned all of the time without breaking any > existing code. I didn't mean to suggest obsolescing anything, only > that it is useful to speak in a way where a new URI might be usable > for a *later* namespace. The existing namespace URI would still > work, and refer to the current namespace. A future namespace might > have the current one as a proper subset and that would work too, > even though there is a different URI for it. > > I realize that there are DAV headers for this, as part of feature > coordination and leveling, It is often handy to also rev the > namespace for anything specific to the use of XML. For example, > with the SOAP XML binding to HTTP, a closer analog to WebDAV, I > would think, the SOAP 1.2 Recommendation establishes a different > namespace than is used for the SOAP 1.1 level, and the SOAP 1.2 > specification deals with how to deal properly with SOAP 1.1 as a > legacy. This supports the versioning of XML Schema definitions too, > since XML Schema definitions tend to be targeted to specific namespaces. > > So I wasn't anticipating any kind of versioning of namespace URIs > that would break compatibility with or even usage of the current > specification. I see it as keeping a namespace stable and known, > whether or not it is a proper subset of a future one. > > Namespace versions will already have to be dealt with when > properties, for example, are taken from other XML-mapped > vocabularies, such as Dublin Core, which has a specific namespace > for its current 1.1 level of element definitions. Something like > that will doubtless happen with RDF, if it isn't underway already in > Friday's Last-Call Working Draft documents. > > Having said that, I am not wedded to the idea. I was just suggesting > a way of speaking that would allow for specific-namespace versioning > with minimal editorial impact in future revisions of the DAV > specification. I assume that 2518bis is far enough along that one > would not want to mess with it. In any case, it is an editorial > nuance, nothing substantive. > > I do think of namespace versioning as a key provision for > preservation of interoperability over time, like versioning COM > interfaces (and their UUIDs), and never changing them. Or providing > for versioning in Java package names. Or even like W3C > specification URLs where you can refer to a specific edition or > simply the current latest of the progression. > > -- Dennis > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > From: Of Dennis E. Hamilton > > 1.1 I find it better to refer to the "DAV namespace" or "DAV > > namespace URI" rather than the "DAV: namespace" especially > > because namespaces are often versioned (rather than revised [;<), > > so the identification in XML will be with different URIs over > > time. Ditto for the lock-token namespace. > > .. > > Well. There are no plans to change the namespace URI for DAV:. Doing that > would be an incompatible change breaking all existing code (see for instance > how XSLT deals with versioning). > > [ ... ] > > --=_alternative 004A1EB185256DBD_= Content-Type: text/html; charset="US-ASCII"
By "breaking all existing code", I believe Julian was referring
to the result that no client that only understands V1
of the namespace can work against a server
that only understands V2 of the namespace, and vica versa.

This means that each time you rev the namespace, you introduce
an interoperability nightmare for both clients and servers,
because inevitably, new clients and servers will be written that
only understand the "current" version of the namespace, which
means that client and server implementors that care about interoperability
will have to implement variant code for every new rev of the namespace.

A significant percentage (possibly even a majority) of the hard
design work of WebDAV and its extensions has been
how to add in functionality in a way that is compatible with the
previous standards.  So I agree with Julian that the DAV namespace
should never be "rev"ed, but rather every new WebDAV protocol has
to figure out how to live within the single existing DAV namespace.

Cheers,
Geoff

Dennis wrote on 10/12/2003 02:19:08 AM:

>
> Gee, Namespaces are versioned all of the time without breaking any
> existing code.  I didn't mean to suggest obsolescing anything, only
> that it is useful to speak in a way where a new URI might be usable
> for a *later* namespace.  The existing namespace URI would still
> work, and refer to the current namespace.  A future namespace might
> have the current one as a proper subset and that would work too,
> even though there is a different URI for it.
>
> I realize that there are DAV headers for this, as part of feature
> coordination and leveling, It is often handy to also rev the
> namespace for anything specific to the use of XML.  For example,
> with the SOAP XML binding to HTTP, a closer analog to WebDAV, I
> would think, the SOAP 1.2 Recommendation establishes a different
> namespace than is used for the SOAP 1.1 level, and the SOAP 1.2
> specification deals with how to deal properly with SOAP 1.1 as a
> legacy.  This supports the versioning of XML Schema definitions too,
> since XML Schema definitions tend to be targeted to specific namespaces.
>
> So I wasn't anticipating any kind of versioning of namespace URIs
> that would break compatibility with or even usage of the current
> specification.  I see it as keeping a namespace stable and known,
> whether or not it is a proper subset of a future one.
>
> Namespace versions will already have to be dealt with when
> properties, for example, are taken from other XML-mapped
> vocabularies, such as Dublin Core, which has a specific namespace
> for its current 1.1 level of element definitions.  Something like
> that will doubtless happen with RDF, if it isn't underway already in
> Friday's Last-Call Working Draft documents.
>
> Having said that, I am not wedded to the idea. I was just suggesting
> a way of speaking that would allow for specific-namespace versioning
> with minimal editorial impact in future revisions of the DAV
> specification.  I assume that 2518bis is far enough along that one
> would not want to mess with it.  In any case, it is an editorial
> nuance, nothing substantive.
>
> I do think of namespace versioning as a key provision for
> preservation of interoperability over time, like versioning COM
> interfaces (and their UUIDs), and never changing them.  Or providing
> for versioning in Java package names.  Or even like W3C
> specification URLs where you can refer to a specific edition or
> simply the current latest of the progression.
>
> -- Dennis
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]

> > From: Of Dennis E. Hamilton
> > 1.1   I find it better to refer to the "DAV namespace" or "DAV
> > namespace URI" rather than the "DAV: namespace" especially
> > because namespaces are often versioned (rather than revised [;<),
> > so the identification in XML will be with different URIs over
> > time.  Ditto for the lock-token namespace.
> > ..
>
> Well. There are no plans to change the namespace URI for DAV:. Doing that
> would be an incompatible change breaking all existing code (see for instance
> how XSLT deals with versioning).
>
> [ ... ]
>
>
--=_alternative 004A1EB185256DBD_=-- From w3c-dist-auth-request@w3.org Sun Oct 12 16:12: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 QAA27367 for ; Sun, 12 Oct 2003 16:12:15 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id EBFC7A0A5C; Sun, 12 Oct 2003 16:12:22 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5AE1EA0A5C for ; Sun, 12 Oct 2003 16:12:20 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id E853E1340B; Sun, 12 Oct 2003 16:12:19 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail11.atl.registeredsite.com (mail11.atl.registeredsite.com [64.224.219.85]) by dr-nick.w3.org (Postfix) with ESMTP id C44C7131D2 for ; Sun, 12 Oct 2003 16:12:19 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail11.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9CKCJ4w014970 for ; Sun, 12 Oct 2003 16:12:19 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id NAA07896 for ; Sun, 12 Oct 2003 13:12:18 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: Date: Sun, 12 Oct 2003 13:12:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAIEEDDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7971 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031012201222.EBFC7A0A5C@frink.w3.org> Resent-Date: Sun, 12 Oct 2003 16:12:22 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Geoff, Thanks. I didn't realize until your note that we have different = nightmares, and both of them are about interoperability. I also agree that the level of attention that you suggest in=20 A significant percentage (possibly even a majority) of the hard=20 design work of WebDAV and its extensions has been=20 how to add in functionality in a way that is compatible with the=20 previous standards. So I agree with Julian that the DAV namespace=20 should never be "rev"ed, but rather every new WebDAV protocol has=20 to figure out how to live within the single existing DAV namespace.=20 will make it unnecessary to revise the namespace, although you don't = entirely solve my nightmare with that approach. The one problem that I = have is that a changed or modified namespace is not construed by = everyone (and definitely not me) as a "single existing ... namespace."=20 Also, I am talking about namespace versioning, not revision. Any change = to a namespace is a revision, in my book. A version is a = differently-identified derivative, in my book. Maybe there is better = nomenclature for that. I am interested in suggestions for that. Meanwhile ... 1. Silent Up-Leveling Dangers The java.lang "namespace" is more-or-less maintained the way you = describe. There are deprecated classes and methods, but they are still = there. There are also new elements that are added to the namespace from = time to time. =20 Reliance on new additions creates down-level compatibility problems, and = it happens in a kind of blissful unawareness. But if you distribute a = class file, it can be found to not run on earlier versions of the JVM = and its libraries precisely because an added feature has been relied on = without concern for (or probably even any awareness of) version = dependency. For example, I am fond of double enteredValue =3D java.lang.Double.parseDouble(someInputString); and in using it I am producing a program that will not operate with = versions of Java prior to JDK 1.2. If I make use of the=20 java.lang.String.matches(some-regular-expression)=20 method, my program will not operate with any version of Java prior to = JDK 1.4. When I first started using Java (earlier this year in a course), I was = meticulous about determining the earliest version my code would work = with, and saying so in prominently placed comments and any = documentation. I have gotten lazy and I don't do that any longer. I = should probably build a tool to figure it out for me and then let me = decide if I want to make changes to expand the down-level compatibility = of whatever I produce for widespread usage. It is probably a hack off of = JavaDoc. 2. My nightmare What has me wake up in the middle of the night is any situation that I = have stepped over where (1) there is any change to the semantics of the = same name between two versions of something or (2) there is vocabulary = [local names] in one and not the other, and (3) I haven't provided for = explicit differentiation so that (4) I can be specific in what interface = contract I am depending on or providing, and (5) it is then clear what = is a bug and what isn't. 3. My sense of interoperability 3.1 I do not find it a nightmare to encounter a clearly-versioned use of = XML that says namespace-version-2 is acceptable and name-space-version-1 = is not. I find that honest and clean. It makes a clear declaration of = where interoperability is not provided. =20 3.2 I also see no problem in an XML application saying that = namespace-version-2 is preferred and acceptable and that = namespace-version-1 will be honored and responded to in complete = compliance with the rules that apply to namespace-version-1. That for = me is the best of interoperability. I could even foresee a = specification (or an interoperability profile that applies to a = specification) where acceptors of namespace-version-2 are required to = accept namespace-version-1 and, in so doing, behave as if = namespace-version-2 has never been heard of. =20 3.3 Even better is that there is only namespace-version-1 and any client = who uses namespace-version-1 will never be surprised by any response and = any acceptor of namespace-version-1 will never be surprised by an = unexpected legal use (as the result of some revision that has occurred). = That's a wonderful contract, as long as it can be maintained. Clearly, = if DAV accomplishes that, there is nothing I could possibly quarrel = with. =20 4. Wrap-up I find that the provision for namespace versioning, even if there is = never more than one version, is a bit different than the care one takes = to foster interoperability and then make clear and readily confirmable = what the interoperability agreement is in actual situations. Of course, = namespace applies only to the XML part and not to DAV protocol in the = context of HTTP, DAV methods and all the rest. I suspect our nightmares overlap, but not completely.=20 As I said, this is not a proposal. And your feedback is really useful. = It is valuable to notice that we might have similar but not the same = nightmares around breakdowns in interoperability. I need to document = the guidelines that I intend to follow in work that I do, and what I = think that provides. -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M Clemm Sent: Sunday, October 12, 2003 06:30 To: w3c-dist-auth@w3.org Subject: Re: Versioning Namespaces By "breaking all existing code", I believe Julian was referring=20 to the result that no client that only understands V1=20 of the namespace can work against a server=20 that only understands V2 of the namespace, and vica versa.=20 This means that each time you rev the namespace, you introduce=20 an interoperability nightmare for both clients and servers,=20 because inevitably, new clients and servers will be written that=20 only understand the "current" version of the namespace, which=20 means that client and server implementors that care about = interoperability=20 will have to implement variant code for every new rev of the namespace.=20 A significant percentage (possibly even a majority) of the hard=20 design work of WebDAV and its extensions has been=20 how to add in functionality in a way that is compatible with the=20 previous standards. So I agree with Julian that the DAV namespace=20 should never be "rev"ed, but rather every new WebDAV protocol has=20 to figure out how to live within the single existing DAV namespace.=20 Cheers,=20 Geoff=20 Dennis wrote on 10/12/2003 02:19:08 AM: [ ... ] >=20 > Having said that, I am not wedded to the idea. I was just suggesting > a way of speaking that would allow for specific-namespace versioning > with minimal editorial impact in future revisions of the DAV=20 > specification. I assume that 2518bis is far enough along that one=20 > would not want to mess with it. In any case, it is an editorial=20 > nuance, nothing substantive. >=20 > I do think of namespace versioning as a key provision for=20 > preservation of interoperability over time, like versioning COM=20 > interfaces (and their UUIDs), and never changing them. Or providing > for versioning in Java package names. Or even like W3C=20 > specification URLs where you can refer to a specific edition or=20 > simply the current latest of the progression. >=20 > -- Dennis >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > From: Of Dennis E. Hamilton > > 1.1 I find it better to refer to the "DAV namespace" or "DAV > > namespace URI" rather than the "DAV: namespace" especially > > because namespaces are often versioned (rather than revised [;<), > > so the identification in XML will be with different URIs over > > time. Ditto for the lock-token namespace. > > .. >=20 > Well. There are no plans to change the namespace URI for DAV:. Doing = that > would be an incompatible change breaking all existing code (see for = instance > how XSLT deals with versioning). >=20 > [ ... ] >=20 >=20 From w3c-dist-auth-request@w3.org Sun Oct 12 16:19:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27565 for ; Sun, 12 Oct 2003 16:19:53 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 11B9BA0A43; Sun, 12 Oct 2003 16:19:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E5D36A09A9 for ; Sun, 12 Oct 2003 16:18:59 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 7C56713A14; Sun, 12 Oct 2003 16:18:59 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 17C2013A5E for ; Sun, 12 Oct 2003 16:18:59 -0400 (EDT) Received: (qmail 27662 invoked by uid 65534); 12 Oct 2003 20:18:53 -0000 Received: from p3EE24725.dip.t-dialin.net (HELO lisa) (62.226.71.37) by mail.gmx.net (mp009) with SMTP; 12 Oct 2003 22:18:53 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Julian Reschke" , Date: Sun, 12 Oct 2003 22:18:25 +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: RE: Ignoring Versus Not Validating X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEKFIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7972 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031012201900.11B9BA0A43@frink.w3.org> Resent-Date: Sun, 12 Oct 2003 16:19:00 -0400 (EDT) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Saturday, October 11, 2003 11:31 PM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Ignoring Versus Not Validating > > > > Hi Julian, > > I am responding to your last comment first, since I think this is > an issue to have be clear right away. This is one of the places > where I see missing precision in definition of the DAV reliance > on XML 1.0: > > 1. Accepting that the WebDAV specification says that WebDAV > XML is not to be validated, that is not the same as saying that > any Document Type Declaration can be ignored. > > 2. XML 1.0 gives specific instructions about what must be done > with a Document Type Declaration even for a non-validating > processor. The key statement is in XML 1.0 Recommendation section > 5.1, Validating and Non-Validating Processors > . True. I was oversimplifying. > 3. The use of Document Type Declarations in non-validating > situations is illustrated in the RDF Primer. See > and > the discussion immediately preceding the example. The official > (candidate) RDF Schema for OWL uses this very technique > (). > > (These illustrate the RDF hack, by the way. In some parts of > RDF, (adlib) QNames *are* mapped to URIs by concatenation of the > namespace URI that the prefix stands for, plus the local-name > part, into a new URI. The is used to set up > entity declarations that are used in xmlns:... attributes and in > directly writing the URI form in literals and attribute values.) > > 4. Rather than have so much sensitivity to out-of-band > nuances, I think it would be cleaner and more interoperable (for > DAV, not arbitrary XML) to have the DAV application of XML 1.0 > specify that a Document Type Declaration must not be present. > Then (1) the XML can't be presumed to be validatable, and (2) > there is no confusion about the validating versus non-validating > use as there is when one is provided. > Since, as you say, it doesn't seem to be used, it might be > a good idea to simplify here and say that it is not meant to be. I think RFC2518bis is saying that (see , section 4.4). > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Oct 12 16:30: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 QAA27949 for ; Sun, 12 Oct 2003 16:30:42 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0BBE7A0B70; Sun, 12 Oct 2003 16:30:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id F36F3A0B70 for ; Sun, 12 Oct 2003 16:30:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D77CE13A3A; Sun, 12 Oct 2003 16:30:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 6C91113761 for ; Sun, 12 Oct 2003 16:30:48 -0400 (EDT) Received: (qmail 13889 invoked by uid 65534); 12 Oct 2003 20:30:41 -0000 Received: from p3EE24725.dip.t-dialin.net (HELO lisa) (62.226.71.37) by mail.gmx.net (mp006) with SMTP; 12 Oct 2003 22:30:41 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Julian Reschke" , Date: Sun, 12 Oct 2003 22:30:14 +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: RE: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEKFIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7973 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031012203050.0BBE7A0B70@frink.w3.org> Resent-Date: Sun, 12 Oct 2003 16:30:50 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Sunday, October 12, 2003 8:19 AM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Versioning Namespaces > > > > Gee, Namespaces are versioned all of the time without breaking > any existing code. I didn't mean to suggest obsolescing I think that depends on what you understand with "breaking". If the DAV: namespace URI gets versioned that is *changed*, no existing code will be able to process messages using the new namespace, even if the local names match and do have the same semantics. > anything, only that it is useful to speak in a way where a new > URI might be usable for a *later* namespace. The existing > namespace URI would still work, and refer to the current > namespace. A future namespace might have the current one as a > proper subset and that would work too, even though there is a > different URI for it. That would mean that new elements are put into a new namespace, or existing elements are getting changed and now use a new namespace. That's possible, but it doesn't (IMHO) really means that the namespace is versioned -- you are just adding a second namespace for new elements, and the old one isn't changed at all. That would be a compatible change, however it would mean that when creating messages, you always have to worry about picking the right namespace URI. One of the reasons why XSLT2 elements use the existing XSLT namespace URI. > I realize that there are DAV headers for this, as part of feature > coordination and leveling, It is often handy to also rev the > namespace for anything specific to the use of XML. For example, > with the SOAP XML binding to HTTP, a closer analog to WebDAV, I > would think, the SOAP 1.2 Recommendation establishes a different > namespace than is used for the SOAP 1.1 level, and the SOAP 1.2 > specification deals with how to deal properly with SOAP 1.1 as a > legacy. This supports the versioning of XML Schema definitions > too, since XML Schema definitions tend to be targeted to specific > namespaces. I don't know a lot about SOAP, but SOAP 1.2 is the first revision of the spec issued by a (sort-of) standards body, so it makes perfect sense to restart and not to worry too much about legacy. > So I wasn't anticipating any kind of versioning of namespace URIs > that would break compatibility with or even usage of the current > specification. I see it as keeping a namespace stable and known, > whether or not it is a proper subset of a future one. > > Namespace versions will already have to be dealt with when > properties, for example, are taken from other XML-mapped > vocabularies, such as Dublin Core, which has a specific namespace > for its current 1.1 level of element definitions. Something like Funny that you mention that, because I came across this issue just a few weeks ago (the SAP EP portal will support extraction of RFC2731-formatted custom metadata from remote HTML pages, for instance as support for crawlers). From a WebDAV point of view, DC properties with the same local name differ when they use different namespace URIs. It seems that DC people have found this to be a problem as well. Looking at , they seem to recommend to use unique (and hopefully) stable namespace URIs for their elements. > that will doubtless happen with RDF, if it isn't underway already > in Friday's Last-Call Working Draft documents. > > Having said that, I am not wedded to the idea. I was just > suggesting a way of speaking that would allow for > specific-namespace versioning with minimal editorial impact in > future revisions of the DAV specification. I assume that 2518bis > is far enough along that one would not want to mess with it. In > any case, it is an editorial nuance, nothing substantive. > > I do think of namespace versioning as a key provision for > preservation of interoperability over time, like versioning COM > interfaces (and their UUIDs), and never changing them. Or > providing for versioning in Java package names. Or even like W3C > specification URLs where you can refer to a specific edition or > simply the current latest of the progression. Doing versioning right is *hard*. I think a few months ago it was suggested that the W3C TAG would pick up the topic, and they rejected that :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 13 11:37: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 LAA11609 for ; Mon, 13 Oct 2003 11:37:42 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CA79FA0A5A; Mon, 13 Oct 2003 11:37:45 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B4E00A08A8 for ; Mon, 13 Oct 2003 11:37:41 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 13D3413900; Mon, 13 Oct 2003 11:34:47 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 998CF135A0 for ; Mon, 13 Oct 2003 11:34:46 -0400 (EDT) Received: (qmail 14677 invoked by uid 65534); 13 Oct 2003 15:34:45 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 13 Oct 2003 17:34:45 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Mon, 13 Oct 2003 17:34:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAELNIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7974 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031013153745.CA79FA0A5A@frink.w3.org> Resent-Date: Mon, 13 Oct 2003 11:37:45 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, one of the (many) open issues for the redirect spec is the support for additional response codes, initially reported by Jim. I just re-read RFC2616's section on 3xx status codes, and here's my summary and a proposal how to resolve this: HTTP seems to distinguish the following use cases: (a) permanent redirect (301), (b) temporary redirect (302 or 307), (c) redirect to a GET location after POST (303) and (d) agent-driven negotiation (300). Among these, (a) and (b) seem to be well understood, so we should support both. (c) doesn't seem to be applicable. (d) may become interesting when user agents start supporting it, so the spec should be flexible enough to support a feature extension for that. For now I propose that the client is able to specify the redirection type as a resource type, such as "DAV:permanent-redirect-reference" and "DAV:temporary-redirect-reference". This spec would only define the behaviour for these two resource types and would allow future extensions using new resource types and suggested response codes. (See ) Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 13 14:17:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18663 for ; Mon, 13 Oct 2003 14:17:24 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 8CED5A0799; Mon, 13 Oct 2003 14:17:30 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7A841A0922 for ; Mon, 13 Oct 2003 14:17:28 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 1055A13506; Mon, 13 Oct 2003 14:17:28 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail6.atl.registeredsite.com (mail6.atl.registeredsite.com [64.224.219.80]) by dr-nick.w3.org (Postfix) with ESMTP id E74FC134BE for ; Mon, 13 Oct 2003 14:17:27 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail6.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9DIHPuV014507; Mon, 13 Oct 2003 14:17:25 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id LAA12810; Mon, 13 Oct 2003 11:17:24 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Mon, 13 Oct 2003 11:17:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Ignoring Versus Not Validating X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAIEELDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7975 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031013181730.8CED5A0799@frink.w3.org> Resent-Date: Mon, 13 Oct 2003 14:17:30 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Thanks, Julian. I looked at 2518bis-04 and section 4.4 does not speak to the presence or = absence of material in XML document headers. It says that the given DTD = (in 24.1 and also throughout the document) is informational and is not = meant to be usable for validation of DAV XML 1.0 documents. [We have = already discussed that ANY, as used in the DTD, doesn't accomplish the = intended purpose.] Section 4.4 does not speak to rules for the appearance of = or anything else in the XML Prolog and Document Type Declaration = [REC-XML section 2.8,=20 ] for DAV XML documents. I also checked bis-04 sections 8.1.1, 15, 18.5, 18.6, 19, 24, 24.1, and = 24.2 and there does not seem to be anything to resolve this question. = There are mildly contradictory statements in 8.1.1 and 18.6, though. I = didn't look elsewhere. I continue to recommend that the presence of a = declaration be forbidden in the XML Prolog of DAV XML in HTTP request = bodies and response bodies. This will also take care of 18.6, since the = only way external entities may be declared is in the DTD. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, October 12, 2003 13:18 To: dennis.hamilton@acm.org; Julian Reschke; w3c-dist-auth@w3.org Subject: RE: Ignoring Versus Not Validating > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Saturday, October 11, 2003 11:31 PM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Ignoring Versus Not Validating > [ ... ] > > 4. Rather than have so much sensitivity to out-of-band > nuances, I think it would be cleaner and more interoperable (for > DAV, not arbitrary XML) to have the DAV application of XML 1.0 > specify that a Document Type Declaration must not be present. > Then (1) the XML can't be presumed to be validatable, and (2) > there is no confusion about the validating versus non-validating > use as there is when one is provided. > Since, as you say, it doesn't seem to be used, it might be > a good idea to simplify here and say that it is not meant to be. I think RFC2518bis is saying that (see , section 4.4). > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 13 14:28: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 OAA19040 for ; Mon, 13 Oct 2003 14:28:55 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 81B38A06D8; Mon, 13 Oct 2003 14:29:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E539DA0878 for ; Mon, 13 Oct 2003 14:28:57 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 692B71343E; Mon, 13 Oct 2003 14:28:57 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id B53B213442 for ; Mon, 13 Oct 2003 14:28:53 -0400 (EDT) Received: (qmail 31348 invoked by uid 65534); 13 Oct 2003 18:28:51 -0000 Received: from p3EE2482A.dip.t-dialin.net (HELO lisa) (62.226.72.42) by mail.gmx.net (mp021) with SMTP; 13 Oct 2003 20:28:51 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Julian Reschke" , Date: Mon, 13 Oct 2003 20:28:47 +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: Ignoring Versus Not Validating X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEMGIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7976 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031013182900.81B38A06D8@frink.w3.org> Resent-Date: Mon, 13 Oct 2003 14:29:00 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis, RFC2518 hasn't forbidden a DOCTYPE so far, and as far as I can tell, this never has caused an interop problem. So please let's stay focused in identifying only those things that are broken. What the spec should say is that a recipient MUST NOT attempt to validate a message (either using a hard-wired DTD or a DOCTYPE declaration when present). You are right that section 4.4 currently doesn't state this, so this should be put onto the issues list (-> Jason, listening? :-). Regards, 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 Dennis E. Hamilton > Sent: Monday, October 13, 2003 8:17 PM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: RE: Ignoring Versus Not Validating > > > > Thanks, Julian. > > I looked at 2518bis-04 and section 4.4 does not speak to the > presence or absence of material in XML document headers. It says > that the given DTD (in 24.1 and also throughout the document) is > informational and is not meant to be usable for validation of DAV > XML 1.0 documents. [We have already discussed that ANY, as used > in the DTD, doesn't accomplish the intended purpose.] > > Section 4.4 does not speak to rules for the appearance of > or anything else in the XML Prolog and Document > Type Declaration [REC-XML section 2.8, > ] for DAV XML documents. > > I also checked bis-04 sections 8.1.1, 15, 18.5, 18.6, 19, 24, > 24.1, and 24.2 and there does not seem to be anything to resolve > this question. There are mildly contradictory statements in > 8.1.1 and 18.6, though. I didn't look elsewhere. > > I continue to recommend that the presence of a > declaration be forbidden in the XML Prolog of DAV XML in HTTP > request bodies and response bodies. This will also take care of > 18.6, since the only way external entities may be declared is in the DTD. > > -- Dennis > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, October 12, 2003 13:18 > To: dennis.hamilton@acm.org; Julian Reschke; w3c-dist-auth@w3.org > Subject: RE: Ignoring Versus Not Validating > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > > Sent: Saturday, October 11, 2003 11:31 PM > > To: Julian Reschke; w3c-dist-auth@w3.org > > Subject: Ignoring Versus Not Validating > > > [ ... ] > > > > > 4. Rather than have so much sensitivity to out-of-band > > nuances, I think it would be cleaner and more interoperable (for > > DAV, not arbitrary XML) to have the DAV application of XML 1.0 > > specify that a Document Type Declaration must not be present. > > Then (1) the XML can't be presumed to be validatable, and (2) > > there is no confusion about the validating versus non-validating > > use as there is when one is provided. > > Since, as you say, it doesn't seem to be used, it might be > > a good idea to simplify here and say that it is not meant to be. > > I think RFC2518bis is saying that (see > , > section 4.4). > > > ... > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > From w3c-dist-auth-request@w3.org Mon Oct 13 15:15: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 PAA21730 for ; Mon, 13 Oct 2003 15:15:09 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 19405A0681; Mon, 13 Oct 2003 15:15:15 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 478EBA0681 for ; Mon, 13 Oct 2003 15:15:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 43A1613917; Mon, 13 Oct 2003 15:13:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail11.atl.registeredsite.com (mail11.atl.registeredsite.com [64.224.219.85]) by dr-nick.w3.org (Postfix) with ESMTP id 1F91F13900 for ; Mon, 13 Oct 2003 15:13:56 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail11.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9DJDm4w003932; Mon, 13 Oct 2003 15:13:48 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id MAA18275; Mon, 13 Oct 2003 12:13:47 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Mon, 13 Oct 2003 12:13:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEEODDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7977 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031013191515.19405A0681@frink.w3.org> Resent-Date: Mon, 13 Oct 2003 15:15:15 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Just a couple of things on the practical use of namespace versioning. =20 I just want to sharpen some cases as long as we are discussing this. I = don't have any basis for suggesting that a particular one applies to DAV = (or not). 1. Although I have seen cases where there is an added namespace (for = example, Dublin Core uses two), normally the idea is that the new = namespace includes everything needed. Sometimes namespaces are = partitioned/subsetted for convenience or logical appropriateness, but = that is another matter (RDF uses two in that way (usually prefixed rdf: = and rdfs:), and so does XML Schema (usually prefixed xs: and xsi:). 2. If there is legacy interoperability, which is generally a strong = requirement as well as practical reality, then the usual idea would be = that uses of the original namespace would continue to do so, and the new = namespace would be used only where features of that namespace, not = available with the earlier namespace, are required. There is the matter of people specifying the newer namespace out of = convenience or carelessness, and this causing processors that only = support the original namespace to reject the material. It is like = updating your Microsoft Office Suite and not doing Save As ... to the = oldest compatible version. On the other hand, the Microsoft Office = application actually has all of the information necessary to correctly = do a Save As ... to the oldest compatible version. And a Java processor = could have all of the information necessary to correctly specify the = oldest versions of JDK that a compiled class is definitely compatible = with [;<). Note that changing the namespace without versioning the name does not = make this particular problem go away, it just changes the way the = problem shows up. Versioning the namespace has it show up sharply and = up front, and that may or may not serve the requirements of a particular = application setting. I find that it has a strong accountability quality = that I prefer, as I mentioned in the exchange of nightmares with Geoff. = But, you know, your nightmare may vary. 3. For changes such that the new namespace does not recognize the old as = a subset, there are more problems, obviously. That is the case for = SOAP, where, like it or not, SOAP 1.1 is in serious de facto use (and is = the level used in the WS-I Base Profile 1.0a for interoperable use in = web services). The SOAP 1.2 namespace does not include the SOAP 1.1 = nomenclature and elements as a proper subset. There are substantial and = important differences. And SOAP 1.2 accounts for what the SOAP 1.1 = behavior will be on receiving a SOAP 1.2 request. It also specifies how = SOAP 1.2 processors can properly accept SOAP 1.1 and also how to = properly reject SOAP 1.1 by using responses that a SOAP 1.1 requester = will interpret correctly. I have my own druthers among that set. If the namespace can be held = fixed and not changed as Web DAV is revised, that certainly preserves = maximum interoperability with ones own legacy. I'm for it. I am grateful for this discussion. There is a lot here that I am going = to pay attention to as I look at applying the XML technology set in = other situations, and in writing about it and encouraging best = practices. This has been useful to me whether or not it is particularly = apt in the context of DAV. Thank you, -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, October 12, 2003 13:30 To: dennis.hamilton@acm.org; Julian Reschke; w3c-dist-auth@w3.org Subject: RE: Versioning Namespaces > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Sunday, October 12, 2003 8:19 AM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Versioning Namespaces > > > > Gee, Namespaces are versioned all of the time without breaking > any existing code. I didn't mean to suggest obsolescing I think that depends on what you understand with "breaking". If the DAV: namespace URI gets versioned that is *changed*, no existing code will be able to process messages using the new namespace, even if the local = names match and do have the same semantics. > anything, only that it is useful to speak in a way where a new > URI might be usable for a *later* namespace. The existing > namespace URI would still work, and refer to the current > namespace. A future namespace might have the current one as a > proper subset and that would work too, even though there is a > different URI for it. That would mean that new elements are put into a new namespace, or = existing elements are getting changed and now use a new namespace. That's = possible, but it doesn't (IMHO) really means that the namespace is versioned -- = you are just adding a second namespace for new elements, and the old one = isn't changed at all. That would be a compatible change, however it would mean that when creating messages, you always have to worry about picking the right namespace URI. One of the reasons why XSLT2 elements use the = existing XSLT namespace URI. > I realize that there are DAV headers for this, as part of feature > coordination and leveling, It is often handy to also rev the > namespace for anything specific to the use of XML. For example, > with the SOAP XML binding to HTTP, a closer analog to WebDAV, I > would think, the SOAP 1.2 Recommendation establishes a different > namespace than is used for the SOAP 1.1 level, and the SOAP 1.2 > specification deals with how to deal properly with SOAP 1.1 as a > legacy. This supports the versioning of XML Schema definitions > too, since XML Schema definitions tend to be targeted to specific > namespaces. I don't know a lot about SOAP, but SOAP 1.2 is the first revision of the spec issued by a (sort-of) standards body, so it makes perfect sense to restart and not to worry too much about legacy. > So I wasn't anticipating any kind of versioning of namespace URIs > that would break compatibility with or even usage of the current > specification. I see it as keeping a namespace stable and known, > whether or not it is a proper subset of a future one. > > Namespace versions will already have to be dealt with when > properties, for example, are taken from other XML-mapped > vocabularies, such as Dublin Core, which has a specific namespace > for its current 1.1 level of element definitions. Something like Funny that you mention that, because I came across this issue just a few weeks ago (the SAP EP portal will support extraction of = RFC2731-formatted custom metadata from remote HTML pages, for instance as support for crawlers). >From a WebDAV point of view, DC properties with the same local name = differ when they use different namespace URIs. It seems that DC people have = found this to be a problem as well. Looking at , they seem = to recommend to use unique (and hopefully) stable namespace URIs for their elements. > that will doubtless happen with RDF, if it isn't underway already > in Friday's Last-Call Working Draft documents. > > Having said that, I am not wedded to the idea. I was just > suggesting a way of speaking that would allow for > specific-namespace versioning with minimal editorial impact in > future revisions of the DAV specification. I assume that 2518bis > is far enough along that one would not want to mess with it. In > any case, it is an editorial nuance, nothing substantive. > > I do think of namespace versioning as a key provision for > preservation of interoperability over time, like versioning COM > interfaces (and their UUIDs), and never changing them. Or > providing for versioning in Java package names. Or even like W3C > specification URLs where you can refer to a specific edition or > simply the current latest of the progression. Doing versioning right is *hard*. I think a few months ago it was = suggested that the W3C TAG would pick up the topic, and they rejected that :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 13 17:44:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00917 for ; Mon, 13 Oct 2003 17:44:27 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E959CA0504; Mon, 13 Oct 2003 17:44:34 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id AED4EA0504 for ; Mon, 13 Oct 2003 17:44:32 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5A2E8133EA; Mon, 13 Oct 2003 17:41:38 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail12.atl.registeredsite.com (mail12.atl.registeredsite.com [64.224.219.86]) by dr-nick.w3.org (Postfix) with ESMTP id 8A146133E6 for ; Mon, 13 Oct 2003 17:41:17 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail12.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9DKfGjs003755; Mon, 13 Oct 2003 16:41:16 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id OAA02529; Mon, 13 Oct 2003 14:41:15 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Mon, 13 Oct 2003 14:41:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAGEEPDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7978 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031013214434.E959CA0504@frink.w3.org> Resent-Date: Mon, 13 Oct 2003 17:44:34 -0400 (EDT) Content-Transfer-Encoding: quoted-printable A. RECOMMENDATION I have the following recommendations with regard to the DAV DTD in = section 24.2 of 2518bis-04. 1. It is possible to provide a DTD and account for use of the DAV = namespace and namespace prefixes. There will need to be some special = way to account for the occurrence of ad hoc elements in the specific = cases where elements and attributes from other namespaces may be = introduced. My thoughts on this are incomplete, so it would be = necessary to try some things first to make the DTD one that can actually = be used and confirmed with a validating processor in the presence of ad = hoc elements. (See note at the end.) 2. The form of the DTD should be changed to be an external DTD. (The = form illustrated in 24.2 and in rfc2518 is of an internal DTD given as = part of a declaration). An external DTD is one that has = a URL and can be invoked by reference from a declaration. = At the same time, an internal DTD can also be provided. The internal = DTD is used to provide supplemental information to be used for = validating a given XML document instance. It is even possible to issue = a PUBLIC identifier for such an external DTD so that it can be cached by = validators without having to always be fetched through the URL (which is = taken as a hint). =20 3. The DTD can be parameterized such that documents can use a different = prefix (or the default prefix) value for occurrence of DAV namespace = elements and attributes. Since all of the work is in the DTD, and the = technique is simple, I suggest that it be applied. (More about that = below). 4. This recommendation does not alter my suggestion that = declarations be forbidden as part of the DAV profile for acceptable XML = in DAV request bodies and response bodies. It is valuable to have a way = to validate these elements as part of creation, processing, and = trouble-shooting in specific settings, even when one does not want to = imply validity or validation as a condition of their occurrence as DAV = protocol elements. The material in 24.2 can be useful for those = ancillary purposes as well as for clarifying the DAV reliance on XML. 5. There are many different XML documents (that is, having different = root elements) that arise as DAV protocol elements. There can continue = to be covered a single DTD, since under validation conditions the = particular root to use is named in the declaration, one = way or another. B. PARAMETERIZING A DTD I would suggest that the same parameterization scheme that is used for = the XML Schema Definition DTD. (See .) The = paragraph preceding the schema itself would also apply for rfc2518bis.) = The technique (for the DAV namespace only, here) is to define two = parameter entities: =20 =20 (I chose prefix "dav:" arbitrarily. Any other default, such as "D:" = could be used.) These are internal to the external DTD to be defined. They are used = everywhere in the DTD where DAV namespace element types and DAV namespace attribute types are declared. = (There might not be any such attribute types -- most attribute types are = local to an element type and their names do not require a prefix. It is only when an attribute from a different namespace is used = that this comes up.) The entity declarations above establish default parameter values for the = parameter entity references %dp and %ds. These references occur only in = the DTD, not in the XML document proper. If the document to be assessed for validity uses a different prefix, the = parameter declarations can be over-ridden. For example, to use the = default namespace for a DAV document, one could assess validity using a = validating parser and=20 =20 ] > To use the prefix without overriding, it can work like this: =09 =20 This case is so simple because only DAV namespace elements are used. = (To a DTD validator, a ":" is just another name character.) This form of schema parameterization cannot be normative because there = will be valid documents that are excluded. However, every acceptable = DAV XML will have a form that is valid under this DTD, and that will be = good enough for most situations where some assessment of validity is = desired. It can also support establishment of recommended practice. C. DEALING WITH AD HOC ELEMENTS In order to have an ad hoc element, there needs to be some approach, in = the external DTD, that allows for the internal DTD to provide additional = element and attribute definitions so that the ad hoc material can be = confirmed as valid. =20 For example, the section 24.2 external DTD can easily provide = definitions for DAV-defined properties. However, there needs to be a = way to define the acceptance of additional property elements under = <%dp;prop>. Suppose for now there is a parameter % op for "other = properties" that effectively defaults to an empty set of choices. The following example, however clumsy, illustrates what it takes to do = the job with a valid XML document: ] > Dennis E. Hamilton Orcmid, junior nymph of the Orcan Conclave -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, October 11, 2003 04:04 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) Comments inline... > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 10, 2003 10:45 PM > To: Julian Reschke; Lisa Dusseault; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and = lockdiscovery) > [ ... ] > 1.2 In the context of this discussion, the DAV namespace is not > a barrier to having a DTD. It is prefixes (that is QNames) that > must be dealt with carefully when a DTD is used. However, this > is completely possible, as the XML Schema folk demonstrated. Is it worth the effort? Can you supply (a link to) an example? [ ... ] Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 14 06:22:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02731 for ; Tue, 14 Oct 2003 06:22:24 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A40ACA0722; Tue, 14 Oct 2003 06:21:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E248CA06A1 for ; Tue, 14 Oct 2003 06:21:52 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 72EEE135F5; Tue, 14 Oct 2003 06:21:52 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id 51E8F13540 for ; Tue, 14 Oct 2003 06:21:52 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9EALq42398070 for ; Tue, 14 Oct 2003 06:21:52 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EALooP213630 for ; Tue, 14 Oct 2003 06:21:51 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 14 Oct 2003 06:21:47 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 06:21:52, Serialize complete at 10/14/2003 06:21:52 Content-Type: multipart/alternative; boundary="=_alternative 000E827C85256DBF_=" Subject: Re: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/OFF9E4CD1F.D698FA74-ON85256DBF.000E7386-85256DBF.0038ED07@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7979 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014102154.A40ACA0722@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 06:21:54 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 000E827C85256DBF_= Content-Type: text/plain; charset="US-ASCII" This would be fine with me. Cheers, Geoff Julian wrote on 10/13/2003 11:34:45 AM: > > Hi, > > one of the (many) open issues for the redirect spec is the support for > additional response codes, initially reported by Jim. > > I just re-read RFC2616's section on 3xx status codes, and here's my summary > and a proposal how to resolve this: > > HTTP seems to distinguish the following use cases: > > (a) permanent redirect (301), > (b) temporary redirect (302 or 307), > (c) redirect to a GET location after POST (303) and > (d) agent-driven negotiation (300). > > Among these, (a) and (b) seem to be well understood, so we should support > both. (c) doesn't seem to be applicable. (d) may become interesting when > user agents start supporting it, so the spec should be flexible enough to > support a feature extension for that. > > For now I propose that the client is able to specify the redirection type as > a resource type, such as "DAV:permanent-redirect-reference" and > "DAV:temporary-redirect-reference". This spec would only define the > behaviour for these two resource types and would allow future extensions > using new resource types and suggested response codes. > > > (See > est.html#rfc.issue.lc-85-301>) > > Regards, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 000E827C85256DBF_= Content-Type: text/html; charset="US-ASCII"
This would be fine with me.

Cheers,
Geoff

Julian wrote on 10/13/2003 11:34:45 AM:

>
> Hi,
>
> one of the (many) open issues for the redirect spec is the support for
> additional response codes, initially reported by Jim.
>
> I just re-read RFC2616's section on 3xx status codes, and here's my summary
> and a proposal how to resolve this:
>
> HTTP seems to distinguish the following use cases:
>
> (a) permanent redirect (301),
> (b) temporary redirect (302 or 307),
> (c) redirect to a GET location after POST (303) and
> (d) agent-driven negotiation (300).
>
> Among these, (a) and (b) seem to be well understood, so we should support
> both. (c) doesn't seem to be applicable. (d) may become interesting when
> user agents start supporting it, so the spec should be flexible enough to
> support a feature extension for that.
>
> For now I propose that the client is able to specify the redirection type as
> a resource type, such as "DAV:permanent-redirect-reference" and
> "DAV:temporary-redirect-reference". This spec would only define the
> behaviour for these two resource types and would allow future extensions
> using new resource types and suggested response codes.
>
>
> (See
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-lat
> est.html#rfc.issue.lc-85-301>)
>
> Regards,
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 000E827C85256DBF_=-- From w3c-dist-auth-request@w3.org Tue Oct 14 06: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 GAA02793 for ; Tue, 14 Oct 2003 06:23:19 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 78BFAA082A; Tue, 14 Oct 2003 06:22:02 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 947B5A07E0 for ; Tue, 14 Oct 2003 06:22:01 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 239D713619; Tue, 14 Oct 2003 06:22:01 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (Postfix) with ESMTP id 0701A133F7 for ; Tue, 14 Oct 2003 06:22:01 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9EAM142204082 for ; Tue, 14 Oct 2003 06:22:01 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EALxeU207806 for ; Tue, 14 Oct 2003 06:21:59 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 14 Oct 2003 06:21:49 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 06:22:00, Serialize complete at 10/14/2003 06:22:00 Content-Type: multipart/alternative; boundary="=_alternative 003651F885256DBF_=" Subject: RE: Versioning Namespaces X-Archived-At: http://www.w3.org/mid/OF0B148932.FEF18AB0-ON85256DBE.006DA61D-85256DBF.0038EDF8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7980 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014102202.78BFAA082A@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 06:22:02 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 003651F885256DBF_= Content-Type: text/plain; charset="US-ASCII" Dennis wrote on 10/12/2003 04:12:15 PM: > The one problem > that I have is that a changed or modified namespace is not construed > by everyone (and definitely not me) as a "single existing ... namespace." Yes, there still is the problem of determining what functionality within that namespace is supported by a given server. That's what the DAV header is all about. > Also, I am talking about namespace versioning, not revision. Any > change to a namespace is a revision, in my book. A version is a > differently-identified derivative, in my book. Maybe there is > better nomenclature for that. I am interested in suggestions for that. I don't think "revision" is the right way to model what happens to the DAV namespace. In particular, revision commonly implies a set of alternatives, of which you can pick one. The WebDAV specs do not define a sequence of alternatives, but rather a set of standard "features", any combination of which can be supported by a WebDAV server(with some constraints, e.g. WebDAV level "2" support requires WebDAV level "1" support). The set of features supported by a server is indicated in the DAV response header. > Meanwhile ... > > 1. Silent Up-Leveling Dangers > > The java.lang "namespace" is more-or-less maintained the way you > describe. There are deprecated classes and methods, but they are > still there. There are also new elements that are added to the > namespace from time to time. > > Reliance on new additions creates down-level compatibility problems, > and it happens in a kind of blissful unawareness. But if you > distribute a class file, it can be found to not run on earlier > versions of the JVM and its libraries precisely because an added > feature has been relied on without concern for (or probably even any > awareness of) version dependency. For example, I am fond of > > double enteredValue = java.lang.Double.parseDouble(someInputString); > > and in using it I am producing a program that will not operate with > versions of Java prior to JDK 1.2. If I make use of the > > java.lang.String.matches(some-regular-expression) > > method, my program will not operate with any version of Java prior to JDK 1.4. > > When I first started using Java (earlier this year in a course), I > was meticulous about determining the earliest version my code would > work with, and saying so in prominently placed comments and any > documentation. I have gotten lazy and I don't do that any longer. > I should probably build a tool to figure it out for me and then let > me decide if I want to make changes to expand the down-level > compatibility of whatever I produce for widespread usage. It is > probably a hack off of JavaDoc. This is a problem for Java classes because they do not have the "supported feature" mechanism that is provided by the WebDAV DAV header. WebDAV clients understand that they must deal with servers that support different combinations of WebDAV features. One of the most difficult aspects of defining a WebDAV protocol extension is to invent the minimal number of new features needed for that extension (preferably just one, but for some sophisticated extensions such as DeltaV, several are required). > 2. My nightmare > > What has me wake up in the middle of the night is any situation that > I have stepped over where (1) there is any change to the semantics > of the same name between two versions of something or (2) there is > vocabulary [local names] in one and not the other, and (3) I haven't > provided for explicit differentiation so that (4) I can be specific > in what interface contract I am depending on or providing, and (5) > it is then clear what is a bug and what isn't. In WebDAV: (1) is not allowed, except in extreme cases where the previous semantics was so poorly defined that interoperability would improve by changing the semantics to something closer to what was actually being implemented (e.g. "lock-null resources" in 2518). (2) is explicitly allowed, but must be accompanied by a new DAV feature that allows a client to discover what vocabulary is supported by a given server. which addresses (3), (4), and (5). > 3. My sense of interoperability > > 3.1 I do not find it a nightmare to encounter a clearly-versioned > use of XML that says namespace-version-2 is acceptable and name- > space-version-1 is not. I find that honest and clean. It makes a > clear declaration of where interoperability is not provided. The WebDAV approach of defining DAV features provides significantly superior interoperability. A client that requires features X, Y, and Z just checks whether X, Y, Z are supported by a given server. If they aren't, the client can fail, or can fall back to the subset of features the server does support. > 3.2 I also see no problem in an XML application saying that > namespace-version-2 is preferred and acceptable and that namespace- > version-1 will be honored and responded to in complete compliance > with the rules that apply to namespace-version-1. That for me is > the best of interoperability. I could even foresee a specification > (or an interoperability profile that applies to a specification) > where acceptors of namespace-version-2 are required to accept > namespace-version-1 and, in so doing, behave as if namespace- > version-2 has never been heard of. That is what the WebDAV DAV feature mechanism gives you. > 3.3 Even better is that there is only namespace-version-1 and any > client who uses namespace-version-1 will never be surprised by any > response and any acceptor of namespace-version-1 will never be > surprised by an unexpected legal use (as the result of some revision > that has occurred). That's a wonderful contract, as long as it can > be maintained. Clearly, if DAV accomplishes that, there is nothing > I could possibly quarrel with. It does, so we have no quarrels (about that, anyway, I'm sure that there are some other aspects of the WebDAV protocols that will warrant a quarrel or two :-). > 4. Wrap-up > > I find that the provision for namespace versioning, even if there is > never more than one version, is a bit different than the care one > takes to foster interoperability and then make clear and readily > confirmable what the interoperability agreement is in actual > situations. Of course, namespace applies only to the XML part and > not to DAV protocol in the context of HTTP, DAV methods and all the rest. The WebDAV feature mechanism deals with all of these issues, i.e. a "feature" that appears in the DAV header defines a set of node types in XML, a set of DAV methods, a set of headers, and a set of properties (in the DAV: namespace). And it works by requiring a DAV protocol extension to respect (and re-use when appropriate) every DAV feature that has been defined by a DAV protocol with an earlier IETF RFC number. This makes writing WebDAV protocol extensions an interesting challenge, but it sounds like you appreciate why we would impose this requirement on ourselves. Cheers, Geoff --=_alternative 003651F885256DBF_= Content-Type: text/html; charset="US-ASCII"
Dennis wrote on 10/12/2003 04:12:15 PM:
> The one problem
> that I have is that a changed or modified namespace is not construed
> by everyone (and definitely not me) as a "single existing ... namespace."

Yes, there still is the problem of determining what functionality
within that namespace is supported by a given server.  That's what
the DAV header is all about.

> Also, I am talking about namespace versioning, not revision.  Any
> change to a namespace is a revision, in my book.  A version is a
> differently-identified derivative, in my book.  Maybe there is
> better nomenclature for that. I am interested in suggestions for that.

I don't think "revision" is the right way to model what happens to
the DAV namespace.  In particular, revision commonly implies a
set of alternatives, of which you can pick one.  The WebDAV
specs do not define a sequence of alternatives, but rather a set
of standard "features", any combination of which can be supported
by a WebDAV server(with some constraints, e.g. WebDAV level "2" support
requires WebDAV level "1" support).  The set of features supported
by a server is indicated in the DAV response header.
 
> Meanwhile ...
>
> 1.   Silent Up-Leveling Dangers
>
> The java.lang "namespace" is more-or-less maintained the way you
> describe.  There are deprecated classes and methods, but they are
> still there.  There are also new elements that are added to the
> namespace from time to time.  
>
> Reliance on new additions creates down-level compatibility problems,
> and it happens in a kind of blissful unawareness.  But if you
> distribute a class file, it can be found to not run on earlier
> versions of the JVM and its libraries precisely because an added
> feature has been relied on without concern for (or probably even any
> awareness of) version dependency.  For example, I am fond of
>
>    double enteredValue = java.lang.Double.parseDouble(someInputString);
>
> and in using it I am producing a program that will not operate with
> versions of Java prior to JDK 1.2.  If I make use of the
>
>    java.lang.String.matches(some-regular-expression)
>
> method, my program will not operate with any version of Java prior to JDK 1.4.
>
> When I first started using Java (earlier this year in a course), I
> was meticulous about determining the earliest version my code would
> work with, and saying so in prominently placed comments and any
> documentation.  I have gotten lazy and I don't do that any longer.  
> I should probably build a tool to figure it out for me and then let
> me decide if I want to make changes to expand the down-level
> compatibility of whatever I produce for widespread usage. It is
> probably a hack off of JavaDoc.

This is a problem for Java classes because they do not have the
"supported feature" mechanism that is provided by the WebDAV DAV
header.  WebDAV clients understand that they must deal with servers
that support different combinations of WebDAV features.

One of the most difficult aspects of defining a WebDAV protocol
extension is to invent the minimal number of new features needed
for that extension (preferably just one, but for some sophisticated
extensions such as DeltaV, several are required).

> 2.   My nightmare
>
> What has me wake up in the middle of the night is any situation that
> I have stepped over where (1) there is any change to the semantics
> of the same name between two versions of something or (2) there is
> vocabulary [local names] in one and not the other, and (3) I haven't
> provided for explicit differentiation so that (4) I can be specific
> in what interface contract I am depending on or providing, and (5)
> it is then clear what is a bug and what isn't.

In WebDAV:

(1) is not allowed, except in extreme cases where the previous semantics
was so poorly defined that interoperability would improve by changing the
semantics to something closer to what was actually being implemented
(e.g. "lock-null resources" in 2518).

(2) is explicitly allowed, but must be accompanied by a new DAV feature
that allows a client to discover what vocabulary is supported by a given
server.

which addresses (3), (4), and (5).

> 3.   My sense of interoperability
>
> 3.1   I do not find it a nightmare to encounter a clearly-versioned
> use of XML that says namespace-version-2 is acceptable and name-
> space-version-1 is not.  I find that honest and clean.  It makes a
> clear declaration of where interoperability is not provided.  

The WebDAV approach of defining DAV features provides significantly
superior interoperability.  A client that requires features X, Y, and
Z just checks whether X, Y, Z are supported by a given server.
If they aren't, the client can fail, or can fall back to the subset
of features the server does support.
 
> 3.2   I also see no problem in an XML application saying that
> namespace-version-2 is preferred and acceptable and that namespace-
> version-1 will be honored and responded to in complete compliance
> with the rules that apply to namespace-version-1.  That for me is
> the best of interoperability.  I could even foresee a specification
> (or an interoperability profile that applies to a specification)
> where acceptors of namespace-version-2 are required to accept
> namespace-version-1 and, in so doing, behave as if namespace-
> version-2 has never been heard of.  

That is what the WebDAV DAV feature mechanism gives you.
 
> 3.3   Even better is that there is only namespace-version-1 and any
> client who uses namespace-version-1 will never be surprised by any
> response and any acceptor of namespace-version-1 will never be
> surprised by an unexpected legal use (as the result of some revision
> that has occurred).  That's a wonderful contract, as long as it can
> be maintained.  Clearly, if DAV accomplishes that, there is nothing
> I could possibly quarrel with.  

It does, so we have no quarrels (about that, anyway, I'm sure that
there are some other aspects of the WebDAV protocols that will warrant
a quarrel or two :-).

> 4.   Wrap-up
>
> I find that the provision for namespace versioning, even if there is
> never more than one version, is a bit different than the care one
> takes to foster interoperability and then make clear and readily
> confirmable what the interoperability agreement is in actual
> situations.  Of course, namespace applies only to the XML part and
> not to DAV protocol in the context of HTTP, DAV methods and all the rest.

The WebDAV feature mechanism deals with all of these issues, i.e. a
"feature" that appears in the DAV header defines a set of node types
in XML, a set of DAV methods, a set of headers, and a set of properties
(in the DAV: namespace).  And it works by requiring a DAV protocol extension
to respect (and re-use when appropriate) every DAV feature that has been
defined by a DAV protocol with an earlier IETF RFC number.  This makes
writing WebDAV protocol extensions an interesting challenge, but it sounds
like you appreciate why we would impose this requirement on ourselves.

Cheers,
Geoff
--=_alternative 003651F885256DBF_=-- From w3c-dist-auth-request@w3.org Tue Oct 14 06:23: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 GAA02811 for ; Tue, 14 Oct 2003 06:23:41 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id CF131A082D; Tue, 14 Oct 2003 06:22:03 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B5BC7A0856 for ; Tue, 14 Oct 2003 06:22:02 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 400D8135F5; Tue, 14 Oct 2003 06:22:02 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (Postfix) with ESMTP id 21E13133F7 for ; Tue, 14 Oct 2003 06:22:02 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id h9EAM2He317066 for ; Tue, 14 Oct 2003 06:22:02 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EAM0oP125932 for ; Tue, 14 Oct 2003 06:22:00 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 14 Oct 2003 06:21:57 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 06:22:01, Serialize complete at 10/14/2003 06:22:01 Content-Type: multipart/alternative; boundary="=_alternative 0036FD4A85256DBF_=" Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/OFA7788E2D.05432B37-ON85256DBF.00368437-85256DBF.0038F0D9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7981 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014102203.CF131A082D@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 06:22:03 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 0036FD4A85256DBF_= Content-Type: text/plain; charset="US-ASCII" Dennis wrote on 10/10/2003 04:45:13 PM: > OK, end of brain dump. > > > > Relax. My next class starts on October 16 and I will quiet down for > another 8 weeks ... Dennis: Thanks for spending time on these topics! It is always useful to re-explore these kinds of issues, since it is likely other folks have similar questions and concerns, and since there are usually at least some points that we have missed (e.g. the question about the suitability of ANY to describe the desired syntactic behavior of DAV:prop). Looking forward to hearing again from you in your next break from classes. Cheers, Geoff --=_alternative 0036FD4A85256DBF_= Content-Type: text/html; charset="US-ASCII"
Dennis wrote on 10/10/2003 04:45:13 PM:

> OK, end of brain dump.
>
> </dh:braindump>
>
> Relax.  My next class starts on October 16 and I will quiet down for
> another 8 weeks ...
Dennis:

Thanks for spending time on these topics!  It is always useful to re-explore
these kinds of issues, since it is likely other folks have similar questions
and concerns, and since there are usually at least some points that we have
missed (e.g. the question about the suitability of ANY to describe the
desired syntactic behavior of DAV:prop).

Looking forward to hearing again from you in your next break from classes.

Cheers,
Geoff --=_alternative 0036FD4A85256DBF_=-- From w3c-dist-auth-request@w3.org Tue Oct 14 09:53: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 JAA09647 for ; Tue, 14 Oct 2003 09:53:48 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 28998A07D3; Tue, 14 Oct 2003 09:53:45 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5C2AEA0B57 for ; Tue, 14 Oct 2003 09:53:41 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B62BF138DA; Tue, 14 Oct 2003 09:53:31 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 49A19139A5 for ; Tue, 14 Oct 2003 09:53:31 -0400 (EDT) Received: (qmail 29377 invoked by uid 65534); 14 Oct 2003 13:53:30 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp026) with SMTP; 14 Oct 2003 15:53:30 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Tue, 14 Oct 2003 15:53:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEOFIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7982 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014135345.28998A07D3@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 09:53:45 -0400 (EDT) Content-Transfer-Encoding: 7bit > OK, > > so we probably should put it onto the issues list (so that it doesn't get lost). Here's a proposal for the issues list: Issue DAV_REQUEST_HEADER RFC 2518 provides a mechanism (the "DAV" response header) for a server to indicate to a client that it supports a specific WebDAV option (e.g. "1", "2", "version-control", etc.), but there is no complementary mechanism for a client to indicate to a server that it understands a specific WebDAV option. This becomes an issue when a WebDAV extension (or revision) needs to change response formats in a way that possibly break existing clients. Detecting client features based on a single, well-defined request header will work better than (for instance) relying on custom headers (specified by each extension) or "User-Agent". Suggested resolution: allow the use of the "DAV" header as a request header, with the same set of values that are defined for the "DAV" response header. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 14 10:43:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12734 for ; Tue, 14 Oct 2003 10:43:27 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 5058DA055A; Tue, 14 Oct 2003 10:43:35 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7EE28A0978 for ; Tue, 14 Oct 2003 10:43:33 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 4E7BD13947; Tue, 14 Oct 2003 10:43:33 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id D2EF813944 for ; Tue, 14 Oct 2003 10:43:32 -0400 (EDT) Received: (qmail 8435 invoked by uid 65534); 14 Oct 2003 14:43:32 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 14 Oct 2003 16:43:32 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , Date: Tue, 14 Oct 2003 16:43:29 +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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEOHIMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7983 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014144335.5058DA055A@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 10:43:35 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis, I'm not sure what you're trying to achieve. On the one hand, we're trying to clarify that WebDAV messages MUST not be validated using DTDs. On the other hand, you're trying to come up with a clever way to enable DTD validation. As far as I understand, it will never work for arbitrary now legal WebDAV messages, so why bother? After all, the initial question was about whether we want to continue using DTD fragments to specify some constraints on WebDAV messages -- after all, this is what all published and soon-to-be published WebDAV-related specs do. So if there's an issue with that notation, we should fix just that, nothing more... In particular, if "fixing" the DTD notation essentially means to make it extremely complicated to read, this will be in fact contra-productive. > ... > > > > > Dennis E. Hamilton > > xmlns:dc="http://purl.org/dc/elements/1.1/"> > Orcmid, junior nymph of the Orcan Conclave > > > > Nit: that isn't a meaningful request. Each WebDAV property only can have a single value, so having it twice in propertyupdate will just result in the "last" value being set. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 14 13:23: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 NAA19999 for ; Tue, 14 Oct 2003 13:23:10 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F19F6A07AF; Tue, 14 Oct 2003 13:23:18 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id BA702A07AF for ; Tue, 14 Oct 2003 13:23:16 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 497AD139D2; Tue, 14 Oct 2003 13:23:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 27CCD13951 for ; Tue, 14 Oct 2003 13:23:16 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9EHNGYN874850 for ; Tue, 14 Oct 2003 13:23:16 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EHNEdL219064 for ; Tue, 14 Oct 2003 13:23:14 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 14 Oct 2003 13:23:12 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 13:23:15, Serialize complete at 10/14/2003 13:23:15 Content-Type: multipart/alternative; boundary="=_alternative 005F820F85256DBF_=" Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/OFF83FE0B4.55A2F222-ON85256DBF.005F4C96-85256DBF.005F8212@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7984 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014172318.F19F6A07AF@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 13:23:18 -0400 (EDT) This is a multipart message in MIME format. --=_alternative 005F820F85256DBF_= Content-Type: text/plain; charset="US-ASCII" I support this addition to RFC2518bis. I believe it is a key mechanism needed for servers to properly support the various current (and future) WebDAV extensions. Cheers, Geoff Julian wrote on 10/14/2003 09:53:30 AM: > > > OK, > > > > so we probably should put it onto the issues list (so that it doesn't get > lost). > > Here's a proposal for the issues list: > > > Issue DAV_REQUEST_HEADER > > RFC 2518 provides a mechanism (the "DAV" response header) for a server to > indicate to a client that it supports a specific WebDAV option (e.g. "1", > "2", "version-control", etc.), but there is no complementary mechanism for a > client to indicate to a server that it understands a specific WebDAV option. > This becomes an issue when a WebDAV extension (or revision) needs to change > response formats in a way that possibly break existing clients. Detecting > client features based on a single, well-defined request header will work > better than (for instance) relying on custom headers (specified by each > extension) or "User-Agent". > > Suggested resolution: allow the use of the "DAV" header as a request header, > with the same set of values that are defined for the "DAV" > response header. > > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 005F820F85256DBF_= Content-Type: text/html; charset="US-ASCII"
I support this addition to RFC2518bis.

I believe it is a key mechanism needed for servers to properly support
the various current (and future) WebDAV extensions.

Cheers,
Geoff

Julian wrote on 10/14/2003 09:53:30 AM:

>
> > OK,
> >
> > so we probably should put it onto the issues list (so that it doesn't get
> lost).
>
> Here's a proposal for the issues list:
>
>
> Issue DAV_REQUEST_HEADER
>
> RFC 2518 provides a mechanism (the "DAV" response header) for a server to
> indicate to a client that it supports a specific WebDAV option (e.g. "1",
> "2", "version-control", etc.), but there is no complementary mechanism for a
> client to indicate to a server that it understands a specific WebDAV option.
> This becomes an issue when a WebDAV extension (or revision) needs to change
> response formats in a way that possibly break existing clients. Detecting
> client features based on a single, well-defined request header will work
> better than (for instance) relying on custom headers (specified by each
> extension) or "User-Agent".
>
> Suggested resolution: allow the use of the "DAV" header as a request header,
> with the same set of values that are defined for the "DAV"
> response header.
>
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 005F820F85256DBF_=-- From w3c-dist-auth-request@w3.org Tue Oct 14 15:33: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 PAA25966 for ; Tue, 14 Oct 2003 15:33:40 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C0D5AA0928; Tue, 14 Oct 2003 15:32:56 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EE792A0937 for ; Tue, 14 Oct 2003 15:32:54 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D167A136D9; Tue, 14 Oct 2003 15:32:54 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail8.atl.registeredsite.com (mail8.atl.registeredsite.com [64.224.219.82]) by dr-nick.w3.org (Postfix) with ESMTP id 9E5CB136B6 for ; Tue, 14 Oct 2003 15:32:54 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail8.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9EJVCdE017011; Tue, 14 Oct 2003 15:31:12 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id MAA12607; Tue, 14 Oct 2003 12:31:10 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Tue, 14 Oct 2003 12:31:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAIEFNDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7985 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014193256.C0D5AA0928@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 15:32:56 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Hi Julian, I'm surprised once again. OK, there are several topics here: 1. Having a generic DTD for WebDAV, or at least one that is generic as = possible considering that actual documents can introduce ad hoc elements = and attributes in various places. There was a question about how to do it and sources on the technique. I = have addressed that question. I have only addressed the question in the = context of section 24.2 of bis-04, because I saw immediate application = there. It is also an useful cross-check on the specification and it = provides an operable DTD that people can use in working with the = specification, creating DAV protocol elements manually, etc., under the = understanding that it is non-normative. 2. Having a way that someone could develop a quasi-generic DTD for a = family of WebDAV XML documents of interest. =20 I think that comes out of (1). Since this is a restricted-use = situation, a precise DTD might actually be possible for many situations = in practice, and I demonstrated a way to have that. It is also possible = in many places where ad hoc properties and attributes are either not = provided for or don't happen to be used. 3. Using XML DTD Fragments (markup declarations) to illustrate/explicate = (not specify) the structures that apply for specific elements of WebDAV. = =20 Since that can't be "normative" as a DTD anywhere that allows ad hoc = elements in the content model, or ad hoc attributes of an element, I = would think it is a nit whether you use a convention of supposing a = representative (explicit) namespace prefix for QNames in the = specification, as many XML-family specifications do, or you show the use = of parameters in the specimen markup declarations. It's the difference = between =20 and where the second parameterizes the use of namespace prefix, but which = might not be so appealing in the flow of the exposition. Either way, I = would not show the everywhere. The assumption of such an = would be explained in the documentation of fragment usage = in the specification. I am not addressing the question of DTD fragments with my proposal for = section 24.2. One can do 24.2 independent of whether markup = declarations are used elsewhere in the specification, and whether they = are of the same literal form. =20 4. Concerning the question of whether or not Document Type Declarations = () should be allowed in the XML document prolog of DAV = request and response bodies, I see my recommendation for 24.2 as = orthogonal to that. =20 Also, I don't believe there is agreement to disallow Document Type = Declarations at this time. (I will keep repeating that presence of a = Document Type Declaration and using a non-validating processor are = separate but interacting matters.) It is valuable to have a DTD that is crafted in such a way that it can = be used to establish validity of a document in proper form (e.g., no = defaulted attribute values for required attributes) for use with or = without validation, with or without a Document Type Declaration. I = think one can come close to that as a practical matter. I find it = valuable. I find interactions with the requirement for use of a non-validating XML = processor to be problematic. A way to assure a predictable, = interoperable non-validating process case is to omit Document Type = Declarations in requests (as a practice, even if not a requirement of = 2518). There is absolutely no doubt about validation in that case. So = omission of a Document Type Declaration is a good practice for obtaining = clearly-predictable behavior in DAV requests (and appropriate safety, = regarding any concern for reference to external parameters and external = XML entities as identified in section 18.6 of bis-04). =20 Dealing with a server that provides Document Type Declarations in = responses is something I don't want to think about. In practice, that = borders on a hostile act, since it imposes processing on the client and = has the interpretation of the response be unpredictable in some cases. = It raises the bar for universal client processors. 5. Why do I consider (4) and some of the other items when we are "only" = talking about HTTP extensions and what happens in that narrow band of = what the DAV functioning is all about -- the exchange of protocol = elements? =20 I answer with a question: Why is it important to use XML in that narrow = setting? I am considering the setting and the desire people have to be = able to understand the rules, apply tools that are available and = supported in the industry, and also be able to check their work (or the = work of their software) as well as trouble-shoot. That strikes me as = valuable. =20 6. Is it worth it? I don't know. I demonstrated the degree to which it = could be done. Developers of other XML-family specifications have found = it worthwhile. Does it hurt? How can it? Would I do it? Yes. This can clearly be done. Whether it is included in the specification = or not seems to be the question. We need some other countries to be = heard from. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, October 14, 2003 07:43 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Dennis, I'm not sure what you're trying to achieve. On the one hand, we're trying to clarify that WebDAV messages MUST not = be validated using DTDs. On the other hand, you're trying to come up with a clever way to enable DTD validation. As far as I understand, it will = never work for arbitrary now legal WebDAV messages, so why bother? After all, the initial question was about whether we want to continue = using DTD fragments to specify some constraints on WebDAV messages -- after = all, this is what all published and soon-to-be published WebDAV-related specs = do. So if there's an issue with that notation, we should fix just that, = nothing more... In particular, if "fixing" the DTD notation essentially means to make it extremely complicated to read, this will be in fact contra-productive. [ ... ] Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 14 16:25: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 QAA00092 for ; Tue, 14 Oct 2003 16:25:30 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6E746A0D9E; Tue, 14 Oct 2003 16:24:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A8487A0D9E for ; Tue, 14 Oct 2003 16:24:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 307CD13A9D; Tue, 14 Oct 2003 16:24:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id E69571370C for ; Tue, 14 Oct 2003 16:24:47 -0400 (EDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9EKOleQ001183 for ; Tue, 14 Oct 2003 13:24:48 -0700 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 h9EKOlG02162 for ; Tue, 14 Oct 2003 14:24:47 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9EKOkG02150 for ; Tue, 14 Oct 2003 14:24:46 -0600 (MDT) Message-ID: <0b8c01c39291$1dadaba0$c5b42382@us.oracle.com> From: "Stanley Guan" To: References: Date: Tue, 14 Oct 2003 13:24:05 -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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/0b8c01c39291$1dadaba0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7986 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031014202450.6E746A0D9E@frink.w3.org> Resent-Date: Tue, 14 Oct 2003 16:24:50 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, I'm new on this mailing list. So, forgive me if my questions were brought up before. For security consideration, external XML entities are considered vulnerable to denial of service attack. So, I agree that WebDAV messages MUST not be validated using DTDs. Or it can be optional, if an implementation opt to do that. Anyone else have ever thought of using XML Schema, instead of DTD, to validate WebDAV messages? Any security concerns? Will appreciate your inputs! -Stanley ----- Original Message ----- From: "Dennis E. Hamilton" To: "Julian Reschke" ; Sent: Tuesday, October 14, 2003 12:31 PM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Hi Julian, I'm surprised once again. OK, there are several topics here: 1. Having a generic DTD for WebDAV, or at least one that is generic as possible considering that actual documents can introduce ad hoc elements and attributes in various places. There was a question about how to do it and sources on the technique. I have addressed that question. I have only addressed the question in the context of section 24.2 of bis-04, because I saw immediate application there. It is also an useful cross-check on the specification and it provides an operable DTD that people can use in working with the specification, creating DAV protocol elements manually, etc., under the understanding that it is non-normative. 2. Having a way that someone could develop a quasi-generic DTD for a family of WebDAV XML documents of interest. I think that comes out of (1). Since this is a restricted-use situation, a precise DTD might actually be possible for many situations in practice, and I demonstrated a way to have that. It is also possible in many places where ad hoc properties and attributes are either not provided for or don't happen to be used. 3. Using XML DTD Fragments (markup declarations) to illustrate/explicate (not specify) the structures that apply for specific elements of WebDAV. Since that can't be "normative" as a DTD anywhere that allows ad hoc elements in the content model, or ad hoc attributes of an element, I would think it is a nit whether you use a convention of supposing a representative (explicit) namespace prefix for QNames in the specification, as many XML-family specifications do, or you show the use of parameters in the specimen markup declarations. It's the difference between and where the second parameterizes the use of namespace prefix, but which might not be so appealing in the flow of the exposition. Either way, I would not show the everywhere. The assumption of such an would be explained in the documentation of fragment usage in the specification. I am not addressing the question of DTD fragments with my proposal for section 24.2. One can do 24.2 independent of whether markup declarations are used elsewhere in the specification, and whether they are of the same literal form. 4. Concerning the question of whether or not Document Type Declarations () should be allowed in the XML document prolog of DAV request and response bodies, I see my recommendation for 24.2 as orthogonal to that. Also, I don't believe there is agreement to disallow Document Type Declarations at this time. (I will keep repeating that presence of a Document Type Declaration and using a non-validating processor are separate but interacting matters.) It is valuable to have a DTD that is crafted in such a way that it can be used to establish validity of a document in proper form (e.g., no defaulted attribute values for required attributes) for use with or without validation, with or without a Document Type Declaration. I think one can come close to that as a practical matter. I find it valuable. I find interactions with the requirement for use of a non-validating XML processor to be problematic. A way to assure a predictable, interoperable non-validating process case is to omit Document Type Declarations in requests (as a practice, even if not a requirement of 2518). There is absolutely no doubt about validation in that case. So omission of a Document Type Declaration is a good practice for obtaining clearly-predictable behavior in DAV requests (and appropriate safety, regarding any concern for reference to external parameters and external XML entities as identified in section 18.6 of bis-04). Dealing with a server that provides Document Type Declarations in responses is something I don't want to think about. In practice, that borders on a hostile act, since it imposes processing on the client and has the interpretation of the response be unpredictable in some cases. It raises the bar for universal client processors. 5. Why do I consider (4) and some of the other items when we are "only" talking about HTTP extensions and what happens in that narrow band of what the DAV functioning is all about -- the exchange of protocol elements? I answer with a question: Why is it important to use XML in that narrow setting? I am considering the setting and the desire people have to be able to understand the rules, apply tools that are available and supported in the industry, and also be able to check their work (or the work of their software) as well as trouble-shoot. That strikes me as valuable. 6. Is it worth it? I don't know. I demonstrated the degree to which it could be done. Developers of other XML-family specifications have found it worthwhile. Does it hurt? How can it? Would I do it? Yes. This can clearly be done. Whether it is included in the specification or not seems to be the question. We need some other countries to be heard from. -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, October 14, 2003 07:43 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Dennis, I'm not sure what you're trying to achieve. On the one hand, we're trying to clarify that WebDAV messages MUST not be validated using DTDs. On the other hand, you're trying to come up with a clever way to enable DTD validation. As far as I understand, it will never work for arbitrary now legal WebDAV messages, so why bother? After all, the initial question was about whether we want to continue using DTD fragments to specify some constraints on WebDAV messages -- after all, this is what all published and soon-to-be published WebDAV-related specs do. So if there's an issue with that notation, we should fix just that, nothing more... In particular, if "fixing" the DTD notation essentially means to make it extremely complicated to read, this will be in fact contra-productive. [ ... ] Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 03:29: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 DAA18803 for ; Wed, 15 Oct 2003 03:29:56 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1CA82A0D7A; Wed, 15 Oct 2003 03:28:55 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 39BC3A0D74 for ; Wed, 15 Oct 2003 03:28:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id AF36D13757; Wed, 15 Oct 2003 03:28:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id E91C513741 for ; Wed, 15 Oct 2003 03:28:47 -0400 (EDT) Received: from greenbytes.de ([192.168.1.23]) (authenticated user se@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v6.8.5.R) with ESMTP id 22-md50000000038.tmp for ; Wed, 15 Oct 2003 09:28:44 +0200 Date: Wed, 15 Oct 2003 09:28:40 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Stefan Eissing To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <32F41807-FEE1-11D7-B204-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.552) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Wed, 15 Oct 2003 09:28: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 Subject: Re: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/32F41807-FEE1-11D7-B204-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7987 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015072855.1CA82A0D7A@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 03:28:55 -0400 (EDT) Content-Transfer-Encoding: 7bit +1. Am Dienstag, 14.10.03, um 19:23 Uhr (Europe/Berlin) schrieb Geoffrey M Clemm: > > I support this addition to RFC2518bis. > > I believe it is a key mechanism needed for servers to properly support > the various current (and future) WebDAV extensions. > > Cheers, > Geoff > > Julian wrote on 10/14/2003 09:53:30 AM: > > > > > > OK, > > > > > > so we probably should put it onto the issues list (so that it > doesn't get > > lost). > > > > Here's a proposal for the issues list: > > > > > > Issue DAV_REQUEST_HEADER > > > > RFC 2518 provides a mechanism (the "DAV" response header) for a > server to > > indicate to a client that it supports a specific WebDAV option (e.g. > "1", > > "2", "version-control", etc.), but there is no complementary > mechanism for a > > client to indicate to a server that it understands a specific WebDAV > option. > > This becomes an issue when a WebDAV extension (or revision) needs to > change > > response formats in a way that possibly break existing clients. > Detecting > > client features based on a single, well-defined request header will > work > > better than (for instance) relying on custom headers (specified by > each > > extension) or "User-Agent". > > > > Suggested resolution: allow the use of the "DAV" header as a request > header, > > with the same set of values that are defined for the "DAV" > > response header. > > > > > > Regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 15 04:44:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20542 for ; Wed, 15 Oct 2003 04:44:34 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4D1F9A0883; Wed, 15 Oct 2003 04:44:39 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9285DA0883 for ; Wed, 15 Oct 2003 04:44:28 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 8A67C13B95; Wed, 15 Oct 2003 04:42:52 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 222CA13B8A for ; Wed, 15 Oct 2003 04:42:52 -0400 (EDT) Received: (qmail 19449 invoked by uid 65534); 15 Oct 2003 08:42:50 -0000 Received: from pD950C247.dip.t-dialin.net (HELO lisa) (217.80.194.71) by mail.gmx.net (mp012) with SMTP; 15 Oct 2003 10:42:50 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , Date: Wed, 15 Oct 2003 10:42:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <0b8c01c39291$1dadaba0$c5b42382@us.oracle.com> Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEADINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7988 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015084439.4D1F9A0883@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 04:44:39 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Tuesday, October 14, 2003 10:24 PM > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > Hi, > > I'm new on this mailing list. So, forgive me if my questions were > brought up before. Sure. > For security consideration, external XML entities are considered > vulnerable to denial of service attack. So, I agree that WebDAV > messages MUST not be validated using DTDs. Or it can be > optional, if an implementation opt to do that. I think we need to be precise here. As far as I understand, the XML recommendation does only define one very specific form of validation, and it is based on the document/message declaring it's document type. Exactly this kind of validation is completely useless in XML based protocols: it's completely irrelevant whether a document conforms to a DTD that the *sender* provides. It would be only interesting to validate against the DTD expected by the *recipient*. Doing the latter of course is completely up to the recipient -- however it must be aware of the fact that the DTD (fragments) in RFC2518 and related specs only describe part of the constraints, and that a recipient MUST accept way more message variations as the DTDs (per XML rec) allow. > Anyone else have ever thought of using XML Schema, instead of > DTD, to validate WebDAV messages? Any security concerns? If the schema or the reference to the schema is provided by the sender of the message, I think the same concerns apply. If the schema is hardwired into the recipient, none apply. On the other hand, I don't see any big advantage in using XML Schema as replacement in WebDAV specs. It only solves one particular problem (DTDs ignorance of namespaces), but is a lot harder to read. If we really decide not to use DTD syntax anymore, we should consider a schema language that can *really* express the DAV extensibility rules, and that's easy to read by the (human) readers of the spec. As far as I understand, Relax NG (compact syntax) would qualify. You may also want to check out RFC3470 ("Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", section 4.7. > Will appreciate your inputs! Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 06:07:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23174 for ; Wed, 15 Oct 2003 06:07:52 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 44802A06CF; Wed, 15 Oct 2003 06:07:56 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 77AFCA0DF6 for ; Wed, 15 Oct 2003 06:07:45 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id CDFE613BBA; Wed, 15 Oct 2003 06:06:29 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 65CDD133A1 for ; Wed, 15 Oct 2003 06:06:29 -0400 (EDT) Received: (qmail 18267 invoked by uid 65534); 15 Oct 2003 10:06:29 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001) with SMTP; 15 Oct 2003 12:06:29 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , Date: Wed, 15 Oct 2003 12:06:28 +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 Importance: Normal In-Reply-To: Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEAFINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7989 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015100756.44802A06CF@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 06:07:56 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis, I appreciate the time you're spending thinking about this subject. The question that started this thread was what to do with the DTD notation that is used in current WebDAV specs and that disappeared in RFC2518bis. My position is that we should keep it and make sure that the spec clearly says what it means for developers. Other comments inline... > 4. Concerning the question of whether or not Document Type > Declarations () should be allowed in the XML > document prolog of DAV request and response bodies, I see my > recommendation for 24.2 as orthogonal to that. > > Also, I don't believe there is agreement to disallow Document > Type Declarations at this time. (I will keep repeating that > presence of a Document Type Declaration and using a > non-validating processor are separate but interacting matters.) Yes. They haven't been forbidden before, and they don't seem to cause harm. > Dealing with a server that provides Document Type Declarations in > responses is something I don't want to think about. In practice, > that borders on a hostile act, since it imposes processing on the > client and has the interpretation of the response be > unpredictable in some cases. It raises the bar for universal > client processors. Nope. The spec should clearly state that messages must be processed in non-validating mode. In this case, it's really irrelevant whether a DOCTYPE is present (except for the well-known recursive entity substition problem). > 6. Is it worth it? I don't know. I demonstrated the degree > to which it could be done. Developers of other XML-family > specifications have found it worthwhile. Does it hurt? How can it? > Would I do it? Yes. > > This can clearly be done. Whether it is included in the > specification or not seems to be the question. We need some > other countries to be heard from. I don't argue with automatic "checking" (avoiding "validation" because it implies DTD to many readers) of messages based on a formal description being useful. However, we were discussing the role of DTD fragments in the spec *as they are*. My take is that it's best to - first get a consensus about what they are supposed to mean - I've been repeating my proposal many times now (before *this* discussion started), and I'd really like to see whether we finally agree on that - then find out whether we can keep that syntax - I think it's worthwhole keeping it for the simple reason that it's present on published specs If we keep the syntax *and* agree about what it means, it will be simple to specify a process by which an arbitrary WebDAV message can be transformed into a format that *can* be validated. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 10:19:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01243 for ; Wed, 15 Oct 2003 10:19:17 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 62172A0556; Wed, 15 Oct 2003 10:19:24 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3A0EEA0556 for ; Wed, 15 Oct 2003 10:19:22 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id BE8131346C; Wed, 15 Oct 2003 10:19:21 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by dr-nick.w3.org (Postfix) with ESMTP id 8F29F133EE for ; Wed, 15 Oct 2003 10:19:21 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9FEJLnb022218 for ; Wed, 15 Oct 2003 07:19:21 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9FEJKt23256 for ; Wed, 15 Oct 2003 08:19:20 -0600 (MDT) Received: from esedlar (dhcp-amer-vpn-rmdc-gw2-east-141-144-120-80.vpn.oracle.com [141.144.120.80]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9FEJJt23193 for ; Wed, 15 Oct 2003 08:19:19 -0600 (MDT) Message-Id: <200310151419.h9FEJJt23193@rgmgw4.us.oracle.com> From: "Eric Sedlar" To: Date: Wed, 15 Oct 2003 07:20:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: <32F41807-FEE1-11D7-B204-00039384827E@greenbytes.de> Thread-Index: AcOS7m+t+mAiMPa6Rv+8J1P18ZqDJQAOQsvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/200310151419.h9FEJJt23193@rgmgw4.us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7990 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015141924.62172A0556@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 10:19:24 -0400 (EDT) Content-Transfer-Encoding: 7bit +1 > -----Original Message----- > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Stefan Eissing > Sent: Wednesday, October 15, 2003 12:29 AM > To: w3c-dist-auth@w3.org > > > +1. > > Am Dienstag, 14.10.03, um 19:23 Uhr (Europe/Berlin) schrieb Geoffrey M > Clemm: > > > > > I support this addition to RFC2518bis. > > > > I believe it is a key mechanism needed for servers to properly support > > the various current (and future) WebDAV extensions. > > > > Cheers, > > Geoff > > > > Julian wrote on 10/14/2003 09:53:30 AM: > > > > > > > > > OK, > > > > > > > > so we probably should put it onto the issues list (so that it > > doesn't get > > > lost). > > > > > > Here's a proposal for the issues list: > > > > > > > > > Issue DAV_REQUEST_HEADER > > > > > > RFC 2518 provides a mechanism (the "DAV" response header) for a > > server to > > > indicate to a client that it supports a specific WebDAV option (e.g. > > "1", > > > "2", "version-control", etc.), but there is no complementary > > mechanism for a > > > client to indicate to a server that it understands a specific WebDAV > > option. > > > This becomes an issue when a WebDAV extension (or revision) needs to > > change > > > response formats in a way that possibly break existing clients. > > Detecting > > > client features based on a single, well-defined request header will > > work > > > better than (for instance) relying on custom headers (specified by > > each > > > extension) or "User-Agent". > > > > > > Suggested resolution: allow the use of the "DAV" header as a request > > header, > > > with the same set of values that are defined for the "DAV" > > > response header. > > > > > > > > > Regards, Julian > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > From w3c-dist-auth-request@w3.org Wed Oct 15 12:52: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 MAA08881 for ; Wed, 15 Oct 2003 12:52:27 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id EFB42A0713; Wed, 15 Oct 2003 12:52:33 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DF177A0713 for ; Wed, 15 Oct 2003 12:52:30 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9E8E0136EA; Wed, 15 Oct 2003 12:52:30 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id 67D1C13552 for ; Wed, 15 Oct 2003 12:52:30 -0400 (EDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9FGqUeQ029182 for ; Wed, 15 Oct 2003 09:52:30 -0700 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9FGqTh13145 for ; Wed, 15 Oct 2003 10:52:29 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9FGqRh13089 for ; Wed, 15 Oct 2003 10:52:27 -0600 (MDT) Message-ID: <0bea01c3933c$985c1c00$c5b42382@us.oracle.com> From: "Stanley Guan" To: References: Date: Wed, 15 Oct 2003 09:51:35 -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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/0bea01c3933c$985c1c00$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7991 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015165233.EFB42A0713@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 12:52:33 -0400 (EDT) Content-Transfer-Encoding: 7bit Julian, Thank you for your comments. Personally I'm working on the implementation of XML Schema. So, I'm talking more from the XML Schema perspective. Sorry for the bias. See my response below. -Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" ; Sent: Wednesday, October 15, 2003 1:42 AM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > > Sent: Tuesday, October 14, 2003 10:24 PM > > To: w3c-dist-auth@w3.org > > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > > > > > Hi, > > > > I'm new on this mailing list. So, forgive me if my questions were > > brought up before. > > Sure. > > > For security consideration, external XML entities are considered > > vulnerable to denial of service attack. So, I agree that WebDAV > > messages MUST not be validated using DTDs. Or it can be > > optional, if an implementation opt to do that. > > I think we need to be precise here. As far as I understand, the XML > recommendation does only define one very specific form of validation, and it > is based on the document/message declaring it's document type. > > Exactly this kind of validation is completely useless in XML based > protocols: it's completely irrelevant whether a document conforms to a DTD > that the *sender* provides. It would be only interesting to validate against > the DTD expected by the *recipient*. Doing the latter of course is > completely up to the recipient -- however it must be aware of the fact that > the DTD (fragments) in RFC2518 and related specs only describe part of the > constraints, and that a recipient MUST accept way more message variations as > the DTDs (per XML rec) allow. Yes, it matters only on how recipients use the DTD, or possible other schemas, to validate the message. RFC 2518 didn't dictate whether the recipient should use DTD, XML Schema, or Relax NG to validate the XML message. Right? > > > Anyone else have ever thought of using XML Schema, instead of > > DTD, to validate WebDAV messages? Any security concerns? > > If the schema or the reference to the schema is provided by the sender of > the message, I think the same concerns apply. If the schema is hardwired > into the recipient, none apply. If the schema is provided by the sender, say using SchemaLocation, it should be ignored by the recipient from the same security consideration. XML Schema spec says SchemaLocation only provides a hint, an implementation can rightfully ignore the information provided by the sender. In this case, I was thinking of hardwiring the schema to the recipient. > > On the other hand, I don't see any big advantage in using XML Schema as > replacement in WebDAV specs. It only solves one particular problem (DTDs > ignorance of namespaces), but is a lot harder to read. If we really decide > not to use DTD syntax anymore, we should consider a schema language that can > *really* express the DAV extensibility rules, and that's easy to read by the > (human) readers of the spec. As far as I understand, Relax NG (compact > syntax) would qualify. I'm not a big fan of XML Schema either. But, I think XML Schema WG is trying hard to correct some of the problems in its original design. However, managing namespaces is a big concern. Current approach for new extensions is just extending DAV: namespace. This introduces a versioning control issue. Currently, DAV extensions are using XML structures in a limited way. To handle these structures, I think, XML Schema can provide good support for its constraint specification and address extensibility by using its "extension" or similar mechanisms. What I'm trying to say here is: TRUE, the whole XML Schema spec. is hard to read; but, if you carefully enough to use a subset of its features, it's still a good tool for message validation. Lastly, XML Schema has been widely supported by most software vendors. > > You may also want to check out RFC3470 ("Guidelines for the Use of > Extensible Markup Language (XML) within IETF Protocols", section 4.7. > Sure! > > Will appreciate your inputs! > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 15 13:14: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 NAA10845 for ; Wed, 15 Oct 2003 13:14:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E2469A0B66; Wed, 15 Oct 2003 13:14:09 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A5333A0B66 for ; Wed, 15 Oct 2003 13:14:07 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 4136B13B29; Wed, 15 Oct 2003 13:14:07 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id AE7F013AFF for ; Wed, 15 Oct 2003 13:14:06 -0400 (EDT) Received: (qmail 14144 invoked by uid 65534); 15 Oct 2003 17:13:56 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp026) with SMTP; 15 Oct 2003 19:13:56 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , Date: Wed, 15 Oct 2003 19:13:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <0bea01c3933c$985c1c00$c5b42382@us.oracle.com> Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEBGINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7992 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015171409.E2469A0B66@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 13:14:09 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Wednesday, October 15, 2003 6:52 PM > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > Julian, > > Thank you for your comments. > > Personally I'm working on the implementation of XML Schema. So, I'm > talking more from the XML Schema perspective. Sorry for the bias. See > my response below. Ok :-) > Yes, it matters only on how recipients use the DTD, or possible other schemas, > to validate the message. RFC 2518 didn't dictate whether the recipient should > use DTD, XML Schema, or Relax NG to validate the XML message. Right? Right. And it doesn't need to. The recipient can of course validate the message with any technology it feels adequate. To be adequate, it must somehow be able to express the special WebDAV extensibility rules. > If the schema is provided by the sender, say using SchemaLocation, it should > be ignored by the recipient from the same security consideration. XML Schema > spec says SchemaLocation only provides a hint, an implementation can > rightfully ignore the information provided by the sender. Correct. > In this case, I was thinking of hardwiring the schema to the recipient. That's fine. > I'm not a big fan of XML Schema either. But, I think XML Schema WG is > trying hard to correct some of the problems in its original design. However, > managing namespaces is a big concern. Current approach for new extensions > is just extending DAV: namespace. This introduces a versioning control > issue. Such as...? Fact is, one of the most successful XML applications -- XSLT -- uses *exactly* the same extensibility mechanism as WebDAV. If a schema language isn't able to express this kind of extensibility mechanism, that's unfortunate but it doesn't necessarily mean that the mechanism itself is flawed. I don't want to change WebDAV. In fact, we can't change WebDAV unless we go back to "proposed standard", and it's very unlikely that at this point of time, we'd get big players such as Microsoft to update their code. So what this issue is about is to *keep* the current extensibility rules while considering a better (hopefully formal) way to express them in the spec. DTDs can't do that well, nor can XML Schema. Relax NG may be able to do it. > Currently, DAV extensions are using XML structures in a limited way. > To handle these structures, I think, XML Schema can provide good > support for its constraint specification and address > extensibility by using > its "extension" or similar mechanisms. What I'm trying to say here is: > TRUE, the whole XML Schema spec. is hard to read; but, if you carefully > enough to use a subset of its features, it's still a good tool for message > validation. OK, so *how* do you express the following rules in XML Schema? - in addition to the specified child elements, *any* other element is allowed (at any position!), unless it's specified in RFC2518, - arbitrary properties are allowed - ordering is irrelevant As far as I understand, XML Schema can't do that (as the extensibility rules explicitly allow new child elements from the DAV: namespace). > Lastly, XML Schema has been widely supported by most software > vendors. I don't want to see another xml-dev permathread migrating here. We just need the schema language for the *formal notation*. It's completelely irrelevant here whether it is or will be implemented. What *is* relevant is whether we can find a notation that is better suited for writing the spec. I seriously doubt that XML Schema can be a candidate (if only for it's verboseness). > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 14:05: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 OAA13395 for ; Wed, 15 Oct 2003 14:05:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 65FB7A0665; Wed, 15 Oct 2003 14:05:51 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id ED3B1A0665 for ; Wed, 15 Oct 2003 14:05:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 99D9013B47; Wed, 15 Oct 2003 14:05:48 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by dr-nick.w3.org (Postfix) with ESMTP id 610BD13489 for ; Wed, 15 Oct 2003 14:05:48 -0400 (EDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9FI5inb032166 for ; Wed, 15 Oct 2003 11:05:47 -0700 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 h9FI5h403172 for ; Wed, 15 Oct 2003 12:05:43 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9FI5g403141 for ; Wed, 15 Oct 2003 12:05:42 -0600 (MDT) Message-ID: <0c2101c39346$d18b31a0$c5b42382@us.oracle.com> From: "Stanley Guan" To: References: Date: Wed, 15 Oct 2003 11:04:46 -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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/0c2101c39346$d18b31a0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7993 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015180551.65FB7A0665@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 14:05:51 -0400 (EDT) Content-Transfer-Encoding: 7bit Julian, If you're just looking for a schema language for the *formal notation*, then any choice will be fine with me :-). Let me try my best for these questions: > OK, so *how* do you express the following rules in XML Schema? > > - in addition to the specified child elements, *any* other element is > allowed (at any position!), unless it's specified in RFC2518, I think, what you need here is specified in a "choice" component. A question here: if the server claims that it only supports "versioning", but not "acl", is it an error if the user sends a request to find the "DAV:acl" property? > > - arbitrary properties are allowed I think, you can collect all server supported DAV: properties in a single complexType using "choice" component. Then, using "extension" component to extend different capabilities into the final set. > > - ordering is irrelevant "choice" is the best candidate. "all" is somewhat limited. Best, Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" ; Sent: Wednesday, October 15, 2003 10:13 AM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > > Sent: Wednesday, October 15, 2003 6:52 PM > > To: w3c-dist-auth@w3.org > > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > > > > > Julian, > > > > Thank you for your comments. > > > > Personally I'm working on the implementation of XML Schema. So, I'm > > talking more from the XML Schema perspective. Sorry for the bias. See > > my response below. > > Ok :-) > > > > Yes, it matters only on how recipients use the DTD, or possible other > schemas, > > to validate the message. RFC 2518 didn't dictate whether the recipient > should > > use DTD, XML Schema, or Relax NG to validate the XML message. Right? > > Right. And it doesn't need to. The recipient can of course validate the > message with any technology it feels adequate. To be adequate, it must > somehow be able to express the special WebDAV extensibility rules. > > > If the schema is provided by the sender, say using SchemaLocation, it > should > > be ignored by the recipient from the same security consideration. XML > Schema > > spec says SchemaLocation only provides a hint, an implementation can > > rightfully ignore the information provided by the sender. > > Correct. > > > In this case, I was thinking of hardwiring the schema to the recipient. > > That's fine. > > > I'm not a big fan of XML Schema either. But, I think XML Schema WG is > > trying hard to correct some of the problems in its original design. > However, > > managing namespaces is a big concern. Current approach for new extensions > > is just extending DAV: namespace. This introduces a versioning control > > issue. > > Such as...? Fact is, one of the most successful XML applications -- XSLT -- > uses *exactly* the same extensibility mechanism as WebDAV. If a schema > language isn't able to express this kind of extensibility mechanism, that's > unfortunate but it doesn't necessarily mean that the mechanism itself is > flawed. > > I don't want to change WebDAV. In fact, we can't change WebDAV unless we go > back to "proposed standard", and it's very unlikely that at this point of > time, we'd get big players such as Microsoft to update their code. > > So what this issue is about is to *keep* the current extensibility rules > while considering a better (hopefully formal) way to express them in the > spec. DTDs can't do that well, nor can XML Schema. Relax NG may be able to > do it. > > > Currently, DAV extensions are using XML structures in a limited way. > > To handle these structures, I think, XML Schema can provide good > > support for its constraint specification and address > > extensibility by using > > its "extension" or similar mechanisms. What I'm trying to say here is: > > TRUE, the whole XML Schema spec. is hard to read; but, if you carefully > > enough to use a subset of its features, it's still a good tool for message > > validation. > > OK, so *how* do you express the following rules in XML Schema? > > - in addition to the specified child elements, *any* other element is > allowed (at any position!), unless it's specified in RFC2518, > > - arbitrary properties are allowed > > - ordering is irrelevant > > As far as I understand, XML Schema can't do that (as the extensibility rules > explicitly allow new child elements from the DAV: namespace). > > > Lastly, XML Schema has been widely supported by most software > > vendors. > > I don't want to see another xml-dev permathread migrating here. We just need > the schema language for the *formal notation*. It's completelely irrelevant > here whether it is or will be implemented. > > What *is* relevant is whether we can find a notation that is better suited > for writing the spec. I seriously doubt that XML Schema can be a candidate > (if only for it's verboseness). > > > ... > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 15 14:33:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15007 for ; Wed, 15 Oct 2003 14:33:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7FA9EA06FF; Wed, 15 Oct 2003 14:33:11 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id DD69FA06FF for ; Wed, 15 Oct 2003 14:33:05 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C241113BCB; Wed, 15 Oct 2003 14:33:05 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 4F3C713861 for ; Wed, 15 Oct 2003 14:33:05 -0400 (EDT) Received: (qmail 28846 invoked by uid 65534); 15 Oct 2003 18:32:59 -0000 Received: from pD950C247.dip.t-dialin.net (HELO lisa) (217.80.194.71) by mail.gmx.net (mp009) with SMTP; 15 Oct 2003 20:32:59 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , Date: Wed, 15 Oct 2003 20:32:48 +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: <0c2101c39346$d18b31a0$c5b42382@us.oracle.com> Importance: Normal Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEBKINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015183311.7FA9EA06FF@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 14:33:11 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Wednesday, October 15, 2003 8:05 PM > To: w3c-dist-auth@w3.org > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > Julian, > > If you're just looking for a schema language for the *formal notation*, > then any choice will be fine with me :-). > > Let me try my best for these questions: > > > OK, so *how* do you express the following rules in XML Schema? > > > > - in addition to the specified child elements, *any* other element is > > allowed (at any position!), unless it's specified in RFC2518, > > I think, what you need here is > > specified in a "choice" component. Last time was dicussed I was told that this will not allow new extension elements from the DAV: namespace. > A question here: if the server claims that it only supports "versioning", > but not "acl", is it an error if the user sends a request to find the > "DAV:acl" property? No. > > - arbitrary properties are allowed > > I think, you can collect all server supported DAV: properties in > a single complexType using "choice" component. Then, using > "extension" component to extend different capabilities into the > final set. Sorry. I wanted to say "attributes". > > - ordering is irrelevant > > "choice" is the best candidate. "all" is somewhat limited. Thanks, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 16:42: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 QAA22755 for ; Wed, 15 Oct 2003 16:42:32 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 534EEA105E; Wed, 15 Oct 2003 16:42:26 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4FF24A105E for ; Wed, 15 Oct 2003 16:42:24 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 24AA913713; Wed, 15 Oct 2003 16:42:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (Postfix) with ESMTP id CAFE313640 for ; Wed, 15 Oct 2003 16:42:23 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9FKgIqi028169; Wed, 15 Oct 2003 13:42:18 -0700 (PDT) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9FKgH517000; Wed, 15 Oct 2003 14:42:17 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9FKgE516921; Wed, 15 Oct 2003 14:42:14 -0600 (MDT) Message-ID: <0c5501c3935c$ad81dff0$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Julian Reschke" , References: Date: Wed, 15 Oct 2003 13:41:14 -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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/0c5501c3935c$ad81dff0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015204226.534EEA105E@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 16:42:26 -0400 (EDT) Content-Transfer-Encoding: 7bit Julian, See my comments inline! Thx, -Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" ; Sent: Wednesday, October 15, 2003 11:32 AM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > > Sent: Wednesday, October 15, 2003 8:05 PM > > To: w3c-dist-auth@w3.org > > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > > > > > Julian, > > > > If you're just looking for a schema language for the *formal notation*, > > then any choice will be fine with me :-). > > > > Let me try my best for these questions: > > > > > OK, so *how* do you express the following rules in XML Schema? > > > > > > - in addition to the specified child elements, *any* other element is > > > allowed (at any position!), unless it's specified in RFC2518, > > > > I think, what you need here is > > > > specified in a "choice" component. > > Last time was dicussed I was told that this will not allow new extension > elements from the DAV: namespace. True. But, new DAV extension elements should be explicitly listed in the "choice" component. So, any bogus element in DAV: namespace can be caught. > > > A question here: if the server claims that it only supports "versioning", > > but not "acl", is it an error if the user sends a request to find the > > "DAV:acl" property? > > No. > > > > - arbitrary properties are allowed > > > > I think, you can collect all server supported DAV: properties in > > a single complexType using "choice" component. Then, using > > "extension" component to extend different capabilities into the > > final set. > > Sorry. I wanted to say "attributes". I thought we want to be loose on what can be allowed at element level. Within each element, don't we want all attributes to be explicitly spelt out? Why do we need arbitrary attributes to be allowed on any specific DAV: element? If elements belong to the following category: , then any arbitrary attributes can be allowed in them. > > > > - ordering is irrelevant > > > > "choice" is the best candidate. "all" is somewhat limited. > > Thanks, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 15 17:50:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25213 for ; Wed, 15 Oct 2003 17:50:47 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0E1EDA078A; Wed, 15 Oct 2003 17:50:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 21127A078A for ; Wed, 15 Oct 2003 17:50:52 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D73FF13802; Wed, 15 Oct 2003 17:50:51 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail15.atl.registeredsite.com (mail15.atl.registeredsite.com [64.224.219.99]) by dr-nick.w3.org (Postfix) with ESMTP id B08F813498 for ; Wed, 15 Oct 2003 17:50:51 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail15.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9FLomFq000711; Wed, 15 Oct 2003 17:50:48 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id OAA19845; Wed, 15 Oct 2003 14:50:46 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Wed, 15 Oct 2003 14:50:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAIEGMDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7996 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015215054.0E1EDA078A@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 17:50:54 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Hi Julian, 1. Yes, I understand that this was spun off of a different question. I = came around to the 24.2 proposal because I started looking at bis-04 to = get up to speed on what new wordings there might be on DTD and = XML-related topics. =20 1.1 I propose to keep the proposal of DTD approach for 24.2 separate = from the one about in-line use of markup declarations in the 2518bis's = descriptions of the DAV use of XML. 1.2 Probably the thing to do is to build such a DTD, play with it, and = see if it is worth including in 24.2 (and also at some well-known URL = where it will stay). [Is the W3C support of WebDAV such that we could = get space on the W3C server, or would ietf.org be more appropriate? Or = webdav.org?] - - - - - - - - -=09 2. I do want to point out an over-simplification that keeps creeping = into this discussion. =20 2.1 -required processing. =20 When a declaration is present, even a non-validating = processor must do a lot of work. It is definitely not the same as just = parsing through the declaration and going on one's merry way. There is = the small matter of entity declarations and whether or not the receiving = processor will read external sources for parameter entities and external = XML entities (it being the receiver's option to do so). =20 And then there are attributes to be concerned about. =20 =09 Also, the standalone attribute of the XML declaration can influence the = non-validating behavior, although it doesn't reduce the amount of work = that must be done. =20 There are some XML 1.0 errata that pertain to these discussions and to = WebDAV use of XML, : E61, E60, = E58, E57, E55, E49, E48, E47, E45, E43, E42, E41, E39, E38, E36, E29, = E25, E23, E22, E21, E20, E19, E16, E15, E14, E12, E8, and E7. I have = allowed for these in my comments. A few pertain to non-validating = behavior, attribute processing, etc. There are also a number of others = regarding Unicode and the correct specifications to use that I have = omitted from the above list. 2.2 Entity References and Recursion. =20 The issue of recursive expansion of entity references is a red herring. = Recursion, directly or indirectly, in processing a parsed entity = reference is a violation of *well-formedness* and it is a bug for a = processor not to reject its occurrence (since all ill-formed XML must be = rejected by an XML processor). This is clear in [REC-XML] section 4.1 = Character and Entity References, = . Look at the syntax on = Entity References and the notes entitled [WFC: No Recursion] for the two = cases. (A non-validating processor can fail to notice a case of = recursion that a validating processor might detect, but that's only if = the recursion depends on an external entity that is not read by the = non-validating processor.) There are some technical nuances around when an entity reference is a = parsed entity reference, but that doesn't seem to figure here. The = point is that all cases of recursive expansion are prohibited. It is still trivially possible to send a short XML document with = internal DTD that results in a gigantic expansion, as noted in the = discussion of security considerations for XML Media types = (). Extend this pattern to, say, = cx32, and open the document in Internet Explorer: =20 ] > =20 &cx7; =20 =20 2.3 Attribute Declarations and Default Values. Any attribute declaration that is read by a non-validating processor = must be honored. This applies to normalization of attribute values = based on their type. If the attribute has a default value, the = processor must supply that default value when the attribute is not = explicitly present in the start tag of the element for which it is = defined. Although it is not considered good practice to rely on default values = and proper normalization for attributes whose declarations might *not* = be read by a non-validating processor, any attribute declarations in an = internal DTD must be read. The idea is that an XML processor delivers a processed stream of = elements as if every defaulted attribute had been explicitly supplied, = every recognized attribute is normalized as appropriate. All parsed = entities have their spacing rules applied, with internal entity = references resolved. The DTD is usually not delivered to the = application. The XML processor makes it unnecessary for the application = to have to deal with the DTD under normal conditions. You can create an XML document with declared attributes and default = values and observe this expansion by opening the XML document in = Internet Explorer 6.0. (There's an inconsistency in some defaultings of = xmlns attributes, but other cases work.) [I am omitting all nuances related to what are called Notations, and how = attributes of type ENTITY and ENTITIES work for non-validating = processors. That's not less to deal with.] -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 15, 2003 03:06 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Dennis, I appreciate the time you're spending thinking about this subject. The question that started this thread was what to do with the DTD notation = that is used in current WebDAV specs and that disappeared in RFC2518bis. My position is that we should keep it and make sure that the spec clearly = says what it means for developers. Other comments inline... [ ... ] > Dealing with a server that provides Document Type Declarations in > responses is something I don't want to think about. In practice, > that borders on a hostile act, since it imposes processing on the > client and has the interpretation of the response be > unpredictable in some cases. It raises the bar for universal > client processors. Nope. The spec should clearly state that messages must be processed in non-validating mode. In this case, it's really irrelevant whether a = DOCTYPE is present (except for the well-known recursive entity substition = problem). [ ... ] Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 15 18:40: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 SAA28325 for ; Wed, 15 Oct 2003 18:40:53 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6ADA7A0FEA; Wed, 15 Oct 2003 18:41:01 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id ABD11A0FEA for ; Wed, 15 Oct 2003 18:40:59 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 82A2F13AA3; Wed, 15 Oct 2003 18:40:59 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (Postfix) with ESMTP id 03665137BE for ; Wed, 15 Oct 2003 18:40:59 -0400 (EDT) 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 h9FMemP14777 for ; Wed, 15 Oct 2003 15:40:48 -0700 (PDT) Message-ID: <3F8DCCF0.7090305@cse.ucsc.edu> Date: Wed, 15 Oct 2003 15:40:48 -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="------------000201070904060908030105" Subject: Re: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/3F8DCCF0.7090305@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7997 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015224101.6ADA7A0FEA@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 18:41:01 -0400 (EDT) --------------000201070904060908030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree, let's add this to 2518bis - the proposed mechnism is simple and easy for developers to understand. Elias Geoffrey M Clemm wrote: > > I support this addition to RFC2518bis. > > I believe it is a key mechanism needed for servers to properly support > the various current (and future) WebDAV extensions. > > Cheers, > Geoff > > Julian wrote on 10/14/2003 09:53:30 AM: > > > > > > OK, > > > > > > so we probably should put it onto the issues list (so that it > doesn't get > > lost). > > > > Here's a proposal for the issues list: > > > > > > Issue DAV_REQUEST_HEADER > > > > RFC 2518 provides a mechanism (the "DAV" response header) for a > server to > > indicate to a client that it supports a specific WebDAV option (e.g. > "1", > > "2", "version-control", etc.), but there is no complementary > mechanism for a > > client to indicate to a server that it understands a specific WebDAV > option. > > This becomes an issue when a WebDAV extension (or revision) needs to > change > > response formats in a way that possibly break existing clients. > Detecting > > client features based on a single, well-defined request header will work > > better than (for instance) relying on custom headers (specified by each > > extension) or "User-Agent". > > > > Suggested resolution: allow the use of the "DAV" header as a request > header, > > with the same set of values that are defined for the "DAV" > > response header. > > > > > > Regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --------------000201070904060908030105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree, let's add this to 2518bis - the proposed mechnism is simple and easy for developers to understand.


Elias


Geoffrey M Clemm wrote:

I support this addition to RFC2518bis.

I believe it is a key mechanism needed for servers to properly support
the various current (and future) WebDAV extensions.

Cheers,
Geoff

Julian wrote on 10/14/2003 09:53:30 AM:

>
> > OK,
> >
> > so we probably should put it onto the issues list (so that it doesn't get
> lost).
>
> Here's a proposal for the issues list:
>
>
> Issue DAV_REQUEST_HEADER
>
> RFC 2518 provides a mechanism (the "DAV" response header) for a server to
> indicate to a client that it supports a specific WebDAV option (e.g. "1",
> "2", "version-control", etc.), but there is no complementary mechanism for a
> client to indicate to a server that it understands a specific WebDAV option.
> This becomes an issue when a WebDAV extension (or revision) needs to change
> response formats in a way that possibly break existing clients. Detecting
> client features based on a single, well-defined request header will work
> better than (for instance) relying on custom headers (specified by each
> extension) or "User-Agent".
>
> Suggested resolution: allow the use of the "DAV" header as a request header,
> with the same set of values that are defined for the "DAV"
> response header.
>
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

--------------000201070904060908030105-- From w3c-dist-auth-request@w3.org Wed Oct 15 18:57: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 SAA28855 for ; Wed, 15 Oct 2003 18:57:20 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A7614A0537; Wed, 15 Oct 2003 18:57:28 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EE658A0537 for ; Wed, 15 Oct 2003 18:57:25 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A919C1372D; Wed, 15 Oct 2003 18:57:25 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from svea0003.statestreet.com (svea0003.statestreet.com [192.250.112.146]) by dr-nick.w3.org (Postfix) with ESMTP id 9629613692 for ; Wed, 15 Oct 2003 18:57:25 -0400 (EDT) Received: from svea0003.statestreet.com (localhost [127.0.0.1]) by svea0003.statestreet.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h9FMvOl15829 for ; Wed, 15 Oct 2003 18:57:24 -0400 (EDT) Received: from waller.ssga.statestreet.com (waller.ssga.statestr.com [147.141.15.163]) by svea0003.statestreet.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h9FMvNl15786 for ; Wed, 15 Oct 2003 18:57:23 -0400 (EDT) From: Joe_Kennedy@ssga.com To: w3c-dist-auth@w3.org Message-ID: Date: Wed, 15 Oct 2003 18:57:05 -0400 X-MIMETrack: Serialize by Router on SSGA_GateWay/BOSTON/SSGA(Release 5.0.8 |June 18, 2001) at 10/15/2003 06:57:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Joe Kennedy/USA/StateStreet is out of the office. X-Archived-At: http://www.w3.org/mid/OF5230AA07.40F74932-ON85256DC0.007E13BA-85256DC0.007E13BA@ssga.statestreet.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7998 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015225728.A7614A0537@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 18:57:28 -0400 (EDT) I will be out of the office starting 10/15/2003 and will not return until 10/20/2003. I will be out of the office from October 15th - 17th. Please contact Bruce Letendre with urgent matters. From w3c-dist-auth-request@w3.org Wed Oct 15 19:01:24 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28973 for ; Wed, 15 Oct 2003 19:01:23 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E93D0A05CB; Wed, 15 Oct 2003 19:01:30 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3C733A05CB for ; Wed, 15 Oct 2003 19:01:30 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id E4CFF137FD; Wed, 15 Oct 2003 19:01:29 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail12.atl.registeredsite.com (mail12.atl.registeredsite.com [64.224.219.86]) by dr-nick.w3.org (Postfix) with ESMTP id C6AFB1372D for ; Wed, 15 Oct 2003 19:01:29 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail12.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9FM1T4W028557; Wed, 15 Oct 2003 18:01:29 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id QAA24836; Wed, 15 Oct 2003 16:01:26 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Stanley Guan" , "Julian Reschke" , Date: Wed, 15 Oct 2003 16:01:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: <0c5501c3935c$ad81dff0$c5b42382@us.oracle.com> Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEHCDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7999 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031015230130.E93D0A05CB@frink.w3.org> Resent-Date: Wed, 15 Oct 2003 19:01:30 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Hi Julian and Stanley, I have been watching your discussion with interest. I concur that XML = Schema should work just nifty for DAV, and the one case of concern to me = can be handled, with a little care. Let me summarize: 1. XML Schema is able to assess schema validity for documents that have = arbitrary elements (and attributes) from other namespaces. I see there = is an open question on the occurrence of arbitrary attributes on DAV = elements and that needs to be looked at separately (e.g., how to use = attributes from the global attribute namespace versus ad hoc attributes = piled onto the DAV element and the element-local namespace -- and = whether the second should be ever allowed). 2. I agree that XML Schema is not an useful way to specify DAV elements = and their content models in the body of the specification. However, = having and using XML Schemas for DAV XML documents is still an useful = option. 3. The case of concern for me is that XML Schema assessment can be done = without doing anything to the document, as Stanley noticed. =20 3.1 There is no requirement to provide an xsi:schemaLocation list, and = there is also no requirement that the XML processor use it. It's all = hinting, as I recall. 3.2 However, XML Schemas are targeted to namespaces (which is how the = whole document can be assessed for schema conformity even when the = document is drawn from many namespaces). Since DAV does not use = immutable namespaces, but uses an extensible namespace with a single = namespace URI (DAV:), this means the schema definition has to be updated = when new official elements are added. =20 3.3 The only wrinkle here is that XML processors that do schema = assessment tend to cache the XML Schema definitions by namespace URI. = So when the DAV namespace is given new local names, any processor = prepared to accept those and provide appropriate schema assessment must = update its cache with the new schema definition. (This is another = reason that namespace versioning is useful, but ... that's life [;<). = [I think my schema/DTD-validating XML editor requires me to flush the = whole cache to do that, and that's the price I pay for being so picky.] The datatype model of XML Schema seems to be gaining popularity for = establishing and expressing the (lexical) datatype of simple-element = content too. So there is already a source of data-type tags (and new = schema-defined ones) that can be supplied as attributes of property = elements conveyed in DAV listings [;<). -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan Sent: Wednesday, October 15, 2003 13:41 To: Julian Reschke; w3c-dist-auth@w3.org Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Julian, See my comments inline! Thx, -Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" ; Sent: Wednesday, October 15, 2003 11:32 AM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) [ ... ] > > Last time was dicussed I was told that this will not allow new = extension > elements from the DAV: namespace. True. But, new DAV extension elements should be explicitly listed in the "choice" component. So, any bogus element in DAV: namespace can be caught. [ ... ] > > > > - arbitrary properties are allowed > > > > I think, you can collect all server supported DAV: properties in > > a single complexType using "choice" component. Then, using > > "extension" component to extend different capabilities into the > > final set. > > Sorry. I wanted to say "attributes". I thought we want to be loose on what can be allowed at element level. Within each element, don't we want all attributes to be explicitly spelt out? Why do we need arbitrary attributes to be allowed on any specific DAV: element? If elements belong to the following category: , then any arbitrary attributes can be allowed in them. [ ... ] From w3c-dist-auth-request@w3.org Thu Oct 16 03:31: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 DAA23003 for ; Thu, 16 Oct 2003 03:31:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B5D6AA050B; Thu, 16 Oct 2003 03:31:52 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id F365CA0772 for ; Thu, 16 Oct 2003 03:31:43 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 115DE1392A; Thu, 16 Oct 2003 03:29:00 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 72DC113550 for ; Thu, 16 Oct 2003 03:28:59 -0400 (EDT) Received: (qmail 29150 invoked by uid 65534); 16 Oct 2003 07:28:50 -0000 Received: from pD950C261.dip.t-dialin.net (HELO lisa) (217.80.194.97) by mail.gmx.net (mp002) with SMTP; 16 Oct 2003 09:28:50 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , "Julian Reschke" , Date: Thu, 16 Oct 2003 09:28:35 +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: <0c5501c3935c$ad81dff0$c5b42382@us.oracle.com> Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDCINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8000 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016073152.B5D6AA050B@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 03:31:52 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Wednesday, October 15, 2003 10:41 PM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > Julian, > > See my comments inline! > > Thx, > > -Stanley > > ... > > > Last time was dicussed I was told that this will not allow new extension > > elements from the DAV: namespace. > > True. But, new DAV extension elements should be explicitly listed in > the "choice" component. So, any bogus element in DAV: namespace > can be caught. How does that help? If a recipient validates a message based on a RFC2518bis-based XML Schema, and draft-ietf-webdav-redirect-ref protocol extends a particular element, these messages will not be valid according to the Schema *without* modifying the schema. The point of extensibility is that old components continue to work with extended messages *without* modification. > I thought we want to be loose on what can be allowed at element > level. Within each element, don't we want all attributes to be > explicitly spelt out? Why do we need arbitrary attributes to be > allowed on any specific DAV: element? Because that's allowed now. > ... Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 16 03:32:06 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 DAA23024 for ; Thu, 16 Oct 2003 03:32:05 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C5B8BA0611; Thu, 16 Oct 2003 03:32:12 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E41DFA0611 for ; Thu, 16 Oct 2003 03:32:11 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B5FDE134E7; Thu, 16 Oct 2003 03:32:11 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 41CFF13468 for ; Thu, 16 Oct 2003 03:32:11 -0400 (EDT) Received: (qmail 13068 invoked by uid 65534); 16 Oct 2003 07:32:07 -0000 Received: from pD950C261.dip.t-dialin.net (HELO lisa) (217.80.194.97) by mail.gmx.net (mp002) with SMTP; 16 Oct 2003 09:32:07 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Stanley Guan" , "Julian Reschke" , Date: Thu, 16 Oct 2003 09:31:55 +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: Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEDDINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8001 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016073212.C5B8BA0611@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 03:32:12 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis, I think you're still missing a basic fact about WebDAV's extensibility: it is not centralized, nor linear. There is no common registry. Everybody can add extension elements anytime. Even if somebody would update that Schema anytime a new RFC (or Internet Draft) comes out out, there will be a lot of legal WebDAV messages that won't validate against that schema. 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 Dennis E. Hamilton > Sent: Thursday, October 16, 2003 1:01 AM > To: Stanley Guan; Julian Reschke; w3c-dist-auth@w3.org > Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > Hi Julian and Stanley, > > I have been watching your discussion with interest. I concur > that XML Schema should work just nifty for DAV, and the one case > of concern to me can be handled, with a little care. > > Let me summarize: > > 1. XML Schema is able to assess schema validity for documents > that have arbitrary elements (and attributes) from other > namespaces. I see there is an open question on the occurrence of > arbitrary attributes on DAV elements and that needs to be looked > at separately (e.g., how to use attributes from the global > attribute namespace versus ad hoc attributes piled onto the DAV > element and the element-local namespace -- and whether the second > should be ever allowed). > > 2. I agree that XML Schema is not an useful way to specify DAV > elements and their content models in the body of the > specification. However, having and using XML Schemas for DAV XML > documents is still an useful option. > > 3. The case of concern for me is that XML Schema assessment > can be done without doing anything to the document, as Stanley noticed. > > 3.1 There is no requirement to provide an xsi:schemaLocation > list, and there is also no requirement that the XML processor use > it. It's all hinting, as I recall. > > 3.2 However, XML Schemas are targeted to namespaces (which is > how the whole document can be assessed for schema conformity even > when the document is drawn from many namespaces). Since DAV does > not use immutable namespaces, but uses an extensible namespace > with a single namespace URI (DAV:), this means the schema > definition has to be updated when new official elements are added. > > 3.3 The only wrinkle here is that XML processors that do schema > assessment tend to cache the XML Schema definitions by namespace > URI. So when the DAV namespace is given new local names, any > processor prepared to accept those and provide appropriate schema > assessment must update its cache with the new schema definition. > (This is another reason that namespace versioning is useful, but > ... that's life [;<). [I think my schema/DTD-validating XML > editor requires me to flush the whole cache to do that, and > that's the price I pay for being so picky.] > > The datatype model of XML Schema seems to be gaining popularity > for establishing and expressing the (lexical) datatype of > simple-element content too. So there is already a source of > data-type tags (and new schema-defined ones) that can be supplied > as attributes of property elements conveyed in DAV listings [;<). > > -- Dennis > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Wednesday, October 15, 2003 13:41 > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > Julian, > > See my comments inline! > > Thx, > > -Stanley > > ----- Original Message ----- > From: "Julian Reschke" > To: "Stanley Guan" ; > Sent: Wednesday, October 15, 2003 11:32 AM > Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > [ ... ] > > > > > Last time was dicussed I was told that this will not allow new extension > > elements from the DAV: namespace. > > True. But, new DAV extension elements should be explicitly listed in > the "choice" component. So, any bogus element in DAV: namespace > can be caught. > > [ ... ] > > > > > > - arbitrary properties are allowed > > > > > > I think, you can collect all server supported DAV: properties in > > > a single complexType using "choice" component. Then, using > > > "extension" component to extend different capabilities into the > > > final set. > > > > Sorry. I wanted to say "attributes". > > I thought we want to be loose on what can be allowed at element > level. Within each element, don't we want all attributes to be > explicitly spelt out? Why do we need arbitrary attributes to be > allowed on any specific DAV: element? > > If elements belong to the following category: > , > then any arbitrary attributes can be allowed in them. > > [ ... ] > > > From w3c-dist-auth-request@w3.org Thu Oct 16 11:57: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 LAA07993 for ; Thu, 16 Oct 2003 11:57:51 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0CE05A0522; Thu, 16 Oct 2003 11:57:59 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B7059A050D for ; Thu, 16 Oct 2003 11:57:56 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 71D9E13675; Thu, 16 Oct 2003 11:57:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id 39F0413639 for ; Thu, 16 Oct 2003 11:57:56 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GFvuWs002028 for ; Thu, 16 Oct 2003 08:57:56 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GFvtP15562 for ; Thu, 16 Oct 2003 09:57:55 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9GFvlP15284 for ; Thu, 16 Oct 2003 09:57:47 -0600 (MDT) Message-ID: <0c8101c393fe$171dc8b0$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Thu, 16 Oct 2003 08:56:41 -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: Fw: Fw: rfc2518bis DAV DTD X-Archived-At: http://www.w3.org/mid/0c8101c393fe$171dc8b0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8002 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016155759.0CE05A0522@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 11:57:59 -0400 (EDT) Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Henry S. Thompson" To: "Stanley Guan" Sent: Wednesday, October 15, 2003 10:16 PM Subject: Re: Fw: rfc2518bis DAV DTD > Would you send the following on my behalf, please? > > Regarding your discussion about using W3C XML Schema to express the > DAV extensibility rules, I agree with the position which says that > unconstrained interleaving of names from any namespace excluding > only those already defined by DAV is inexpressible. > > I would observe that it is perhaps misleading to describe this as an > extensibility mechanism, particularly in the context of comparison > with XSLT. XSLT has both an *extension* mechanism for stylesheets, > which is much more constrained than what you are talking about, and > which _can_ be described with W3C XML Schema, and a *versioning* > mechanism for the REC itself, which defines forward-compatible > processing. It's the latter you are discussing, not the former. > > ht > -- > Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh > Half-time member of W3C Team > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without it is forged spam] > From w3c-dist-auth-request@w3.org Thu Oct 16 12:48: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 MAA10579 for ; Thu, 16 Oct 2003 12:48:14 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1A929A0640; Thu, 16 Oct 2003 12:48:24 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4DEF5A0640 for ; Thu, 16 Oct 2003 12:48:22 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 18B88137AD; Thu, 16 Oct 2003 12:48:22 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id DBD17132EB for ; Thu, 16 Oct 2003 12:48:21 -0400 (EDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GGmKWs008205; Thu, 16 Oct 2003 09:48:20 -0700 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GGmIh29826; Thu, 16 Oct 2003 10:48:18 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9GGmGh29754; Thu, 16 Oct 2003 10:48:16 -0600 (MDT) Message-ID: <0cb101c39405$2324d6b0$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Julian Reschke" , References: Date: Thu, 16 Oct 2003 09:47:07 -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: Appropriate XML processing in extensibility consideration (Was rfc2518bis DAV DTD) X-Archived-At: http://www.w3.org/mid/0cb101c39405$2324d6b0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016164824.1A929A0640@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 12:48:24 -0400 (EDT) Content-Transfer-Encoding: 7bit Julian, I am getting more clear on what the true issues are. Thanks! However, it seems to me that there are different options to resolve the extensibility issue and WG seems to choose the following approach: 1. For client implementations, ignore XML elements they do not understand. "Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand." 2. For server implementations, ignore any unknown XML element and all its children encountered. "All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language." As told by you, this rule will be extended to include any unknown XML attribute. Right? To summarize what I understand so far: 1. WG is seeking a formal notation to describe the XML components contained in any message body that need to be minimally understood by all DAV-compliant (including DAV's extensions) implementations. Any bogus (or should be called "alien") XML elements (or attributes) will be simply ignored without even raising a flag. So, to avoid hackers using this feature to launch denial-of-access attacks is to limit the size of XML data allowed in the request body. Additionally, there is no need for any implementation to use any schema to check whether received XML data is valid or not. What it needs to do is just walking through the XML elements and check if it is what the implementation can understand or not. If yes, take action; otherwise, ignore it. 2. The DAV response header (and new proposed DAV request header is just informational and has no constraining power. Am I right? Thx, -Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" ; "Julian Reschke" ; Sent: Thursday, October 16, 2003 12:28 AM Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > > Sent: Wednesday, October 15, 2003 10:41 PM > > To: Julian Reschke; w3c-dist-auth@w3.org > > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) > > > > > > > > Julian, > > > > See my comments inline! > > > > Thx, > > > > -Stanley > > > > ... > > > > > Last time was dicussed I was told that this will not allow new extension > > > elements from the DAV: namespace. > > > > True. But, new DAV extension elements should be explicitly listed in > > the "choice" component. So, any bogus element in DAV: namespace > > can be caught. > > How does that help? If a recipient validates a message based on a > RFC2518bis-based XML Schema, and draft-ietf-webdav-redirect-ref protocol > extends a particular element, these messages will not be valid according to > the Schema *without* modifying the schema. The point of extensibility is > that old components continue to work with extended messages *without* > modification. > > > I thought we want to be loose on what can be allowed at element > > level. Within each element, don't we want all attributes to be > > explicitly spelt out? Why do we need arbitrary attributes to be > > allowed on any specific DAV: element? > > Because that's allowed now. > > > ... > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Thu Oct 16 12:59:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10997 for ; Thu, 16 Oct 2003 12:59:24 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B495BA0C78; Thu, 16 Oct 2003 12:59:33 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A8BB8A0DA7 for ; Thu, 16 Oct 2003 12:59:30 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id CF96413C7B; Thu, 16 Oct 2003 12:58:09 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by dr-nick.w3.org (Postfix) with ESMTP id A0590135E4 for ; Thu, 16 Oct 2003 12:58:09 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GGw1nb026105; Thu, 16 Oct 2003 09:58:01 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GGvwP20586; Thu, 16 Oct 2003 10:57:58 -0600 (MDT) Received: from esedlar (dhcp-amer-vpn-gw2-east-141-144-82-7.vpn.oracle.com [141.144.82.7]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GGvsP20435; Thu, 16 Oct 2003 10:57:54 -0600 (MDT) Message-Id: <200310161657.h9GGvsP20435@rgmgw4.us.oracle.com> From: "Eric Sedlar" To: "'Stanley Guan'" Cc: , Date: Thu, 16 Oct 2003 09:57:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook, Build 11.0.4920 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <0c8101c393fe$171dc8b0$c5b42382@us.oracle.com> Thread-Index: AcOT/uPWiL1s6Fi/ROyLyMlMnOmnmwABwddQ Subject: RE: Fw: rfc2518bis DAV DTD X-Archived-At: http://www.w3.org/mid/200310161657.h9GGvsP20435@rgmgw4.us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016165933.B495BA0C78@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 12:59:33 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Stanley-- I raised this issue with Henry about 18 months back regarding the need = for a flavor of that basically says "match anything not otherwise declared in the content model". (Henry indicated that this requirement = had come up in other contexts and was under consideration.) The WebDAV WG decided at that point to stick with the existing DTD-based mechanism = rather than try to "upgrade" our formalism to XML Schema, until a future = version of XML Schema allowed such a declaration. While some schema processors like XML Spy allow something like: as the namespace attribute of the is not required, they also then = stop validating "a" and "b". This seems to be, strictly speaking, to be = illegal, as the Unique Particle Attribution requirement is being violated. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Stanley Guan > Sent: Thursday, October 16, 2003 8:57 AM > To: w3c-dist-auth@w3.org >=20 >=20 >=20 > ----- Original Message ----- > From: "Henry S. Thompson" > To: "Stanley Guan" > Sent: Wednesday, October 15, 2003 10:16 PM > Subject: Re: Fw: rfc2518bis DAV DTD >=20 >=20 > > Would you send the following on my behalf, please? > > > > Regarding your discussion about using W3C XML Schema to express = the > > DAV extensibility rules, I agree with the position which says that > > unconstrained interleaving of names from any namespace excluding > > only those already defined by DAV is inexpressible. > > > > I would observe that it is perhaps misleading to describe this as = an > > extensibility mechanism, particularly in the context of comparison > > with XSLT. XSLT has both an *extension* mechanism for = stylesheets, > > which is much more constrained than what you are talking about, = and > > which _can_ be described with W3C XML Schema, and a *versioning* > > mechanism for the REC itself, which defines forward-compatible > > processing. It's the latter you are discussing, not the former. > > > > ht > > -- > > Henry S. Thompson, HCRC Language Technology Group, University of > Edinburgh > > Half-time member of W3C Team > > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 = 650-4440 > > Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk > > URL: http://www.ltg.ed.ac.uk/~ht/ > > [mail really from me _always_ has this .sig -- mail without it is > forged > spam] > > From w3c-dist-auth-request@w3.org Thu Oct 16 15:51:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19918 for ; Thu, 16 Oct 2003 15:51:17 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E9897A058D; Thu, 16 Oct 2003 15:51:25 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EAC4FA058D for ; Thu, 16 Oct 2003 15:51:23 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B04A01346A; Thu, 16 Oct 2003 15:51:23 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 462F813366 for ; Thu, 16 Oct 2003 15:51:23 -0400 (EDT) Received: (qmail 4831 invoked by uid 65534); 16 Oct 2003 19:51:13 -0000 Received: from pD950C261.dip.t-dialin.net (HELO lisa) (217.80.194.97) by mail.gmx.net (mp021) with SMTP; 16 Oct 2003 21:51:13 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , "Julian Reschke" , Date: Thu, 16 Oct 2003 21:50:53 +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: <0cb101c39405$2324d6b0$c5b42382@us.oracle.com> Importance: Normal Subject: RE: Appropriate XML processing in extensibility consideration (Was rfc2518bis DAV DTD) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEELINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8005 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016195125.E9897A058D@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 15:51:25 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan > Sent: Thursday, October 16, 2003 6:47 PM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: Appropriate XML processing in extensibility consideration (Was > rfc2518bis DAV DTD) > > > > Julian, > > I am getting more clear on what the true issues are. Thanks! > > However, it seems to me that there are different options to resolve the > extensibility issue and WG seems to choose the following approach: > > 1. For client implementations, ignore XML elements they do not > understand. > > "Older clients will not break when they encounter extensions > because they will still have the data specified in the original > schema and will ignore elements they do not understand." Right. > 2. For server implementations, ignore any unknown XML > element and all its children encountered. > > "All DAV compliant resources MUST ignore any unknown > XML element and all its children encountered while processing > a DAV method that uses XML as its command language." > > As told by you, this rule will be extended to include any unknown > XML attribute. Right? Actually, that's not obvious. RFC2518 so far hasn't used attributes at all (except for some wording about xml:lang's role). But I'd assume that yes, extensibility applies to attributes as well. > To summarize what I understand so far: > > 1. WG is seeking a formal notation to describe the XML components > contained in any message body that need to be minimally understood > by all DAV-compliant (including DAV's extensions) implementations. > > Any bogus (or should be called "alien") XML elements (or attributes) > will be simply ignored without even raising a flag. So, to avoid > hackers using this feature to launch denial-of-access attacks is to limit > the size of XML data allowed in the request body. Right. Side note: it would be interesting to explore a mechanism for mandatory extensions (I think RFC2774 can help here). > Additionally, there is no need for any implementation to use any schema > to check whether received XML data is valid or not. What it needs > to do is just walking through the XML elements and check if it is what > the implementation can understand or not. If yes, take action; > otherwise, ignore it. Yes. However, "understanding" is a bit vague. For instance, PROPFIND uses: So for instance servers SHOULD reject requests such as ...... > 2. The DAV response header (and new proposed DAV request > header is just informational and has no constraining power. I wouldn't call it "just informational", but it doesn't affect the validaty of a message body. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 16 16:02:07 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 QAA20139 for ; Thu, 16 Oct 2003 16:02:07 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id E63F1A0501; Thu, 16 Oct 2003 16:02:14 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8A068A0501 for ; Thu, 16 Oct 2003 16:02:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3D9C013763; Thu, 16 Oct 2003 16:02:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail13.atl.registeredsite.com (mail13.atl.registeredsite.com [64.224.219.87]) by dr-nick.w3.org (Postfix) with ESMTP id 2059813492 for ; Thu, 16 Oct 2003 16:02:13 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail13.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9GK2ARF012952; Thu, 16 Oct 2003 16:02:10 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id NAA03641; Thu, 16 Oct 2003 13:02:09 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , "Stanley Guan" , Date: Thu, 16 Oct 2003 13:02:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAKEHNDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016200214.E63F1A0501@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 16:02:14 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Julian, With regard to schema-definition maintenance, I was referring only to = extension to the DAV: namespace, not the occurrence of ad hoc elements = from other namespaces. =20 With regard to schema assessment, I believe XML Schema has ways to allow = for occurrence of elements that are from namespaces other than the one = covered by a particular schema definition, if you can delimit where such = occurrences are allowed. (I have not checked this as carefully as = Stanley may have, however, and the response from Henry Thompson is not = clear to me on that point. I was relying on Stanley's illustration and = I did not go check the XML Namespace specs myself, nor review how lax = assessment is specified.) =20 I think I understand both how the DAV namespace is extensible (by = agreement) and how DAV XML elements are extensible (by ad hoc additions = having nothing to do with the DAV namespace). The only case that a reference XML schema definition for DAV would need = to be maintained is with regard to the first part. The second case is = up to the people who define/use ad hoc additions. [Because there is no = 100%, I see no reason to settle for 0%. It's not a binary question for = me.] Does that fit your understanding of DAV extensibility? =20 If you're telling me that anyone can invent an element and DAV-validly = introduce it as if under the DAV namespace, I will quietly pick up my = marbles and go figure out how to use SOAP (with attachments) and the Web = Services stack on HTTP to do Document Authoring and Versioning on the = web. (Such an expression of some level of DAV functionality is probably = valuable anyway.)=20 -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, October 16, 2003 00:32 To: dennis.hamilton@acm.org; Stanley Guan; Julian Reschke; w3c-dist-auth@w3.org Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) Dennis, I think you're still missing a basic fact about WebDAV's extensibility: = it is not centralized, nor linear. There is no common registry. Everybody = can add extension elements anytime. Even if somebody would update that = Schema anytime a new RFC (or Internet Draft) comes out out, there will be a lot = of legal WebDAV messages that won't validate against that schema. Julian -- From w3c-dist-auth-request@w3.org Thu Oct 16 16:20:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21922 for ; Thu, 16 Oct 2003 16:20:04 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 4B6AAA0867; Thu, 16 Oct 2003 16:19:21 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6C7A8A0867 for ; Thu, 16 Oct 2003 16:19:19 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id F33AC13973; Thu, 16 Oct 2003 16:19:18 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8C202137E5 for ; Thu, 16 Oct 2003 16:19:18 -0400 (EDT) Received: (qmail 22519 invoked by uid 65534); 16 Oct 2003 20:19:11 -0000 Received: from pD950C261.dip.t-dialin.net (HELO lisa) (217.80.194.97) by mail.gmx.net (mp026) with SMTP; 16 Oct 2003 22:19:11 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Stanley Guan" , Date: Thu, 16 Oct 2003 22:18:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEENINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016201921.4B6AAA0867@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 16:19:21 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Thursday, October 16, 2003 10:02 PM > To: Julian Reschke; Stanley Guan; w3c-dist-auth@w3.org > Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > Julian, > > With regard to schema-definition maintenance, I was referring > only to extension to the DAV: namespace, not the occurrence of ad > hoc elements from other namespaces. OK, yes, you can define a Schema that knows about all presently defined DAV elements. If you combine that with lax validation for non-DAV elements, and also take care of all other issues (such as ordering), you may be able to use that for validation. However, this validation immediately breaks once a new DAV protocol element is added. Thus, you can't use that Schema to validate messages in a production system that is meant to accept messages with not-yet defined extensions. > ... > > The only case that a reference XML schema definition for DAV > would need to be maintained is with regard to the first part. > The second case is up to the people who define/use ad hoc > additions. [Because there is no 100%, I see no reason to settle > for 0%. It's not a binary question for me.] Well, the validation process MUST accept all messages that are legal according to the spec. If it doesn't, what's the point in using it (unless just for debugging/education reasons)? > Does that fit your understanding of DAV extensibility? > > If you're telling me that anyone can invent an element and > DAV-validly introduce it as if under the DAV namespace, I will The WG says it's not allowed, but many companies do it. That's a fact we can't change in practice. > quietly pick up my marbles and go figure out how to use SOAP > (with attachments) and the Web Services stack on HTTP to do > Document Authoring and Versioning on the web. (Such an expression > of some level of DAV functionality is probably valuable anyway.) I'm not sure I follow. The way WebDAV is extensible IMHO doesn't cause any actual problems. Please be more specific. And before promoting SOAP in a HTTP-based WG, please make sure that you've read all related HTTP-with-extensions-vs-SOAP propaganda :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 16 16:59:06 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 QAA24652 for ; Thu, 16 Oct 2003 16:59:06 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6B7E5A0529; Thu, 16 Oct 2003 16:59:13 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 108E9A0529 for ; Thu, 16 Oct 2003 16:59:11 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id BD6EE1386A; Thu, 16 Oct 2003 16:59:10 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id 87B8813838 for ; Thu, 16 Oct 2003 16:59:10 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GKxAWs020551 for ; Thu, 16 Oct 2003 13:59:10 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GKx9P07442 for ; Thu, 16 Oct 2003 14:59:09 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9GKx8P07427 for ; Thu, 16 Oct 2003 14:59:08 -0600 (MDT) Message-ID: <0ddc01c39428$2a8f6870$c5b42382@us.oracle.com> From: "Stanley Guan" To: References: Date: Thu, 16 Oct 2003 13:57:52 -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: Easy-to-read deltas for rfc2518bis? X-Archived-At: http://www.w3.org/mid/0ddc01c39428$2a8f6870$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016205913.6B7E5A0529@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 16:59:13 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, Is there any delta history of the rfc2518bis? Is it possible to provide something similar to: http://www.w3.org/2001/05/xmlschema-errata.html regarding editorial efforts to highlight what's new and what's different from the original rfc2518 in rfc218bis? Thx, -Stanley From w3c-dist-auth-request@w3.org Thu Oct 16 17:41: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 RAA26203 for ; Thu, 16 Oct 2003 17:41:22 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 23A34A0691; Thu, 16 Oct 2003 17:41:31 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E73B5A092C for ; Thu, 16 Oct 2003 17:41:22 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A6C7C13C81; Thu, 16 Oct 2003 17:38:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (Postfix) with ESMTP id 954F513C71 for ; Thu, 16 Oct 2003 17:38:49 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9GLcnHM412470 for ; Thu, 16 Oct 2003 17:38:49 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9GLcmmD210338 for ; Thu, 16 Oct 2003 17:38:48 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 16 Oct 2003 17:38:47 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/16/2003 17:38:48, Serialize complete at 10/16/2003 17:38:48 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/OF7A76FD81.52D5C07D-ON85256DC1.0075A8CA-85256DC1.0076E8FF@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016214131.23A34A0691@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 17:41:31 -0400 (EDT) Julian wrote on 10/16/2003 04:18:52 PM: > > If you're telling me that anyone can invent an element and > > DAV-validly introduce it as if under the DAV namespace, > > The WG says it's not allowed, but many companies do it. That's a fact we > can't change in practice. > > > I will quietly pick up my marbles and go figure out how to use SOAP > > (with attachments) and the Web Services stack on HTTP to do > > Document Authoring and Versioning on the web. (Such an expression > > of some level of DAV functionality is probably valuable anyway.) > > I'm not sure I follow. The way WebDAV is extensible IMHO doesn't cause any > actual problems. Please be more specific. And before promoting SOAP in a > HTTP-based WG, please make sure that you've read all related > HTTP-with-extensions-vs-SOAP propaganda :-) In particular, SOAP is like XML ... it's easy to marshall things with it because it places no semantic constraints on what you marshall ... but the result of no semantic constraints is no semantic interoperability. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 16 17:50:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26591 for ; Thu, 16 Oct 2003 17:50:40 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 987EFA0691; Thu, 16 Oct 2003 17:50:49 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 20EB7A0691 for ; Thu, 16 Oct 2003 17:50:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DC04C1397B; Thu, 16 Oct 2003 17:50:47 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 65C79138EA for ; Thu, 16 Oct 2003 17:50:47 -0400 (EDT) Received: (qmail 24077 invoked by uid 65534); 16 Oct 2003 21:50:41 -0000 Received: from pD950C261.dip.t-dialin.net (HELO lisa) (217.80.194.97) by mail.gmx.net (mp005) with SMTP; 16 Oct 2003 23:50:41 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Julian Reschke" , , "Stanley Guan" , Date: Thu, 16 Oct 2003 23:50:23 +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 In-Reply-To: Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEFCINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016215049.987EFA0691@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 17:50:49 -0400 (EDT) Content-Transfer-Encoding: 8bit OK, I just spend a few minutes with Jing (Relax NG validator) and Trang (Schema Language convertor) [1]. Some initial thoughts: - RelaxNG can express WebDAV's extensibility model - RelaxNG has both an XML based syntax (à la XML Schema) and a Compact syntax (à la DTD) - Trang supports to/from DTD, XML Schema, RelaxG (compact/XML) and (!) sample XML instance data - RelaxNG supports the XML schema datatypes Here's an example for dav:propfind in RNC (Relax NG Compact Syntax): namespace dav = "DAV:" start = propfind allprop = element dav:allprop { empty } prop = element dav:prop { element * { empty }+ } propname = element dav:propname { empty } propfind = element dav:propfind { (allprop | prop | propname) & EXT? } EXT = element * - (dav:allprop | dav:href | dav:multistatus | dav:prop | dav:propfind | dav:propname | dav:response | dav:status) { empty } ...you get the idea. Should we pursue this? Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 16 18:33: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 SAA28856 for ; Thu, 16 Oct 2003 18:33:41 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 0D734A0673; Thu, 16 Oct 2003 18:33:51 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 26E63A0673 for ; Thu, 16 Oct 2003 18:33:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 0084E13838; Thu, 16 Oct 2003 18:33:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (Postfix) with ESMTP id AA102136A1 for ; Thu, 16 Oct 2003 18:33:48 -0400 (EDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GMXdqi018793; Thu, 16 Oct 2003 15:33:39 -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 h9GMXdr13896; Thu, 16 Oct 2003 16:33:39 -0600 (MDT) Received: from esedlarlap1 (dhcp-4op7-4op8-east-130-35-171-18.us.oracle.com [130.35.171.18]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9GMXcr13887; Thu, 16 Oct 2003 16:33:38 -0600 (MDT) Message-ID: <018801c39435$8a65a2c0$12ab2382@us.oracle.com> From: "Eric Sedlar" To: , "Julian Reschke" , "Stanley Guan" , References: Date: Thu, 16 Oct 2003 15:33:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/018801c39435$8a65a2c0$12ab2382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016223351.0D734A0673@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 18:33:51 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis-- The issue is not that "anyone can invent an element", but that new DAV specs will come out, and would break older clients not updated with the new schema. The issue is that XML Schema would constrain the DAV WG's ability to extend the specification. --Eric ----- Original Message ----- From: "Dennis E. Hamilton" To: "Julian Reschke" ; "Stanley Guan" ; Sent: Thursday, October 16, 2003 1:02 PM Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) [snip] If you're telling me that anyone can invent an element and DAV-validly introduce it as if under the DAV namespace, I will quietly pick up my marbles and go figure out how to use SOAP (with attachments) and the Web Services stack on HTTP to do Document Authoring and Versioning on the web. (Such an expression of some level of DAV functionality is probably valuable anyway.) -- Dennis -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, October 16, 2003 00:32 To: dennis.hamilton@acm.org; Stanley Guan; Julian Reschke; w3c-dist-auth@w3.org Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) Dennis, I think you're still missing a basic fact about WebDAV's extensibility: it is not centralized, nor linear. There is no common registry. Everybody can add extension elements anytime. Even if somebody would update that Schema anytime a new RFC (or Internet Draft) comes out out, there will be a lot of legal WebDAV messages that won't validate against that schema. Julian -- From w3c-dist-auth-request@w3.org Thu Oct 16 18:38: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 SAA28996 for ; Thu, 16 Oct 2003 18:38:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 192C5A0906; Thu, 16 Oct 2003 18:38:56 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1F21DA0906 for ; Thu, 16 Oct 2003 18:38:54 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id EE150138BC; Thu, 16 Oct 2003 18:38:53 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (Postfix) with ESMTP id A47CC13838 for ; Thu, 16 Oct 2003 18:38:53 -0400 (EDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9GMcoqi021467; Thu, 16 Oct 2003 15:38:50 -0700 (PDT) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9GMcnh16859; Thu, 16 Oct 2003 16:38:49 -0600 (MDT) Received: from esedlarlap1 (dhcp-4op7-4op8-east-130-35-171-18.us.oracle.com [130.35.171.18]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9GMcnh16848; Thu, 16 Oct 2003 16:38:49 -0600 (MDT) Message-ID: <01b401c39436$438e9b30$12ab2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" , , "Stanley Guan" , References: Date: Thu, 16 Oct 2003 15:38:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/01b401c39436$438e9b30$12ab2382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031016223856.192C5A0906@frink.w3.org> Resent-Date: Thu, 16 Oct 2003 18:38:56 -0400 (EDT) Content-Transfer-Encoding: 8bit There's not much interest in Relax NG in actual vendor products. Unless people are actually going to use validators, I don't think we should push Relax NG on people. --Eric ----- Original Message ----- From: "Julian Reschke" To: "Julian Reschke" ; ; "Stanley Guan" ; Sent: Thursday, October 16, 2003 2:50 PM Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > OK, > > I just spend a few minutes with Jing (Relax NG validator) and Trang (Schema > Language convertor) [1]. Some initial thoughts: > > - RelaxNG can express WebDAV's extensibility model > - RelaxNG has both an XML based syntax (à la XML Schema) and a Compact > syntax (à la DTD) > - Trang supports to/from DTD, XML Schema, RelaxG (compact/XML) and (!) > sample XML instance data > - RelaxNG supports the XML schema datatypes > > Here's an example for dav:propfind in RNC (Relax NG Compact Syntax): > > namespace dav = "DAV:" > > start = propfind > > allprop = element dav:allprop { empty } > > prop = > element dav:prop { > element * { empty }+ > } > propname = element dav:propname { empty } > propfind = element dav:propfind { (allprop | prop | propname) & EXT? } > > EXT = > element * - (dav:allprop > | dav:href > | dav:multistatus > | dav:prop > | dav:propfind > | dav:propname > | dav:response > | dav:status) { empty } > > ...you get the idea. > > Should we pursue this? > > Julian > > > [1] > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > From w3c-dist-auth-request@w3.org Fri Oct 17 00:04:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05604 for ; Fri, 17 Oct 2003 00:04:46 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F3378A0580; Fri, 17 Oct 2003 00:04:53 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 2B943A0633 for ; Fri, 17 Oct 2003 00:04:47 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id EA28713DCB; Fri, 17 Oct 2003 00:01:52 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail11.atl.registeredsite.com (mail11.atl.registeredsite.com [64.224.219.85]) by dr-nick.w3.org (Postfix) with ESMTP id CCF9C13D7A for ; Fri, 17 Oct 2003 00:01:52 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail11.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9H41khM022784; Fri, 17 Oct 2003 00:01:46 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172]) by infonuovo.com (8.8.7/8.8.5) with SMTP id VAA07956; Thu, 16 Oct 2003 21:01:45 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Eric Sedlar" , "Julian Reschke" , "Stanley Guan" , Date: Thu, 16 Oct 2003 21:01:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: <018801c39435$8a65a2c0$12ab2382@us.oracle.com> Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEIFDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017040453.F3378A0580@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 00:04:53 -0400 (EDT) Content-Transfer-Encoding: quoted-printable I don't understand how we got to this point. What about this has anything to do with breaking clients? =20 I thought the "ignore any element/attribute you don't understand" was a = pretty clean rule, and trumped the use of extensions *in*the*DAV*XML* by = another participant in the protocol. And this goes along with knowing = that a service may also ignore XML elements and attributes from you that = it doesn't understand for the level of DAV that it implements. The rules to DAV seem pretty clear: new DAV specs that come out can add = elements to the DAV namespace. What an older DAV implementation is to = do with any of that sent its way is well defined. Any use of a schema = validator would have to allow for that. =20 But I might know that what I am producing (not receiving) is at a = particular level of DAV, and I use schema assessment to verify that. = And if there is an update to DAV, I might have to update the schema I am = using. Or not, if I don't intend to use the extension and the rules say = it is still legal to ignore the extension.=20 Where does breaking come in? =20 I apologize Eric, I don't know what the context is any more. =20 -- Dennis -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Thursday, October 16, 2003 15:34 To: dennis.hamilton@acm.org; Julian Reschke; Stanley Guan; w3c-dist-auth@w3.org Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) Dennis-- The issue is not that "anyone can invent an element", but that new DAV specs will come out, and would break older clients not updated with the = new schema. The issue is that XML Schema would constrain the DAV WG's = ability to extend the specification. --Eric [ ... ] From w3c-dist-auth-request@w3.org Fri Oct 17 00:50: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 AAA06515 for ; Fri, 17 Oct 2003 00:50:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 80116A0705; Fri, 17 Oct 2003 00:50:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 07791A060D for ; Fri, 17 Oct 2003 00:50:51 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C2A7613D1E; Fri, 17 Oct 2003 00:50:50 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by dr-nick.w3.org (Postfix) with ESMTP id 9569313D10 for ; Fri, 17 Oct 2003 00:50:50 -0400 (EDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9H4o3nb014934; Thu, 16 Oct 2003 21:50:18 -0700 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 h9H4nqr03318; Thu, 16 Oct 2003 22:49:52 -0600 (MDT) Received: from esedlar (dhcp-amer-vpn-gw2-west-141-144-92-170.vpn.oracle.com [141.144.92.170]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9H4nqr03312; Thu, 16 Oct 2003 22:49:52 -0600 (MDT) Message-Id: <200310170449.h9H4nqr03312@rgmgw6.us.oracle.com> From: "Eric Sedlar" To: , "'Julian Reschke'" , "'Stanley Guan'" , Date: Thu, 16 Oct 2003 21:49:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook, Build 11.0.4920 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Thread-Index: AcOUY51ngVhHPcULTI6p9hkrFmlGAAABk5NQ Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/200310170449.h9H4nqr03312@rgmgw6.us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017045054.80116A0705@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 00:50:54 -0400 (EDT) Content-Transfer-Encoding: quoted-printable The problem is that there is no good way to say: "ignore any element/attribute you don't understand" in XML Schema. --Eric=20 > -----Original Message----- > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] > Sent: Thursday, October 16, 2003 9:02 PM > To: Eric Sedlar; Julian Reschke; Stanley Guan; w3c-dist-auth@w3.org >=20 > I don't understand how we got to this point. >=20 > What about this has anything to do with breaking clients? >=20 > I thought the "ignore any element/attribute you don't understand" was = a > pretty clean rule, and trumped the use of extensions *in*the*DAV*XML* = by > another participant in the protocol. And this goes along with knowing > that a service may also ignore XML elements and attributes from you = that > it doesn't understand for the level of DAV that it implements. >=20 > The rules to DAV seem pretty clear: new DAV specs that come out can = add > elements to the DAV namespace. What an older DAV implementation is = to do > with any of that sent its way is well defined. Any use of a schema > validator would have to allow for that. >=20 > But I might know that what I am producing (not receiving) is at a > particular level of DAV, and I use schema assessment to verify that. = And > if there is an update to DAV, I might have to update the schema I am > using. Or not, if I don't intend to use the extension and the rules = say > it is still legal to ignore the extension. >=20 > Where does breaking come in? >=20 > I apologize Eric, I don't know what the context is any more. >=20 > -- Dennis >=20 >=20 > -----Original Message----- > From: Eric Sedlar [mailto:eric.sedlar@oracle.com] > Sent: Thursday, October 16, 2003 15:34 > To: dennis.hamilton@acm.org; Julian Reschke; Stanley Guan; > w3c-dist-auth@w3.org > Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) >=20 >=20 > Dennis-- >=20 > The issue is not that "anyone can invent an element", but that new = DAV > specs will come out, and would break older clients not updated with = the > new > schema. The issue is that XML Schema would constrain the DAV WG's = ability > to extend the specification. >=20 > --Eric >=20 > [ ... ] >=20 From w3c-dist-auth-request@w3.org Fri Oct 17 03:20:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21991 for ; Fri, 17 Oct 2003 03:20:47 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B263FA059C; Fri, 17 Oct 2003 03:20:53 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C8BF4A059C for ; Fri, 17 Oct 2003 03:20:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5BFC6138AD; Fri, 17 Oct 2003 03:20:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id CDA591355D for ; Fri, 17 Oct 2003 03:20:48 -0400 (EDT) Received: (qmail 25883 invoked by uid 65534); 17 Oct 2003 07:20:36 -0000 Received: from pD950C241.dip.t-dialin.net (HELO lisa) (217.80.194.65) by mail.gmx.net (mp027) with SMTP; 17 Oct 2003 09:20:36 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Eric Sedlar" , "Julian Reschke" , Date: Fri, 17 Oct 2003 09:19:57 +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: <01b401c39436$438e9b30$12ab2382@us.oracle.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEFLINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017072053.B263FA059C@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 03:20:53 -0400 (EDT) Content-Transfer-Encoding: 8bit Eric, > There's not much interest in Relax NG in actual vendor products. Unless > people are actually going to use validators, I don't think we should push > Relax NG on people. I think that's a non-issue. We don't want to push *any* particular language on people. We were looking for something that would work better than DTDs, and RelaxNG seems to do that (it can express what we want and it has a readable syntax suitable for embedding in specs). If the requirement for the notation actually is that it needs to be a W3C spec and there have to be implementations by Microft, IBM and Oracle, then we can stop this discussion right away. The only alternative to DTDs would be XML Schema, and we know that it doesn't work. In which case we should go back to the original question about what we want to say normatively about the DTD fragments we use. On the other hand, RelaxNG fulfills all technical requirements, has working open source reference implementations, is as open as a spec as XML Schema (although Oasis instead of W3C) *and* is on it's way to a real ISO standard (something you can't say about XML Schema). 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 Eric Sedlar > Sent: Friday, October 17, 2003 12:39 AM > To: Julian Reschke; dennis.hamilton@acm.org; Stanley Guan; > w3c-dist-auth@w3.org > Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > > --Eric > > ----- Original Message ----- > From: "Julian Reschke" > To: "Julian Reschke" ; ; > "Stanley Guan" ; > Sent: Thursday, October 16, 2003 2:50 PM > Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > > > OK, > > > > I just spend a few minutes with Jing (Relax NG validator) and Trang > (Schema > > Language convertor) [1]. Some initial thoughts: > > > > - RelaxNG can express WebDAV's extensibility model > > - RelaxNG has both an XML based syntax (à la XML Schema) and a Compact > > syntax (à la DTD) > > - Trang supports to/from DTD, XML Schema, RelaxG (compact/XML) and (!) > > sample XML instance data > > - RelaxNG supports the XML schema datatypes > > > > Here's an example for dav:propfind in RNC (Relax NG Compact Syntax): > > > > namespace dav = "DAV:" > > > > start = propfind > > > > allprop = element dav:allprop { empty } > > > > prop = > > element dav:prop { > > element * { empty }+ > > } > > propname = element dav:propname { empty } > > propfind = element dav:propfind { (allprop | prop | propname) & EXT? } > > > > EXT = > > element * - (dav:allprop > > | dav:href > > | dav:multistatus > > | dav:prop > > | dav:propfind > > | dav:propname > > | dav:response > > | dav:status) { empty } > > > > ...you get the idea. > > > > Should we pursue this? > > > > Julian > > > > > > [1] > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 03:21: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 DAA22010 for ; Fri, 17 Oct 2003 03:21:08 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 02443A059C; Fri, 17 Oct 2003 03:21:16 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8D5C8A059C for ; Fri, 17 Oct 2003 03:21:14 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 1DB261355D; Fri, 17 Oct 2003 03:21:14 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A0771138EF for ; Fri, 17 Oct 2003 03:21:13 -0400 (EDT) Received: (qmail 27970 invoked by uid 65534); 17 Oct 2003 07:21:03 -0000 Received: from pD950C241.dip.t-dialin.net (HELO lisa) (217.80.194.65) by mail.gmx.net (mp027) with SMTP; 17 Oct 2003 09:21:03 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , Date: Fri, 17 Oct 2003 09:20:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFLINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017072116.02443A059C@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 03:21:16 -0400 (EDT) Content-Transfer-Encoding: 7bit Dennis, > ... > But I might know that what I am producing (not receiving) is at a > particular level of DAV, and I use schema assessment to verify > that. And if there is an update to DAV, I might have to update > the schema I am using. Or not, if I don't intend to use the > extension and the rules say it is still legal to ignore the extension. > ... I think both Eric and I are focusing on validating messages upon reception. If you just want to validate what you produced yourself, then, sure, it's possible to do that with a Schema that only accepts a subset of all the possible variations. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 10:45:16 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 KAA04999 for ; Fri, 17 Oct 2003 10:45:16 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 77F39A054B; Fri, 17 Oct 2003 10:45:24 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6467FA054B for ; Fri, 17 Oct 2003 10:45:21 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3063613F62; Fri, 17 Oct 2003 10:45:21 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from greenbytes.de (unknown [217.5.201.10]) by dr-nick.w3.org (Postfix) with ESMTP id 716C813F61 for ; Fri, 17 Oct 2003 10:45:20 -0400 (EDT) Received: from lisa ([192.168.1.23]) (authenticated user jr@greenbytes.de) by greenbytes.de (greenbytes.de [217.5.201.11]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 43-md50000000005.tmp for ; Fri, 17 Oct 2003 16:45:12 +0200 From: "Julian Reschke" To: Date: Fri, 17 Oct 2003 16:45:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Authenticated-Sender: jr@greenbytes.de X-Spam-Processed: greenbytes.de, Fri, 17 Oct 2003 16:45:12 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: redirect ref spec, issue "11.2-apply-to-redirect-ref-syntax" X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEGHINAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017144524.77F39A054B@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 10:45:24 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi, : this is the first non fully backwards-compliant change compared to the original drafts - it changes the definition for the "Apply-To-Redirect-Ref" header (previously empty, now "T" or "F"). The next major change will be an update of the PROPFIND/Depth 1 handling for redirect ref resources (getting rid of pseudo-properties, as discussed during the 2000 last call period). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 12:53: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 MAA10093 for ; Fri, 17 Oct 2003 12:53:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 3F134A0879; Fri, 17 Oct 2003 12:52:54 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 934CFA07D2 for ; Fri, 17 Oct 2003 12:52:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 54C92134EE; Fri, 17 Oct 2003 12:52:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet03.oracle.com (agminet03.oracle.com [141.146.126.230]) by dr-nick.w3.org (Postfix) with ESMTP id 1EDBE1345B for ; Fri, 17 Oct 2003 12:52:49 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet03.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9HGqlFQ011044; Fri, 17 Oct 2003 09:52:47 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9HGqjK19101; Fri, 17 Oct 2003 10:52:45 -0600 (MDT) Received: from esedlar (dhcp-amer-vpn-gw2-west-141-144-78-205.vpn.oracle.com [141.144.78.205]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9HGqhK19052; Fri, 17 Oct 2003 10:52:43 -0600 (MDT) Message-Id: <200310171652.h9HGqhK19052@rgmgw4.us.oracle.com> From: "Eric Sedlar" To: "'Julian Reschke'" , Date: Fri, 17 Oct 2003 09:52:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook, Build 11.0.4920 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Thread-Index: AcOUf3wU0WIAKa/0TliC10wDRsmXPQASm/Rw Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/200310171652.h9HGqhK19052@rgmgw4.us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017165254.3F134A0879@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 12:52:54 -0400 (EDT) Content-Transfer-Encoding: quoted-printable There are two possible use cases for a schema language to describe DAV = XML syntax. Case 1 is as a tool like BNF to formally describe the protocol. = A second is in the case where people would actually do validation at = runtime. I don't think that most WebDAV implementations today actually run DTD validation. For use case 1, XML Schema is fine since there is no = backwards compatibility issue. If you want to require use case 2, then people = would have to include a validation engine in their WebDAV implementations. If WebDAV WG chose RELAX NG for use case 2, then all WebDAV vendors would = have to acquire or develop RELAX implementations, which to me, is pushing = RELAX on people. If all we care about is case 1, we could always write our standards using XML Schema, but just note that the schemas are for a = formal description rather than for use in implementations. As far as your name-calling, goes, yes, Relax is almost a real ISO = standard like X.400 and other such successes from the ISO. They're much better = than those poorly specified ones coming from IETF and W3C like SMTP and HTTP. = I don't know why we have to descend into bashing of particular vendors or standards organizations to have this discussion. W3C is the = organization that currently owns most of the related standards we deal with in = WebDAV, such as XML and HTTP, so yes, I believe its standards are more relevant = than ISO ones when a conflict occurs (also note the mail address of this = list). Schema was designed by a large committee to meet the needs of a wide = variety of organizations and applications (e.g. structure definition, not just validation), as opposed to RELAX, which was designed by one guy. That's = why Schema has more market acceptance and RELAX is more elegant. In = general, the IETF and the WebDAV WG has tried to keep discussions rooted in practicality--what's actually out there in the bulk of the users. As = far as what major vendors are doing, since you mentioned my employer, I would = point out that your employer is also a proponent of XML Schema (quoted from http://www.w3.org/2001/05/xml-schema-testimonial.html): SAP is pleased to see that XML Schema has become a W3C Recommendation. = XML Schema is a key integration technology for supporting tightly coupled business processes through loosely coupled components within and outside = of the company boundary and an essential standard for building and = leveraging shared knowledge about collaborative services and processes. SAP is committed to embracing XML Schema throughout the mySAP.com e-business platform by providing XML-based services and leveraging XML Schema to support business integration within mySAP Technology. -- Dr. Peter Barth, Director Corporate Marketing mySAP Technology and = mySAP Workplace, SAP AG --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Julian Reschke > Sent: Friday, October 17, 2003 12:20 AM > To: Eric Sedlar; Julian Reschke; w3c-dist-auth@w3.org >=20 >=20 > Eric, >=20 > > There's not much interest in Relax NG in actual vendor products. = Unless > > people are actually going to use validators, I don't think we should > push > > Relax NG on people. >=20 > I think that's a non-issue. We don't want to push *any* particular > language > on people. We were looking for something that would work better than = DTDs, > and RelaxNG seems to do that (it can express what we want and it has a > readable syntax suitable for embedding in specs). >=20 > If the requirement for the notation actually is that it needs to be a = W3C > spec and there have to be implementations by Microft, IBM and Oracle, = then > we can stop this discussion right away. The only alternative to DTDs = would > be XML Schema, and we know that it doesn't work. In which case we = should > go > back to the original question about what we want to say normatively = about > the DTD fragments we use. >=20 > On the other hand, RelaxNG fulfills all technical requirements, has > working > open source reference implementations, is as open as a spec as XML = Schema > (although Oasis instead of W3C) *and* is on it's way to a real ISO > standard > (something you can't say about XML Schema). >=20 > Julian >=20 > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >=20 > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > > Sent: Friday, October 17, 2003 12:39 AM > > To: Julian Reschke; dennis.hamilton@acm.org; Stanley Guan; > > w3c-dist-auth@w3.org > > Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > > > >=20 > > > > --Eric > > > > ----- Original Message ----- > > From: "Julian Reschke" > > To: "Julian Reschke" ; = ; > > "Stanley Guan" ; > > Sent: Thursday, October 16, 2003 2:50 PM > > Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > > > > > > > OK, > > > > > > I just spend a few minutes with Jing (Relax NG validator) and = Trang > > (Schema > > > Language convertor) [1]. Some initial thoughts: > > > > > > - RelaxNG can express WebDAV's extensibility model > > > - RelaxNG has both an XML based syntax (=E0 la XML Schema) and a = Compact > > > syntax (=E0 la DTD) > > > - Trang supports to/from DTD, XML Schema, RelaxG (compact/XML) and = (!) > > > sample XML instance data > > > - RelaxNG supports the XML schema datatypes > > > > > > Here's an example for dav:propfind in RNC (Relax NG Compact = Syntax): > > > > > > namespace dav =3D "DAV:" > > > > > > start =3D propfind > > > > > > allprop =3D element dav:allprop { empty } > > > > > > prop =3D > > > element dav:prop { > > > element * { empty }+ > > > } > > > propname =3D element dav:propname { empty } > > > propfind =3D element dav:propfind { (allprop | prop | propname) & = EXT? } > > > > > > EXT =3D > > > element * - (dav:allprop > > > | dav:href > > > | dav:multistatus > > > | dav:prop > > > | dav:propfind > > > | dav:propname > > > | dav:response > > > | dav:status) { empty } > > > > > > ...you get the idea. > > > > > > Should we pursue this? > > > > > > Julian > > > > > > > > > [1] > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760 > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 13:19:03 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 NAA11185 for ; Fri, 17 Oct 2003 13:19:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7F8C9A0675; Fri, 17 Oct 2003 13:19:11 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 270DBA05E3 for ; Fri, 17 Oct 2003 13:19:09 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B21EF13907; Fri, 17 Oct 2003 13:19:08 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 4728F138FB for ; Fri, 17 Oct 2003 13:19:08 -0400 (EDT) Received: (qmail 15952 invoked by uid 65534); 17 Oct 2003 17:19:07 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006) with SMTP; 17 Oct 2003 19:19:07 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Eric Sedlar" , Date: Fri, 17 Oct 2003 19:19:05 +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: <200310171652.h9HGqhK19052@rgmgw4.us.oracle.com> Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEGPINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017171911.7F8C9A0675@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 13:19:11 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Friday, October 17, 2003 6:53 PM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) > > > > There are two possible use cases for a schema language to describe DAV XML > syntax. Case 1 is as a tool like BNF to formally describe the > protocol. A > second is in the case where people would actually do validation > at runtime. > I don't think that most WebDAV implementations today actually run DTD > validation. For use case 1, XML Schema is fine since there is no > backwards I agree that use case 1 is the one we talk about (at least it's the one that triggered this discussion). I happen to disagree that XML Schema is a good choice, because *for this particular use case*, it adds only little to what we already can do with DTDs, however it has the disadvantage of not having a compact syntax I'm prepared to put into a spec. (Side note: unless we use Trang to convert the XML Schema to RelaxNG Compact Notation) The DTD fragments we have right now at least offer good readability. I'm not prepared to throw them away just because DTDs aren't en vogue anymore. > compatibility issue. If you want to require use case 2, then people would > have to include a validation engine in their WebDAV implementations. If > WebDAV WG chose RELAX NG for use case 2, then all WebDAV vendors > would have > to acquire or develop RELAX implementations, which to me, is pushing RELAX Use case 2 is of no interest to me. > on people. If all we care about is case 1, we could always write our > standards using XML Schema, but just note that the schemas are > for a formal > description rather than for use in implementations. We could, but what would be the advantage compared to DTDs? We would still have to enumerate all the exceptions caused by WebDAV's extensibility rules. As far as I understand, we'd only get rid of one single exception (being namespace-awareness). > As far as your name-calling, goes, yes, Relax is almost a real > ISO standard > like X.400 and other such successes from the ISO. They're much > better than > those poorly specified ones coming from IETF and W3C like SMTP > and HTTP. I > don't know why we have to descend into bashing of particular vendors or > standards organizations to have this discussion. W3C is the organization > that currently owns most of the related standards we deal with in WebDAV, > such as XML and HTTP, so yes, I believe its standards are more > relevant than > ISO ones when a conflict occurs (also note the mail address of this list). In fact, WebDAV and HTTP are IETF specs. It's just this mailing list that happens to be hosted by the W3C. As for which organization is relevant -- this was not supposed to be an argument *against* W3C or IETF. In fact, in that case I'd have to ask myself why I'm putting all this work into IETF specification development. I just wanted to clarify that RelaxNG isn't just an unimportant niche product: one of it's creators is Jim Clark (editor of XSLT 1.0 rec) and it's published by Oasis (members including Oracle, SAP and Microsoft, for that matter). So as far as I'm concerned it has the same credibility as any competing W3C spec. Now I do understand that people who have heavily invested into XML Schema want to see it used. However, that's really not a convincing element if there are alternatives which seem to be better suited from a technical point of view. BTW here are some more alternatives: - specify an XSLT transformation that will transform any legal WebDAV message to a format that *can* be DTD validated, or - specify constraints by a serious of XPath assertions (a la Schematron), such as count(d:allprop|d:prop|d:propname)=1 ...and so on. > Schema was designed by a large committee to meet the needs of a > wide variety > of organizations and applications (e.g. structure definition, not just > validation), as opposed to RELAX, which was designed by one guy. Two, as a matter of fact. So does this make XML Schema better per se? > That's why > Schema has more market acceptance and RELAX is more elegant. In general, So if all we need is a notation for RFCs, what's more relevant? Elegance or market acceptance? > the IETF and the WebDAV WG has tried to keep discussions rooted in > practicality--what's actually out there in the bulk of the users. > As far as > what major vendors are doing, since you mentioned my employer, I > would point > out that your employer is also a proponent of XML Schema (quoted from > http://www.w3.org/2001/05/xml-schema-testimonial.html): > > SAP is pleased to see that XML Schema has become a W3C Recommendation. XML > Schema is a key integration technology for supporting tightly coupled > business processes through loosely coupled components within and > outside of > the company boundary and an essential standard for building and leveraging > shared knowledge about collaborative services and processes. SAP is > committed to embracing XML Schema throughout the mySAP.com e-business > platform by providing XML-based services and leveraging XML Schema to > support business integration within mySAP Technology. > -- Dr. Peter Barth, Director Corporate Marketing mySAP Technology > and mySAP > Workplace, SAP AG Actually, greenbytes is my employer. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 14:05: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 OAA13830 for ; Fri, 17 Oct 2003 14:05:51 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id C8D46A05D3; Fri, 17 Oct 2003 14:05:57 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7F6D3A06BF for ; Fri, 17 Oct 2003 14:05:53 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 2C1ED134E0; Fri, 17 Oct 2003 14:05:53 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by dr-nick.w3.org (Postfix) with ESMTP id 236EB133B4 for ; Fri, 17 Oct 2003 14:05:53 -0400 (EDT) Received: from mail11.atl.registeredsite.com (mail11.atl.registeredsite.com [64.224.219.85]) by frink.w3.org (Postfix) with ESMTP id 247F0A06BF for ; Fri, 17 Oct 2003 14:05:53 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail11.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9HI5IhM004363; Fri, 17 Oct 2003 14:05:18 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172] (may be forged)) by infonuovo.com (8.8.7/8.8.5) with SMTP id LAA15936; Fri, 17 Oct 2003 11:05:16 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Eric Sedlar" , "'Julian Reschke'" , "'Stanley Guan'" , Date: Fri, 17 Oct 2003 11:05:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200310170449.h9H4nqr03312@rgmgw6.us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAIEIPDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017180557.C8D46A05D3@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 14:05:57 -0400 (EDT) Content-Transfer-Encoding: quoted-printable That's correct. You can't use an XML Schema definition as a pass-fail filter that = rejects elements/attributes that might be from an extension and are not = comprehended in the schema definition. Since you also can't reject ad = hoc non-DAV elements and attributes either, one must be careful how the = schema definition is written and how/whether schema assessment is = applied to material that is received. In my world, that's not a problem. That's just how it is. It is a = limitation on the applicability of XML Schema to DAV XML documents in = request and response bodies. -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar Sent: Thursday, October 16, 2003 21:50 To: dennis.hamilton@acm.org; 'Julian Reschke'; 'Stanley Guan'; w3c-dist-auth@w3.org Subject: RE: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) The problem is that there is no good way to say: "ignore any element/attribute you don't understand" in XML Schema. --Eric=20 [ ... ] From w3c-dist-auth-request@w3.org Fri Oct 17 14:16: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 OAA14207 for ; Fri, 17 Oct 2003 14:16:57 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 02A5AA0870; Fri, 17 Oct 2003 14:16:33 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9419DA0870 for ; Fri, 17 Oct 2003 14:16:31 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 29F51139A8; Fri, 17 Oct 2003 14:16:31 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 92AE5134E0 for ; Fri, 17 Oct 2003 14:16:30 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAZ9J-0007Sl-00; Fri, 17 Oct 2003 18:16:29 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAZ9I-0007Rz-00; Fri, 17 Oct 2003 18:16:29 +0000 From: "Lisa Dusseault" To: , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Fri, 17 Oct 2003 23:15:28 -0700 Message-ID: <000b01c3953f$3cd44b50$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: dennis.hamilton@acm.org, geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/000b01c3953f$3cd44b50$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017181633.02A5AA0870@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 14:16:33 -0400 (EDT) Content-Transfer-Encoding: 7bit > > ... > > (a) the ANY case in an element markup declaration means > any element > > that is declared in the DTD, not some undeclared or unspecified > > element. ... > > Thanks for the reminder. I had forgotten about that. It > basically means that by definition you can't express the > content model of using a DTD. So does this mean we should simply remove the DTD-style definition of the 'prop' element (as well as 'owner' and 'resourcetype') from the spec? I believe the natural-language specification should be sufficient to define these anyway. The 'owner' element could maybe be defined as MIXED but 'prop' and 'resourcetype' cannot be mixed. Lisa From w3c-dist-auth-request@w3.org Fri Oct 17 14:35: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 OAA15190 for ; Fri, 17 Oct 2003 14:35:54 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7ECAEA058E; Fri, 17 Oct 2003 14:36:01 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8CDC2A057D for ; Fri, 17 Oct 2003 14:35:56 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 6A84813891; Fri, 17 Oct 2003 14:35:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id ED3861345F for ; Fri, 17 Oct 2003 14:35:55 -0400 (EDT) Received: (qmail 24302 invoked by uid 65534); 17 Oct 2003 18:35:46 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp012) with SMTP; 17 Oct 2003 20:35:46 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , , "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Fri, 17 Oct 2003 20:35:15 +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: <000b01c3953f$3cd44b50$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEHCINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017183601.7ECAEA058E@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 14:36:01 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Saturday, October 18, 2003 8:15 AM > To: dennis.hamilton@acm.org; 'Julian Reschke'; 'Geoffrey M Clemm'; > w3c-dist-auth@w3.org > Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) > > > > > ... > > > (a) the ANY case in an element markup declaration means > > any element > > > that is declared in the DTD, not some undeclared or unspecified > > > element. ... > > > > Thanks for the reminder. I had forgotten about that. It > > basically means that by definition you can't express the > > content model of using a DTD. > > So does this mean we should simply remove the DTD-style definition of > the 'prop' element (as well as 'owner' and 'resourcetype') from the > spec? I believe the natural-language specification should be > sufficient to define these anyway. The drawback would be that this would break the DTD's syntax. An alternative is to keep ANY, and make sure that the description says what this actually means. > The 'owner' element could maybe be defined as MIXED but 'prop' and > 'resourcetype' cannot be mixed. Yes. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 14:50: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 OAA15582 for ; Fri, 17 Oct 2003 14:50:46 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9EF88A0A0F; Fri, 17 Oct 2003 14:49:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E2CCFA09B3 for ; Fri, 17 Oct 2003 14:48:53 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id EA36513DD0; Fri, 17 Oct 2003 14:46:20 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id CCFA813D0B for ; Fri, 17 Oct 2003 14:46:20 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAZcC-0007lu-00; Fri, 17 Oct 2003 18:46:20 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAZcB-0007li-00; Fri, 17 Oct 2003 18:46:20 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Fri, 17 Oct 2003 23:45:23 -0700 Message-ID: <001701c39543$6864a680$f8cb90c6@lisalap> 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, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/001701c39543$6864a680$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017184900.9EF88A0A0F@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 14:49:00 -0400 (EDT) Content-Transfer-Encoding: 7bit > > For now I propose that the client is able to specify the > redirection type as a resource type, such as > "DAV:permanent-redirect-reference" and > "DAV:temporary-redirect-reference". This spec would only > define the behaviour for these two resource types and would > allow future extensions using new resource types and > suggested response codes. > What's the use case for this functionality. How would a user creating a link decide whether this was a permanent or a temporary redirect link? Is anybody actually planning to implement a client that would care which one it was creating? If there aren't implementation plans, use case, etc, then the KISS principle suggests that we pick one. Since redirect resources are in fact permanent until deleted (the temporariness is completely unknown), I see no reason why they wouldn't all be the same kind of redirect resource. Before we chose one HTTP response or another, it would be good to know whether HTTP clients behave differently. I have no data on this. lisa From w3c-dist-auth-request@w3.org Fri Oct 17 15:01: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 PAA15947 for ; Fri, 17 Oct 2003 15:01:09 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 22A5DA0865; Fri, 17 Oct 2003 15:01:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id CCA3FA0865 for ; Fri, 17 Oct 2003 15:01:14 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 81AC513776; Fri, 17 Oct 2003 15:01:14 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 19BDD135B0 for ; Fri, 17 Oct 2003 15:01:14 -0400 (EDT) Received: (qmail 27651 invoked by uid 65534); 17 Oct 2003 19:01:09 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp023) with SMTP; 17 Oct 2003 21:01:09 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , Date: Fri, 17 Oct 2003 21:00:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <001701c39543$6864a680$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEHEINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017190117.22A5DA0865@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:01:17 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa, HTTP is very clear about what it means: - Temporary: follow the link, but keep accessing *this* URL - Permanent: follow the link, and forget about the original location Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Saturday, October 18, 2003 8:45 AM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > For now I propose that the client is able to specify the > > redirection type as a resource type, such as > > "DAV:permanent-redirect-reference" and > > "DAV:temporary-redirect-reference". This spec would only > > define the behaviour for these two resource types and would > > allow future extensions using new resource types and > > suggested response codes. > > > > What's the use case for this functionality. How would a user > creating a link decide whether this was a permanent or a temporary > redirect link? Is anybody actually planning to implement a > client that would care which one it was creating? > > If there aren't implementation plans, use case, etc, then the > KISS principle suggests that we pick one. Since redirect resources > are in fact permanent until deleted (the temporariness is > completely unknown), I see no reason why they > wouldn't all be the same kind of redirect resource. > > Before we chose one HTTP response or another, it would be good > to know whether HTTP clients behave differently. I have no data > on this. > > lisa > > From w3c-dist-auth-request@w3.org Fri Oct 17 15:07:44 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 PAA16522 for ; Fri, 17 Oct 2003 15:07:44 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 3DBFFA0512; Fri, 17 Oct 2003 15:07:26 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A1945A0624 for ; Fri, 17 Oct 2003 15:07:24 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 4BF4B135B0; Fri, 17 Oct 2003 15:07:24 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 2F290134E3 for ; Fri, 17 Oct 2003 15:07:24 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAZwZ-00080P-00; Fri, 17 Oct 2003 19:07:23 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAZwZ-00080E-00; Fri, 17 Oct 2003 19:07:23 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , , "'Geoffrey M Clemm'" , Date: Sat, 18 Oct 2003 00:06:27 -0700 Message-ID: <001f01c39546$596b27f0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: dennis.hamilton@acm.org, geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/001f01c39546$596b27f0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017190726.3DBFFA0512@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:07:26 -0400 (EDT) Content-Transfer-Encoding: 7bit > > So does this mean we should simply remove the DTD-style > definition of > > the 'prop' element (as well as 'owner' and 'resourcetype') from the > > spec? I believe the natural-language specification should be > > sufficient to define these anyway. > > The drawback would be that this would break the DTD's syntax. > An alternative is to keep ANY, and make sure that the > description says what this actually means. > It wouldn't break the DTD syntax if we only use DTD fragments to formally define those elements that can be formally defined. I thought the idea of omitting the full combined DTD appendix was a generally acceptable idea, as long as the DTD fragments were still there for most of the elements. Lisa From w3c-dist-auth-request@w3.org Fri Oct 17 15:11: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 PAA16977 for ; Fri, 17 Oct 2003 15:11:26 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 054BBA0619; Fri, 17 Oct 2003 15:11:34 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B2B16A0619 for ; Fri, 17 Oct 2003 15:11:32 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 55992139F7; Fri, 17 Oct 2003 15:11:32 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 24052135B0 for ; Fri, 17 Oct 2003 15:11:32 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAa0Z-000841-00; Fri, 17 Oct 2003 19:11:31 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAa0Z-00083q-00; Fri, 17 Oct 2003 19:11:31 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Sat, 18 Oct 2003 00:10:35 -0700 Message-ID: <002201c39546$ed54e8c0$f8cb90c6@lisalap> 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, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/002201c39546$ed54e8c0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017191134.054BBA0619@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:11:34 -0400 (EDT) Content-Transfer-Encoding: 7bit This is indisputable, but that doesn't answer my questions. - How do browsers in fact behave differently? - What is the use case for creating different redirect resource types? Lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, October 17, 2003 12:01 PM > To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > Lisa, > > HTTP is very clear about what it means: > > - Temporary: follow the link, but keep accessing *this* URL > - Permanent: follow the link, and forget about the original location > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Saturday, October 18, 2003 8:45 AM > > To: 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > > > > > For now I propose that the client is able to specify the > > > redirection type as a resource type, such as > > > "DAV:permanent-redirect-reference" and > > > "DAV:temporary-redirect-reference". This spec would only > > > define the behaviour for these two resource types and would > > > allow future extensions using new resource types and > > > suggested response codes. > > > > > > > What's the use case for this functionality. How would a > user creating > > a link decide whether this was a permanent or a temporary redirect > > link? Is anybody actually planning to implement a client > that would > > care which one it was creating? > > > > If there aren't implementation plans, use case, etc, then the KISS > > principle suggests that we pick one. Since redirect > resources are in > > fact permanent until deleted (the temporariness is completely > > unknown), I see no reason why they wouldn't all be the same kind of > > redirect resource. > > > > Before we chose one HTTP response or another, it would be good > > to know whether HTTP clients behave differently. I have no data > > on this. > > > > lisa > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 15:27: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 PAA17924 for ; Fri, 17 Oct 2003 15:27:30 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 73F73A0587; Fri, 17 Oct 2003 15:27:37 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3F0E4A0587 for ; Fri, 17 Oct 2003 15:27:35 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B93E413A4A; Fri, 17 Oct 2003 15:27:34 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 785B9139B2 for ; Fri, 17 Oct 2003 15:27:34 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAaG6-0008Ct-00 for w3c-dist-auth@w3.org; Fri, 17 Oct 2003 19:27:34 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAaG5-0008Ci-00 for w3c-dist-auth@w3.org; Fri, 17 Oct 2003 19:27:34 +0000 From: "Lisa Dusseault" To: Date: Sat, 18 Oct 2003 00:26:38 -0700 Message-ID: <002501c39549$2b05d6a0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C3950E.7EA6FEA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3F8DCCF0.7090305@cse.ucsc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/002501c39549$2b05d6a0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017192737.73F73A0587@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:27:37 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C3950E.7EA6FEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This proposal clearly has a lot of support. I too favour a single client-feature-advertisement header. However, I'd like to caution the = group that we won't be able to demonstrate the interoperability of this = header, and thus we take the risk that this won't be considered a suitable = feature to take to the next standards phase (draft standard). =20 =20 I see no problem with defining the exact same header in the redirect = spec (or another), with a note that other extensions are encouraged to use = the same header. Since this community is very good about reusing this kind = of solution, I'm not worried that its location will be a problem. It's = much like the DeltaV preconditions/postconditions framework which has already been reused by ACL and others without needing to modify 2518. =20 If there's still consensus to add to 2518bis specifically, let me know (individually is fine) and I'll add it to the document. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Elias Sinderson Sent: Wednesday, October 15, 2003 3:41 PM To: w3c-dist-auth@w3.org Subject: Re: 3xx vs RFC2518 vs redirect-ref spec I agree, let's add this to 2518bis - the proposed mechnism is simple and easy for developers to understand. Elias Geoffrey M Clemm wrote: I support this addition to RFC2518bis.=20 I believe it is a key mechanism needed for servers to properly support=20 the various current (and future) WebDAV extensions.=20 Cheers,=20 Geoff=20 Julian wrote on 10/14/2003 09:53:30 AM: >=20 > > OK, > > > > so we probably should put it onto the issues list (so that it = doesn't get > lost). >=20 > Here's a proposal for the issues list: >=20 >=20 > Issue DAV_REQUEST_HEADER >=20 > RFC 2518 provides a mechanism (the "DAV" response header) for a server = to > indicate to a client that it supports a specific WebDAV option (e.g. = "1", > "2", "version-control", etc.), but there is no complementary mechanism = for a > client to indicate to a server that it understands a specific WebDAV option. > This becomes an issue when a WebDAV extension (or revision) needs to change > response formats in a way that possibly break existing clients. = Detecting > client features based on a single, well-defined request header will = work > better than (for instance) relying on custom headers (specified by = each > extension) or "User-Agent". >=20 > Suggested resolution: allow the use of the "DAV" header as a request header, > with the same set of values that are defined for the "DAV" > response header. >=20 >=20 > Regards, Julian >=20 > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >=20 ------=_NextPart_000_0026_01C3950E.7EA6FEA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
This=20 proposal clearly has a lot of support.  I too favour a single=20 client-feature-advertisement header. However, I'd like to caution the = group that=20 we won't be able to demonstrate the interoperability of this header, and = thus we=20 take the risk that this won't be considered a suitable feature to take = to the=20 next standards phase (draft standard). 
 
I see=20 no problem with defining the exact same header in the redirect spec (or=20 another), with a note that other extensions are encouraged to use the = same=20 header.  Since this community is very good about reusing this kind = of=20 solution, I'm not worried that its location will be a problem.  = It's much=20 like the DeltaV preconditions/postconditions framework which has already = been=20 reused by ACL and others without needing to modify = 2518.
 
If=20 there's still consensus to add to 2518bis specifically, let me know=20 (individually is fine) and I'll add it to the = document.
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Elias Sinderson
Sent: Wednesday, October 15, = 2003 3:41=20 PM
To: w3c-dist-auth@w3.org
Subject: Re: 3xx vs = RFC2518 vs=20 redirect-ref spec

I agree, let's add this to = 2518bis - the=20 proposed mechnism is simple and easy for developers to=20 understand.


Elias


Geoffrey M Clemm wrote:

I support this addition to=20 RFC2518bis.

I believe it is a = key=20 mechanism needed for servers to properly support =
the various current (and future) WebDAV = extensions.=20

Cheers,
Geoff

Julian = wrote on=20 10/14/2003 09:53:30 AM:

>
> > OK,
> = >
>=20 > so we probably should put it onto the issues list (so that it = doesn't=20 get
> lost).
>
> Here's a proposal for the issues = list:
>
>
> Issue DAV_REQUEST_HEADER
> =
>=20 RFC 2518 provides a mechanism (the "DAV" response header) for a = server=20 to
> indicate to a client that it supports a specific WebDAV = option=20 (e.g. "1",
> "2", "version-control", etc.), but there is no=20 complementary mechanism for a
> client to indicate to a server = that it=20 understands a specific WebDAV option.
> This becomes an issue = when a=20 WebDAV extension (or revision) needs to change
> response = formats in a=20 way that possibly break existing clients. Detecting
> client = features=20 based on a single, well-defined request header will work
> = better than=20 (for instance) relying on custom headers (specified by each
>=20 extension) or "User-Agent".
>
> Suggested resolution: = allow the=20 use of the "DAV" header as a request header,
> with the same = set of=20 values that are defined for the "DAV"
> response = header.
>=20
>
> Regards, Julian
>
> --
>=20 <green/>bytes GmbH -- http://www.greenbytes.de --=20 tel:+492512807760
>=20

------=_NextPart_000_0026_01C3950E.7EA6FEA0-- From w3c-dist-auth-request@w3.org Fri Oct 17 15:37: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 PAA18808 for ; Fri, 17 Oct 2003 15:37:56 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 903AAA0587; Fri, 17 Oct 2003 15:38:03 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 113BCA0587 for ; Fri, 17 Oct 2003 15:38:01 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C4D0213B09; Fri, 17 Oct 2003 15:35:51 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (Postfix) with ESMTP id AC05A139F2 for ; Fri, 17 Oct 2003 15:35:51 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9HJZpXg006190 for ; Fri, 17 Oct 2003 15:35:51 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9HJZnP8228580 for ; Fri, 17 Oct 2003 15:35:50 -0400 In-Reply-To: <002501c39549$2b05d6a0$f8cb90c6@lisalap> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 17 Oct 2003 15:35:47 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/17/2003 15:35:50, Serialize complete at 10/17/2003 15:35:50 Content-Type: text/plain; charset="US-ASCII" Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/OF47D5C329.33CD7C6D-ON85256DC2.006B9C0B-85256DC2.006BA5BE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017193803.903AAA0587@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:38:03 -0400 (EDT) I would like to see it added specifically to 2518bis. I believe that there will be plenty of time between now and when 2518bis goes to the IESG for a sufficient number of clients and servers to add in the DAV request header (and if there is one feature that is unlikely to introduce an interoperability problem, this is probably it :-). Cheers, Geoff Lisa wrote on 10/18/2003 03:26:38 AM: > This proposal clearly has a lot of support. I too favour a single > client-feature-advertisement header. However, I'd like to caution > the group that we won't be able to demonstrate the interoperability > of this header, and thus we take the risk that this won't be > considered a suitable feature to take to the next standards phase > (draft standard). > > I see no problem with defining the exact same header in the redirect > spec (or another), with a note that other extensions are encouraged > to use the same header. Since this community is very good about > reusing this kind of solution, I'm not worried that its location > will be a problem. It's much like the DeltaV > preconditions/postconditions framework which has already been reused > by ACL and others without needing to modify 2518. > > If there's still consensus to add to 2518bis specifically, let me > know (individually is fine) and I'll add it to the document. > > Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Elias Sinderson > Sent: Wednesday, October 15, 2003 3:41 PM > To: w3c-dist-auth@w3.org > Subject: Re: 3xx vs RFC2518 vs redirect-ref spec > I agree, let's add this to 2518bis - the proposed mechnism is simple > and easy for developers to understand. > > > Elias > > > Geoffrey M Clemm wrote: > > I support this addition to RFC2518bis. > > I believe it is a key mechanism needed for servers to properly support > the various current (and future) WebDAV extensions. > > Cheers, > Geoff > > Julian wrote on 10/14/2003 09:53:30 AM: > > > > > > OK, > > > > > > so we probably should put it onto the issues list (so that it doesn't get > > lost). > > > > Here's a proposal for the issues list: > > > > > > Issue DAV_REQUEST_HEADER > > > > RFC 2518 provides a mechanism (the "DAV" response header) for a server to > > indicate to a client that it supports a specific WebDAV option (e.g. "1", > > "2", "version-control", etc.), but there is no complementary mechanism for a > > client to indicate to a server that it understands a specific WebDAV option. > > This becomes an issue when a WebDAV extension (or revision) needs to change > > response formats in a way that possibly break existing clients. Detecting > > client features based on a single, well-defined request header will work > > better than (for instance) relying on custom headers (specified by each > > extension) or "User-Agent". > > > > Suggested resolution: allow the use of the "DAV" header as a request header, > > with the same set of values that are defined for the "DAV" > > response header. > > > > > > Regards, Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Fri Oct 17 15:38:06 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 PAA18824 for ; Fri, 17 Oct 2003 15:38:06 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7C733A0619; Fri, 17 Oct 2003 15:38:05 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3EB1FA0619 for ; Fri, 17 Oct 2003 15:38:04 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DE4AD13C25; Fri, 17 Oct 2003 15:36:05 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id C112813BD0 for ; Fri, 17 Oct 2003 15:36:05 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AAaOL-0008HT-00; Fri, 17 Oct 2003 19:36:05 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AAaOL-0008HI-00; Fri, 17 Oct 2003 19:36:05 +0000 From: "Lisa Dusseault" To: "'Stanley Guan'" , Date: Sat, 18 Oct 2003 00:35:09 -0700 Message-ID: <002c01c3954a$5ba11df0$f8cb90c6@lisalap> 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, Build 10.0.4510 Importance: Normal In-Reply-To: <0ddc01c39428$2a8f6870$c5b42382@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: stanley.guan@oracle.com, w3c-dist-auth@w3.org Subject: RE: Easy-to-read deltas for rfc2518bis? X-Archived-At: http://www.w3.org/mid/002c01c3954a$5ba11df0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017193805.7C733A0619@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:38:05 -0400 (EDT) Content-Transfer-Encoding: 7bit I have an ad-hoc document here that might serve your needs: http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc It's gotten increasingly inaccurate because it's hard to track changes to changes to changes to RFC2518. If you find any such inaccuracies and point them out to me, I will be happy to fix them. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stanley Guan > Sent: Thursday, October 16, 2003 1:58 PM > To: w3c-dist-auth@w3.org > Subject: Easy-to-read deltas for rfc2518bis? > > > > Hi, > > Is there any delta history of the rfc2518bis? Is it possible > to provide something similar to: > http://www.w3.org/2001/05/xmlschema-errata.html > > regarding editorial efforts to highlight what's new and > what's different from the original rfc2518 in rfc218bis? > > Thx, > > -Stanley > > From w3c-dist-auth-request@w3.org Fri Oct 17 15:47:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19489 for ; Fri, 17 Oct 2003 15:47:19 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id A9165A0587; Fri, 17 Oct 2003 15:47:26 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 38458A0587 for ; Fri, 17 Oct 2003 15:47:25 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 00E33139F2; Fri, 17 Oct 2003 15:47:25 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8AF5B1341C for ; Fri, 17 Oct 2003 15:47:24 -0400 (EDT) Received: (qmail 11604 invoked by uid 65534); 17 Oct 2003 19:47:20 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp001) with SMTP; 17 Oct 2003 21:47:20 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Fri, 17 Oct 2003 21:47:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <002201c39546$ed54e8c0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEHHINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017194726.A9165A0587@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:47:26 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa, I don't think it's up to me to answer that. The purpose of the Redirect Ref spec is 1) to define how existing redirects behave inside WebDAV collections and 2) how to author redirects. The HTTP spec has decided to distinguish between these types, and therefore it makes sense to reflect that distinction in the redirect ref spec as well. I imagine that browsers should remember "how they got" to the URL when the user decides to bookmark the URL. This feature was requested during the Last Call in spring 2000, and it seems that there was WG consensus to add that (at least this is what the issues list says). As storing a type seems to be trivial when the target URL needs to be stored anyway, and as Apache indeed distinguishes between those types, I feel it makes sense to have it authorable as well. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, October 18, 2003 9:11 AM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > This is indisputable, but that doesn't answer my questions. > - How do browsers in fact behave differently? > - What is the use case for creating different redirect resource types? > > Lisa > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Friday, October 17, 2003 12:01 PM > > To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > Lisa, > > > > HTTP is very clear about what it means: > > > > - Temporary: follow the link, but keep accessing *this* URL > > - Permanent: follow the link, and forget about the original location > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Saturday, October 18, 2003 8:45 AM > > > To: 'Julian Reschke'; w3c-dist-auth@w3.org > > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > > > > > > > > > For now I propose that the client is able to specify the > > > > redirection type as a resource type, such as > > > > "DAV:permanent-redirect-reference" and > > > > "DAV:temporary-redirect-reference". This spec would only > > > > define the behaviour for these two resource types and would > > > > allow future extensions using new resource types and > > > > suggested response codes. > > > > > > > > > > What's the use case for this functionality. How would a > > user creating > > > a link decide whether this was a permanent or a temporary redirect > > > link? Is anybody actually planning to implement a client > > that would > > > care which one it was creating? > > > > > > If there aren't implementation plans, use case, etc, then the KISS > > > principle suggests that we pick one. Since redirect > > resources are in > > > fact permanent until deleted (the temporariness is completely > > > unknown), I see no reason why they wouldn't all be the same kind of > > > redirect resource. > > > > > > Before we chose one HTTP response or another, it would be good > > > to know whether HTTP clients behave differently. I have no data > > > on this. > > > > > > lisa > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 15:54: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 PAA20343 for ; Fri, 17 Oct 2003 15:54:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 999A0A0879; Fri, 17 Oct 2003 15:54:50 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7FE67A0870 for ; Fri, 17 Oct 2003 15:54:48 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 81FE713CE4; Fri, 17 Oct 2003 15:51:54 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (Postfix) with ESMTP id 6164B13AF1 for ; Fri, 17 Oct 2003 15:51:54 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9HJpmfk745826; Fri, 17 Oct 2003 15:51:48 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9HJplO2192816; Fri, 17 Oct 2003 15:51:47 -0400 In-Reply-To: To: "Julian Reschke" Cc: "Lisa Dusseault" , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 17 Oct 2003 15:51:45 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/17/2003 15:51:47, Serialize complete at 10/17/2003 15:51:47 Content-Type: text/plain; charset="US-ASCII" Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/OF6CBC3772.B52061CB-ON85256DC2.006CF238-85256DC2.006D1C34@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017195450.999A0A0879@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 15:54:50 -0400 (EDT) I agree with Julian's rationale for adding this distinction. This is just modeling the behavior defined by the existing standard, not introducing new behavior. Cheers, Geoff Julian wrote on 10/17/2003 03:47:09 PM: > > Lisa, > > I don't think it's up to me to answer that. The purpose of the Redirect Ref > spec is > > 1) to define how existing redirects behave inside WebDAV collections and > > 2) how to author redirects. > > The HTTP spec has decided to distinguish between these types, and therefore > it makes sense to reflect that distinction in the redirect ref spec as well. > I imagine that browsers should remember "how they got" to the URL when the > user decides to bookmark the URL. > > This feature was requested during the Last Call in spring 2000, and it seems > that there was WG consensus to add that (at least this is what the issues > list says). As storing a type seems to be trivial when the target URL needs > to be stored anyway, and as Apache indeed distinguishes between those types, > I feel it makes sense to have it authorable as well. > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Saturday, October 18, 2003 9:11 AM > > To: 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > > > This is indisputable, but that doesn't answer my questions. > > - How do browsers in fact behave differently? > > - What is the use case for creating different redirect resource types? > > > > Lisa > > > -----Original Message----- > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Sent: Friday, October 17, 2003 12:01 PM > > > To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org > > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > > > > Lisa, > > > > > > HTTP is very clear about what it means: > > > > > > - Temporary: follow the link, but keep accessing *this* URL > > > - Permanent: follow the link, and forget about the original location > > > > > > Julian > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > -----Original Message----- > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > > Sent: Saturday, October 18, 2003 8:45 AM > > > > To: 'Julian Reschke'; w3c-dist-auth@w3.org > > > > Subject: RE: redirect ref spec, update on issue lc-85-301 > > > > > > > > > > > > > > > > > > For now I propose that the client is able to specify the > > > > > redirection type as a resource type, such as > > > > > "DAV:permanent-redirect-reference" and > > > > > "DAV:temporary-redirect-reference". This spec would only > > > > > define the behaviour for these two resource types and would > > > > > allow future extensions using new resource types and > > > > > suggested response codes. > > > > > > > > > > > > > What's the use case for this functionality. How would a > > > user creating > > > > a link decide whether this was a permanent or a temporary redirect > > > > link? Is anybody actually planning to implement a client > > > that would > > > > care which one it was creating? > > > > > > > > If there aren't implementation plans, use case, etc, then the KISS > > > > principle suggests that we pick one. Since redirect > > > resources are in > > > > fact permanent until deleted (the temporariness is completely > > > > unknown), I see no reason why they wouldn't all be the same kind of > > > > redirect resource. > > > > > > > > Before we chose one HTTP response or another, it would be good > > > > to know whether HTTP clients behave differently. I have no data > > > > on this. > > > > > > > > lisa > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 16:07: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 QAA21204 for ; Fri, 17 Oct 2003 16:07:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 8899BA0870; Fri, 17 Oct 2003 16:07:19 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 47F5DA0870 for ; Fri, 17 Oct 2003 16:07:17 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id E71E013A05; Fri, 17 Oct 2003 16:07:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (Postfix) with ESMTP id 9738013AEF for ; Fri, 17 Oct 2003 16:07:16 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9HK7Fqi023172; Fri, 17 Oct 2003 13:07:16 -0700 (PDT) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9HK7FK28306; Fri, 17 Oct 2003 14:07:15 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9HK7EK28296; Fri, 17 Oct 2003 14:07:14 -0600 (MDT) Message-ID: <0f3501c394ea$31399020$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Lisa Dusseault" , References: <002c01c3954a$5ba11df0$f8cb90c6@lisalap> Date: Fri, 17 Oct 2003 13:06:46 -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: Easy-to-read deltas for rfc2518bis? X-Archived-At: http://www.w3.org/mid/0f3501c394ea$31399020$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017200719.8899BA0870@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 16:07:19 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa, This is a great help! Will let you know if I've found out any inaccuracies in it! Thx, -Stanley ----- Original Message ----- From: "Lisa Dusseault" To: "'Stanley Guan'" ; Sent: Saturday, October 18, 2003 12:35 AM Subject: RE: Easy-to-read deltas for rfc2518bis? > I have an ad-hoc document here that might serve your needs: > > http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc > > It's gotten increasingly inaccurate because it's hard to > track changes to changes to changes to RFC2518. If you find > any such inaccuracies and point them out to me, I will be > happy to fix them. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stanley Guan > > Sent: Thursday, October 16, 2003 1:58 PM > > To: w3c-dist-auth@w3.org > > Subject: Easy-to-read deltas for rfc2518bis? > > > > > > > > Hi, > > > > Is there any delta history of the rfc2518bis? Is it possible > > to provide something similar to: > > http://www.w3.org/2001/05/xmlschema-errata.html > > > > regarding editorial efforts to highlight what's new and > > what's different from the original rfc2518 in rfc218bis? > > > > Thx, > > > > -Stanley > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 17 16:44: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 QAA23566 for ; Fri, 17 Oct 2003 16:44:48 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id DF1CEA05D3; Fri, 17 Oct 2003 16:44:56 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C1237A05D3 for ; Fri, 17 Oct 2003 16:44:54 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 91240133DB; Fri, 17 Oct 2003 16:44:54 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 1F59D134F8 for ; Fri, 17 Oct 2003 16:44:54 -0400 (EDT) Received: (qmail 21940 invoked by uid 65534); 17 Oct 2003 20:44:47 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp009) with SMTP; 17 Oct 2003 22:44:47 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Fri, 17 Oct 2003 22:44:33 +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: <001f01c39546$596b27f0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEHLINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017204456.DF1CEA05D3@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 16:44:56 -0400 (EDT) Content-Transfer-Encoding: 7bit OK, here's an attempt to summarize... Almost all participants in this discussion have been trying to "solve" the issue in different ways. 1) Remove the DTD fragments and replace them by english language descriptions. This actually triggered this thread (see title) because in rfc2528bis, some of the information present in rfc2518 was lost. 2) Extend/fix the DTD: we can do better with DTD notation but not much better. However there's a readability cost associated with these changes, and it's unclear wether that cost justifies the small increase in precision. 3) Move to XML Schema: only solves few of the problems that we have with the DTD notation, yet has a big problem with readability in the spec. 4) Move to something else: I was proposing RelaxNG (Compact Notation) because it solves all technical issues that we have. Drawback: some think that the fact that it's not as popular as DTD or XML Schema makes it unsuited for usage in a RFC. So it seems there's no support at all for a major change. Let's fix just the issues that we have with the DTD fragments. I'd suggest to re-read what the ordering spec currently says and, if necessary, to clarify it. Then we can use that in all other specs. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 17:47: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 RAA25748 for ; Fri, 17 Oct 2003 17:47:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 5120AA0870; Fri, 17 Oct 2003 17:48:06 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0BF9FA0976 for ; Fri, 17 Oct 2003 17:48:03 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B29AC13B4B; Fri, 17 Oct 2003 17:48:02 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail11.atl.registeredsite.com (mail11.atl.registeredsite.com [64.224.219.85]) by dr-nick.w3.org (Postfix) with ESMTP id 7C35113A62 for ; Fri, 17 Oct 2003 17:48:02 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail11.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9HLm2hM016871 for ; Fri, 17 Oct 2003 17:48:02 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172] (may be forged)) by infonuovo.com (8.8.7/8.8.5) with SMTP id OAA08611 for ; Fri, 17 Oct 2003 14:48:01 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "WebDAV Discussion List" Date: Fri, 17 Oct 2003 14:47:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: duplicate properties (was rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAEEJADDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017214806.5120AA0870@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 17:48:06 -0400 (EDT) Content-Transfer-Encoding: quoted-printable This note seems to have gone into a hole somewhere [it is not on the = archive] so I am resending it for completeness. Now if I could figure = out why I receive two of everything, that would be a good thing. -- dh -----Original Message----- From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] Sent: Tuesday, October 14, 2003 12:31 To: Julian Reschke; w3c-dist-auth@w3.org Subject: RE: duplicate properties and such (was rfc2518bis DAV DTD ...) Julian, Thanks for the comment on the example. I did that intentionally, = because there is an existing example (8.2.1 in bis-04) that repeats a = property, in effect, but inside of a wrapper, and I wanted to see what = attention this one would attract. (There is also an error in my element example. I left out the = "/" before ">" of the empty element. It should be = .) There is an issue that will arise with the unique property requirement. = Other uses of ad hoc properties in XML applications are not limited to = single occurrences of property elements for the same property. = (Property-asserting elements are seen as predicates or establishment of = a relationship, and many-to-many is commonplace.) The example I gave = would be appropriate if I was mapping something from RDF to DAV, for = example. This may become a problem as the Semantic Web and DAV collide. = =20 I assume that the appropriate DAV treatment would be to wrap a bundle of = RDF properties inside a single DAV property and pray. This is a new = topic and probably becomes something to identify as an open/future item = without resolution in 2518bis. It is part of the overall question of = relationship to other applicable standards, such as XML digital = signatures and encryption, XML Schema, SOAP/XML-HTTP, UDDI, RDF-XML, and = other Web Service and Semantic Web specifications that may have some = bearing on DAV applications. =20 -- Dennis Side Note: From my background with DMS and especially DMA, I would find = it natural to prohibit duplicate assertions about the same property. =20 Having worked with other XML-based specifications for a while, I see = that is not the course being taken. What I learn from that is that I = have been subjecting the protocol to the constraints of an envisioned = storage model: I am using ideas about storage-system implementation to = place tacit constraints on the request/response protocol for which there = is no abstract justification. That's a lesson for me. =20 It's apparently a lesson in W3C work too. Later specifications are = being abstracted above the XML InfoSet and even above XML altogether. = The difference in specification models between SOAP 1.1 and SOAP 1.2 is = informative in that regard. The same arises in the Working Documents = for revisions of RDF and in other Semantic Web specifications (e.g., = OWL). I don't know what the lesson might be for DAV. -- dh -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, October 14, 2003 07:43 To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...) Dennis, [ ... ] > ... > > > > > Dennis E. Hamilton > > xmlns:dc=3D"http://purl.org/dc/elements/1.1/"> > Orcmid, junior nymph of the Orcan Conclave > > > > Nit: that isn't a meaningful request. Each WebDAV property only can have = a single value, so having it twice in propertyupdate will just result in = the "last" value being set. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 19:32: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 TAA29513 for ; Fri, 17 Oct 2003 19:32:58 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1693BA09B3; Fri, 17 Oct 2003 19:33:06 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EC5D7A09B3 for ; Fri, 17 Oct 2003 19:33:03 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D0F6E135E7; Fri, 17 Oct 2003 19:33:03 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail5.atl.registeredsite.com (mail5.atl.registeredsite.com [64.224.219.79]) by dr-nick.w3.org (Postfix) with ESMTP id B341B135E1 for ; Fri, 17 Oct 2003 19:33:03 -0400 (EDT) Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged)) by mail5.atl.registeredsite.com (8.12.9/8.12.9) with ESMTP id h9HNWxsL009510; Fri, 17 Oct 2003 19:32:59 -0400 Received: from compagno (tukwdslgw6poolo172.tukw.qwest.net [67.42.110.172] (may be forged)) by infonuovo.com (8.8.7/8.8.5) with SMTP id QAA14225; Fri, 17 Oct 2003 16:32:59 -0700 (PDT) Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , Date: Fri, 17 Oct 2003 16:32:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: DTD-Fragment Approach (was Re: How to use DTDs, or not to ...) X-Archived-At: http://www.w3.org/mid/FFEPLLNFAHGBKNENFGPAGEJHDDAA.dennis.hamilton@acm.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017233306.1693BA09B3@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 19:33:06 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Good summary. I looked at the ordering specification. =20 1. I would suggest that some other form than ANY be used to mean that = there is an open content model with nothing said about it. Maybe an = invented form like "(...)" [or even %:... oddly enough] 2. With regard to the statement about ordering, it may be necessary to = say more. For example, in I would read this, in terms of order being unimportant, as providing for = at most one element, none or more and = extension elements, all in any order. I assume that if there are multiple elements, it is the = ones after the first that must be ignored if that usage is not = understood. On the other hand, an example in rfc2518 section 23 (and = bis-04 section 24) would indicate that a second occurrence of = is illegal and must be rejected with a 400 response. = (See (4) below). 3. A lax DTD fragment for all of that is something like where other conditions on multiplicity are stated in the text [and, in = this example, %:... can be defaulted to the empty string or some = hypothetical sequence beginning with "| ". =20 3.1 Does appearance of mixed content qualify as an extended use? Then = it would be If you really mean that ANY DAV-defined element can potentially be here = as well as any other (i.e., , , and so on), that = is the best that can be done in a DTD that does not exclude any = possibly-valid element, leaving the rest up to the DAV processor. 3.2 In a narrower notion of what an admissible extension could be, it = might be more useful to consider with the side stipulation that there be at most one = element. I would give this the reading that there may be any number of = potentially-acceptable -extension content elements other = than those explicitly identified. That is, the conditions on admissible = ordering-type and order-member occurrences are not modifiable by = extension to the element. 4. Is there any more-precise definition of extension than the one in = this part of the ordered-collection specification and in rfc2518 section = 23? (rfc2518bis-04 section 24?) =20 4.1 I am thinking there is a difference between an extension and an = application involving ad hoc additions, as in the content of a = element, but perhaps it is all regarded as extension. =20 4.2 It also would seem, based on the example of a mandatory 400 = response, that extensions cannot contradict the multiplicity given in = 2518 or any extension specification (as honored in 3.2). =20 It's a mystery. -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke Sent: Friday, October 17, 2003 13:45 To: w3c-dist-auth@w3.org Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery) [ ... ] So it seems there's no support at all for a major change. Let's fix just = the issues that we have with the DTD fragments. I'd suggest to re-read what = the ordering spec currently says and, if necessary, to clarify it. Then we = can use that in all other specs. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 19:56: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 TAA00491 for ; Fri, 17 Oct 2003 19:56:11 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 17408A05AE; Fri, 17 Oct 2003 19:56:19 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 03DF1A05AE for ; Fri, 17 Oct 2003 19:56:17 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id B4C34136FE; Fri, 17 Oct 2003 19:56:16 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 4E57013750 for ; Fri, 17 Oct 2003 19:56:16 -0400 (EDT) Received: (qmail 9958 invoked by uid 65534); 17 Oct 2003 23:56:08 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp016) with SMTP; 18 Oct 2003 01:56:08 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "WebDAV Discussion List" Date: Sat, 18 Oct 2003 01:55:52 +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: duplicate properties (was rfc2518bis DAV DTD ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEIAINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031017235619.17408A05AE@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 19:56:19 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Friday, October 17, 2003 11:48 PM > To: WebDAV Discussion List > Subject: duplicate properties (was rfc2518bis DAV DTD ...) > > > > This note seems to have gone into a hole somewhere [it is not on > the archive] so I am resending it for completeness. Now if I > could figure out why I receive two of everything, that would be a > good thing. -- dh People pressing "reply to all"... > Julian, > > Thanks for the comment on the example. I did that intentionally, > because there is an existing example (8.2.1 in bis-04) that > repeats a property, in effect, but inside of a wrapper, and I > wanted to see what attention this one would attract. Could you be more specific? I don't see a duplicate property name there. > (There is also an error in my element example. I left > out the "/" before ">" of the empty element. It should be > .) > > There is an issue that will arise with the unique property > requirement. Other uses of ad hoc properties in XML applications > are not limited to single occurrences of property elements for > the same property. (Property-asserting elements are seen as > predicates or establishment of a relationship, and many-to-many > is commonplace.) The example I gave would be appropriate if I > was mapping something from RDF to DAV, for example. This may > become a problem as the Semantic Web and DAV collide. Well, that's how WebDAV works. If you need multi-valued properties (such as when mapping DC to WebDAV properties), you need to come up with a WebDAV-compatible way to do it. See for instance: > I assume that the appropriate DAV treatment would be to wrap a > bundle of RDF properties inside a single DAV property and pray. > This is a new topic and probably becomes something to identify as No, it's absolutely not new. See above. In fact, our server already supports extraction of DC-encoded metadata from HTML content and mapping to WebDAV properties. If there are more people interested on a common format, please email me. > an open/future item without resolution in 2518bis. It is part of > the overall question of relationship to other applicable > standards, such as XML digital signatures and encryption, XML > Schema, SOAP/XML-HTTP, UDDI, RDF-XML, and other Web Service and > Semantic Web specifications that may have some bearing on DAV > applications. > > -- Dennis > > Side Note: From my background with DMS and especially DMA, I > would find it natural to prohibit duplicate assertions about the > same property. > > Having worked with other XML-based specifications for a while, I > see that is not the course being taken. What I learn from that > is that I have been subjecting the protocol to the constraints of > an envisioned storage model: I am using ideas about > storage-system implementation to place tacit constraints on the > request/response protocol for which there is no abstract > justification. That's a lesson for me. > > It's apparently a lesson in W3C work too. Later specifications > are being abstracted above the XML InfoSet and even above XML > altogether. The difference in specification models between SOAP > 1.1 and SOAP 1.2 is informative in that regard. The same arises > in the Working Documents for revisions of RDF and in other > Semantic Web specifications (e.g., OWL). I don't know what the > lesson might be for DAV. -- dh At the end of the day, that's just an aspect of marshalling in WebDAV. As properties can have arbitrary XML content, there's no problem mapping these multi-valued properties to WebDAV. The only things that's missing is a common format. So far, the interest in agreeing on one seems to be little. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 20:17:39 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 UAA01002 for ; Fri, 17 Oct 2003 20:17:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 1D1AAA0A12; Fri, 17 Oct 2003 20:17:47 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A47C3A0A12 for ; Fri, 17 Oct 2003 20:17:44 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3CF9E13C91; Fri, 17 Oct 2003 20:17:44 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C75CB13C2A for ; Fri, 17 Oct 2003 20:17:43 -0400 (EDT) Received: (qmail 7981 invoked by uid 65534); 18 Oct 2003 00:17:34 -0000 Received: from pD950C24E.dip.t-dialin.net (HELO lisa) (217.80.194.78) by mail.gmx.net (mp022) with SMTP; 18 Oct 2003 02:17:34 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: , "Julian Reschke" , Date: Sat, 18 Oct 2003 02:17:09 +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: DTD-Fragment Approach (was Re: How to use DTDs, or not to ...) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEIBINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031018001747.1D1AAA0A12@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 20:17:47 -0400 (EDT) Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton > Sent: Saturday, October 18, 2003 1:33 AM > To: Julian Reschke; w3c-dist-auth@w3.org > Subject: RE: DTD-Fragment Approach (was Re: How to use DTDs, or not to > ...) > > > > Good summary. > > I looked at the ordering specification. > > 1. I would suggest that some other form than ANY be used to > mean that there is an open content model with nothing said about > it. Maybe an invented form like "(...)" [or even %:... oddly enough] Yes, I agree that if we don't mean "ANY", we shouldn't say so. Or if we continue to say so, that ANY comes with a comment line saying what it means. See, for instance: (side note: the HTML versions of the RFCs on our web page contain DCMI metadata encoded in the format specified in RFC2774) > 2. With regard to the statement about ordering, it may be > necessary to say more. For example, in > > > > I would read this, in terms of order being unimportant, as > providing for at most one element, none or more > and extension elements, all in any order. Correct. > I assume that if there are multiple elements, it > is the ones after the first that must be ignored if that usage is Actually, multiple instances of ordering-type are illegal. That's why the DTD says "?". > not understood. On the other hand, an example in rfc2518 section > 23 (and bis-04 section 24) would indicate that a second > occurrence of is illegal and must be rejected > with a 400 response. (See (4) below). Right. > 3. A lax DTD fragment for all of that is something like > > > > where other conditions on multiplicity are stated in the text > [and, in this example, %:... can be defaulted to the empty string > or some hypothetical sequence beginning with "| ". in Relax NG Compact Syntax, this would be: namespace dav = "DAV:" orderpatch = element dav:oderpatch (ordering-type? & order-member* & EXT*) ordering-type = element dav:ordering-type ... (and so on...) So in theory we could just borrow the "&" notation (which is the same as "," except that ordering isn't significant), and use EXT (or any other identifier) to denote elemements not defined by the spec (and other base specs). So I'd prefer: (of course this is also a demonstration about why the RelaxNG Compact Notation is very popular around former DTD users). > 3.1 Does appearance of mixed content qualify as an extended > use? Then it would be > > order-member %:... )* > > > If you really mean that ANY DAV-defined element can potentially > be here as well as any other (i.e., , , > and so on), that is the best that can be done in a DTD that does > not exclude any possibly-valid element, leaving the rest up to > the DAV processor. Actually, RFC2518 is vague about how mixed content and extensibility work together. Technically it says that anything can be extended, however I assume that almost all implementations get very confused when I start extending elements with text content, such as 123 although I think this conforms to the spec. So a conservative approach would be to limit extensibility to elements that do not have text content, and not to allow text content as extension. > 3.2 In a narrower notion of what an admissible extension could > be, it might be more useful to consider > > %orderpatch:... )* > > > with the side stipulation that there be at most one > element. I would give this the reading that > there may be any number of potentially-acceptable > -extension content elements other than those > explicitly identified. That is, the conditions on admissible > ordering-type and order-member occurrences are not modifiable by > extension to the element. %orderpatch would need to represent all elements not defined in the relevant specs, in RNC: EXT = * - (dav:allprop | dav:href | dav:multistatus | dav:prop | dav:propfind | dav:propname ) { any } (of course the list is incomplete...). > 4. Is there any more-precise definition of extension than the > one in this part of the ordered-collection specification and in > rfc2518 section 23? (rfc2518bis-04 section 24?) No. > 4.1 I am thinking there is a difference between an extension > and an application involving ad hoc additions, as in the content > of a element, but perhaps it is all regarded as extension. We discussed this just a few days ago. I wouldn't call the content model of "extensible". Whatever you put there is defined by the spec (as identifier of a property). I'd like to use the term "extensibility" when we speak about things *not* defined by the spec (such as adding new child elements to DAV:response). > 4.2 It also would seem, based on the example of a mandatory 400 > response, that extensions cannot contradict the multiplicity > given in 2518 or any extension specification (as honored in 3.2). I didn't get that. Could you please explain? > It's a mystery. I don't think it's that bad. Except for one particular client, it doesn't seem to have caused actual interoperability problems so far. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 17 21:20:03 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 VAA02584 for ; Fri, 17 Oct 2003 21:20:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 8E3DBA08B1; Fri, 17 Oct 2003 21:20:11 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 4A2C7A0A38 for ; Fri, 17 Oct 2003 21:20:07 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id D187913D2F; Fri, 17 Oct 2003 21:20:06 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from SVSMAILBOX.svsexch.com (smgw.apcn.net [216.77.148.4]) by dr-nick.w3.org (Postfix) with SMTP id 4A1A413D3B for ; Fri, 17 Oct 2003 21:20:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39516.AF2B7BAC" Date: Fri, 17 Oct 2003 21:25:15 -0400 Message-ID: <98C8414C4EDEE644AFD3D6485B44896A409AE3@SVSMAILBOX.svsexch.com> Thread-Topic: 3xx vs RFC2518 vs redirect-ref spec Thread-Index: AcOU5XT42lDMw7h5RyWgf5a5j899WAAMG/kQ From: "Chris Gentile" To: "Lisa Dusseault" , Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/98C8414C4EDEE644AFD3D6485B44896A409AE3@SVSMAILBOX.svsexch.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031018012011.8E3DBA08B1@frink.w3.org> Resent-Date: Fri, 17 Oct 2003 21:20:11 -0400 (EDT) This is a multi-part message in MIME format. ------_=_NextPart_001_01C39516.AF2B7BAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please remove me from your list. =20 =20 Christopher Gentile, Ph.D. Executive Director, Sagemont Virtual School =20 Office: 305-867-8825 Toll Free: 877-357-0109 Cell: 954-410-8011 Fax: 305-867-6278 -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com]=20 Sent: Saturday, October 18, 2003 2:27 AM To: w3c-dist-auth@w3.org Subject: RE: 3xx vs RFC2518 vs redirect-ref spec =20 This proposal clearly has a lot of support. I too favour a single client-feature-advertisement header. However, I'd like to caution the group that we won't be able to demonstrate the interoperability of this header, and thus we take the risk that this won't be considered a suitable feature to take to the next standards phase (draft standard). =20 =20 I see no problem with defining the exact same header in the redirect spec (or another), with a note that other extensions are encouraged to use the same header. Since this community is very good about reusing this kind of solution, I'm not worried that its location will be a problem. It's much like the DeltaV preconditions/postconditions framework which has already been reused by ACL and others without needing to modify 2518. =20 If there's still consensus to add to 2518bis specifically, let me know (individually is fine) and I'll add it to the document. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Elias Sinderson Sent: Wednesday, October 15, 2003 3:41 PM To: w3c-dist-auth@w3.org Subject: Re: 3xx vs RFC2518 vs redirect-ref spec I agree, let's add this to 2518bis - the proposed mechnism is simple and easy for developers to understand. =09 =09 Elias =09 =09 Geoffrey M Clemm wrote: =09 =09 =09 I support this addition to RFC2518bis.=20 =09 I believe it is a key mechanism needed for servers to properly support=20 the various current (and future) WebDAV extensions.=20 =09 Cheers,=20 Geoff=20 =09 Julian wrote on 10/14/2003 09:53:30 AM: =09 >=20 > > OK, > > > > so we probably should put it onto the issues list (so that it doesn't get > lost). >=20 > Here's a proposal for the issues list: >=20 >=20 > Issue DAV_REQUEST_HEADER >=20 > RFC 2518 provides a mechanism (the "DAV" response header) for a server to > indicate to a client that it supports a specific WebDAV option (e.g. "1", > "2", "version-control", etc.), but there is no complementary mechanism for a > client to indicate to a server that it understands a specific WebDAV option. > This becomes an issue when a WebDAV extension (or revision) needs to change > response formats in a way that possibly break existing clients. Detecting > client features based on a single, well-defined request header will work > better than (for instance) relying on custom headers (specified by each > extension) or "User-Agent". >=20 > Suggested resolution: allow the use of the "DAV" header as a request header, > with the same set of values that are defined for the "DAV" > response header. >=20 >=20 > Regards, Julian >=20 > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >=20 =20 ------_=_NextPart_001_01C39516.AF2B7BAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Please remove me from your = list.

 

 

Christopher = Gentile, Ph.D.

Executive = Director, Sagemont Virtual School

 

Office: &nbs= p;   305-867-8825

Toll Free: = 877-357-0109

Cell:  =       954-410-8011

Fax:  &= nbsp;     305-867-6278

-----Original = Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Saturday, October = 18, 2003 2:27 AM
To: = w3c-dist-auth@w3.org
Subject: RE: 3xx vs = RFC2518 vs redirect-ref spec

 

This proposal = clearly has a lot of support.  I too favour a single = client-feature-advertisement header. However, I'd like to caution the group that we won't be able to demonstrate the interoperability of this header, and thus we take the = risk that this won't be considered a suitable feature to take to the next = standards phase (draft standard). 

 

I see no problem = with defining the exact same header in the redirect spec (or another), with a = note that other extensions are encouraged to use the same header.  Since = this community is very good about reusing this kind of solution, I'm not = worried that its location will be a problem.  It's much like the DeltaV preconditions/postconditions framework which has already been reused by = ACL and others without needing to modify 2518.

 

If there's still consensus to add to 2518bis specifically, let me know (individually is = fine) and I'll add it to the document.

 

Lisa

-----Original Message-----
From: = w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Elias Sinderson
Sent: Wednesday, October = 15, 2003 3:41 PM
To: = w3c-dist-auth@w3.org
Subject: Re: 3xx vs = RFC2518 vs redirect-ref spec

I agree, let's add this to 2518bis - the = proposed mechnism is simple and easy for developers to understand.


Elias


Geoffrey M Clemm wrote:


I support this addition to RFC2518bis.

I believe it is a key mechanism needed for servers to properly = support
the various current (and future) WebDAV extensions.

Cheers,
Geoff

Julian wrote on 10/14/2003 09:53:30 AM:

>
> > OK,
> >
> > so we probably should put it = onto the issues list (so that it doesn't get
> lost).
>
> Here's a proposal for the issues = list:
>
>
> Issue = DAV_REQUEST_HEADER
>
> RFC 2518 provides a mechanism (the "DAV" response header) for a server to
> indicate to a client that it = supports a specific WebDAV option (e.g. "1",
> "2", = "version-control", etc.), but there is no complementary mechanism for a
> client to indicate to a server that = it understands a specific WebDAV option.
> This becomes an issue when a WebDAV = extension (or revision) needs to change
> response formats in a way that = possibly break existing clients. Detecting
> client features based on a single, well-defined request header will work
> better than (for instance) relying = on custom headers (specified by each
> extension) or = "User-Agent".
>
> Suggested resolution: allow the use = of the "DAV" header as a request header,
> with the same set of values that are = defined for the "DAV"
> response header.
>
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

 

=00 ------_=_NextPart_001_01C39516.AF2B7BAC-- From w3c-dist-auth-request@w3.org Sat Oct 18 00:31: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 AAA06654 for ; Sat, 18 Oct 2003 00:31:38 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 9CFA6A0AC2; Sat, 18 Oct 2003 00:31:45 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id B9392A0B00 for ; Sat, 18 Oct 2003 00:31:34 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DCB831402D; Sat, 18 Oct 2003 00:30:35 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from eis-msg-052.jpl.nasa.gov (eis-msg-052.jpl.nasa.gov [137.78.160.72]) by dr-nick.w3.org (Postfix) with ESMTP id 8FDBA1402B for ; Sat, 18 Oct 2003 00:30:35 -0400 (EDT) Received: from cse.ucsc.edu (mac02190081349.jpl.nasa.gov [137.78.230.43]) by eis-msg-052.jpl.nasa.gov (8.12.10/8.12.10) with ESMTP id h9I4UXMs027006 for ; Fri, 17 Oct 2003 21:30:34 -0700 (PDT) Message-ID: <3F90C18F.3080500@cse.ucsc.edu> Date: Fri, 17 Oct 2003 21:29:03 -0700 From: Elias Sinderson User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/3F90C18F.3080500@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031018043145.9CFA6A0AC2@frink.w3.org> Resent-Date: Sat, 18 Oct 2003 00:31:45 -0400 (EDT) Content-Transfer-Encoding: 7bit I agree, the best approach would be to specify the basic DAV request header mechanism in 2518bis. The other WebDAV specs can then define additional values, thereby indicating other client capabilities. The logic behind the DAV request header seems straightforward enough to allow for interoperable implementations before 2518 moves to the draft standard phase. Regards, Elias Geoffrey M Clemm wrote: >I would like to see it added specifically to 2518bis. > >I believe that there will be plenty of time between now and when >2518bis goes to the IESG for a sufficient number of clients and >servers to add in the DAV request header (and if there is one >feature that is unlikely to introduce an interoperability problem, >this is probably it :-). > >Cheers, >Geoff > > >Lisa wrote on 10/18/2003 03:26:38 AM: > > > >>This proposal clearly has a lot of support. I too favour a single >>client-feature-advertisement header. However, I'd like to caution >>the group that we won't be able to demonstrate the interoperability >>of this header, and thus we take the risk that this won't be >>considered a suitable feature to take to the next standards phase >>(draft standard). >> >>I see no problem with defining the exact same header in the redirect >>spec (or another), with a note that other extensions are encouraged >>to use the same header. Since this community is very good about >>reusing this kind of solution, I'm not worried that its location >>will be a problem. It's much like the DeltaV >>preconditions/postconditions framework which has already been reused >>by ACL and others without needing to modify 2518. >> >>If there's still consensus to add to 2518bis specifically, let me >>know (individually is fine) and I'll add it to the document. >> >>Lisa >>-----Original Message----- >>From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] >> >> From w3c-dist-auth-request@w3.org Sat Oct 18 20:53:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14751 for ; Sat, 18 Oct 2003 20:53:40 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id D9E4DA05A7; Sat, 18 Oct 2003 20:53:47 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 87585A05A7 for ; Sat, 18 Oct 2003 20:53:43 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 48A3B1365A; Sat, 18 Oct 2003 20:53:43 -0400 (EDT) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id F09C313504 for ; Sat, 18 Oct 2003 20:53:42 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AB1pG-0007vk-00 for w3c-dist-auth@w3c.org; Sun, 19 Oct 2003 00:53:42 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AB1pF-0007vZ-00 for w3c-dist-auth@w3c.org; Sun, 19 Oct 2003 00:53:41 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 18 Oct 2003 17:52:38 -0700 Message-ID: <000301c395db$4d28ecd0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Subject: FW: 58th IETF - DRAFT Agenda X-Archived-At: http://www.w3.org/mid/000301c395db$4d28ecd0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031019005347.D9E4DA05A7@frink.w3.org> Resent-Date: Sat, 18 Oct 2003 20:53:47 -0400 (EDT) Content-Transfer-Encoding: quoted-printable The WebDAV WG meeting is TENTATIVELY scheduled for Thursday afternoon. Lisa -----Original Message----- From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org] On Behalf = Of agenda@ietf.org Sent: Friday, October 17, 2003 3:18 PM To: wgchairs@ietf.org; bofchairs@ietf.org Cc: iesg@ietf.org; agenda@ietf.org Subject: 58th IETF - DRAFT Agenda DRAFT Agenda of the 58th IETF Meeting November 9-14, 2003 (As of October 17, 2003) SUNDAY, November 9, 2003 1000-1700 IEPG Meeting 1200-1900 Registration - Ballroom Foyer, 3rd Floor 1330-1430 Newcomer's Training - Salon B 1330-1500 Editor's Training - Conrad C 1330-1500 Intro WG Chairs Training - Conrad B 1500-1700 Security Tutorial - Salon B 1700-1900 Welcome Reception - Salon D MONDAY, November 10, 2003 0800-2000 IETF Registration - Ballroom Foyer, 3rd Floor 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 0900-1130 Morning = Sessions APP apparea Applications Open Area Meeting INT dnsext DNS Extensions WG INT ipoib IP over InfiniBand WG OPS ipfix IP Flow Information Export WG SEC msec Multicast Security WG SUB ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP lemonade Enhancements to Internet email to support diverse = service environments WG INT mip4 Mobility for IPv4 WG OPS mboned MBONE Deployment WG RTG forces Forwarding and Control Element Separation WG SEC ipsec IP Security Protocol WG TSV tsvwg Transport Area Working Group 1500-1530 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor 1530-1730 Afternoon Sessions II APP iea Internationalizing Email Addresses BOF INT mip6 Mobility for IPv6 WG OPS netconf Network Configuration WG RTG ospf Open Shortest Path First IGP WG SEC pkix Public-Key Infrastructure (X.509) WG TSV dccp Datagram Congestion Control Protocol WG TSV rserpool Reliable Server Pooling WG 1730-1930 Break 1930-2200 Evening Sessions APP geopriv Georgraphic Location/Privacy WG INT eap Extensible Authentication Protocol WG OPS dnsop Domain Name System Operations WG OPS rmonmib Remote Network Monitoring WG RTG rtgarea Routing Area Meeting SEC ipsp IP Security Policy WG TSV pwe3 Pseudo Wire Emulation Edge to Edge WG TUESDAY, November 11, 2003 0800-1800 IETF Registration - Ballroom Foyer, 3rd Floor 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 0900-1130 Morning = Sessions APP calsch Calendaring and Scheduling WG INT ipv6 IP Version 6 WG OPS psamp Packet Sampling WG SEC ltans Long-Term Archive and Notary Services WG SUB mpls Multiprotocol Label Switching WG TSV rddp Remote Direct Data Placement WG TSV sipping Session Initiation Proposal Investigation WG 1130-1300 Break 1300-1400 Afternoon Sessions I APP ldapbis LDAP (v3) Revsion WG Open Trading Protocol WG INT send Securing Neighbor Discovery WG OPS dnsop Domain Name System Operations WG OPS ipcdn IP over Cable Data Network WG RTG pim Protocol Independent Multicast WG SEC enroll Credential and Provisioning BOF TSV enum Telephone Number Mapping WG 1415-1515 Afternoon Sessions II APP ldup LDAP Replication/Duplication/Update Protocols WG INT magma Multicast & Anycast Group Membership WG OPS pana Protocol for Carrying Authentication for Network = Access WG OPS multi6 Site Multihoming in IPv6 WG SEC krb-wg Kerberos WG TSV alias Access Lind Intermediaries Assisting Services BOF 1515-1545 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor 1545-1645 Afternoon Sessions III APP trade Internet Open Trading Protocol WG INT eap Extensible Authentication Protocol WG RTG ssm Source-Specific Multicast WG SEC sasl Simple Authentication and Security Layer WG TSV midcom Middlebox Communication WG TSV nsis Next Steps in Signaling WG 1700-1800 Afternoon Sessions IV APP opes Open Pluggable Edge Services WG INT ipv6 IP Version 6 WG SEC smime S/MIME Mail Security WG TSV rmt Reliable Multicast Transport WG WEDNESDAY, November 12, 2003 0800-1800 IETF Registration - Ballroom Foyer, 3rd Floor 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 0900-1130 Morning = Sessions APP impp Instant Messaging and Presence Protocol WG INT l3vpn Layer 3 Virtual Private Networks WG OPS netconf Network Configuration WG TSV avt Audio/Video Transport WG TSV iptel IP Telephony WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP crisp Cross Registry Information Service Protocol WG GEN problem Problem WG INT ipv6 IP Version 6 WG RTG rpsec Routing Protocol Security Requirements WG TSV nfsv4 Network File System Version 4 WG TSV sip Session Initiation Protocol WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor 1530-1730 Afternoon Sessions II APP imapext Internet Message Access Protocol Extensions WG INT l2vpn Layer 2 Virtual Private Networks WG INT nemo Network Mobility WG OPS mboned MBONE Deployment WG TSV xcon Centralized Conferencing WG 1730-1930 Break 1930-2200 Open IESG Plenary THURSDAY, November 13, 2003 0800-1800 IETF Registration - Ballroom Foyer, 3rd Floor 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 0900-1130 Morning = Sessions APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT dhc Dynamic Host Configuration WG OPS grow Global Routing Operations WG RTG vrrp Virtual Router Redundancy Protocol WG SEC pki4ipsecProfiling Use of PKI in IPSEC BOF SUB tewg Internet Traffic Engineering WG TSV nsis Next Steps in Signaling WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT hipbof Host Identity Protocol BOF OPS aaa Authentication, Authorization and Accounting WG OPS entmib Entity MIB WG RTG idr Inter-Domain Routing WG SEC inch Extended Incident Handling WG TSV speechsc Speech Services Control WG 1500-1530 Break (Refreshments provided) - Ballroom Foyer, 3rd Floor 1530-1730 Afternoon Sessions II APP webdav WWW Distributed Authoring and Versioning WG INT mipshop MIPv6 Signaling and Handoff Optimization BOF OPS bmwg Benchmarking Methodology WG RTG manet Mobile Ad-hoc Networks WG SEC saag Open Security Area Directorate TSV sipping Session Initiation Proposal Investigation WG 1730-1930 Break 1930-2200 Open IAB Plenary FRIDAY, November 14, 2003 0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor 0900-1130 Morning Sessions APP xmpp Extensible Messaging and Presence Protocol WG OPS radext RADIUS EXTensions BOF TSV mmusic Multiparty Multimedia Session Control WG From w3c-dist-auth-request@w3.org Sun Oct 19 07:26: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 HAA05886 for ; Sun, 19 Oct 2003 07:26:40 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7D3ABA060A; Sun, 19 Oct 2003 07:26:47 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 08AD4A060A for ; Sun, 19 Oct 2003 07:26:45 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 8373513618; Sun, 19 Oct 2003 07:26:44 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id D818C134A8 for ; Sun, 19 Oct 2003 07:26:43 -0400 (EDT) Received: (qmail 7623 invoked by uid 65534); 19 Oct 2003 11:26:43 -0000 Received: from p3EE2473B.dip.t-dialin.net (HELO lisa) (62.226.71.59) by mail.gmx.net (mp025) with SMTP; 19 Oct 2003 13:26:43 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Sun, 19 Oct 2003 13:26:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEJIINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031019112647.7D3ABA060A@frink.w3.org> Resent-Date: Sun, 19 Oct 2003 07:26:47 -0400 (EDT) Content-Transfer-Encoding: 7bit Lisa, > This proposal clearly has a lot of support. I too favour a single > client-feature-advertisement header. However, I'd like to caution the group > that we won't be able to demonstrate the interoperability of this header, > and thus we take the risk that this won't be considered a suitable feature > to take to the next standards phase (draft standard). If we define the following: - A DAV: request header MAY be sent by the client indicating compliance to a specific WebDAV feature (in the same syntax as defined for the DAV: response header) *and* - Each protocol extension must explicitly declare what sending a specific feature token indicates *and* - If there's no such definition, clients MUST not send that token (thus we can avoid the situation where clients start enumerating all kinds of extensions although this info is completely useless to the server) then there shouldn't be an issue at all. RFC2518bis would just provide the marshalling framework for other specs, and *those* would need to show interoperability. The first canditates for actually *using* this IMHO are - binding spec (client indicates that it knows about new bind-loop-detected condition in multistatus response) and - redirect ref spec (client indicates that it knows how to deal with Location info in multistatus) (side note: interestingly, both use cases are about PROPFIND response formats). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Oct 19 21:42: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 VAA25896 for ; Sun, 19 Oct 2003 21:42:45 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B674FA06BC; Sun, 19 Oct 2003 21:42:52 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id EE0C5A06BC for ; Sun, 19 Oct 2003 21:42:49 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id C105213A39; Sun, 19 Oct 2003 21:42:49 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by dr-nick.w3.org (Postfix) with ESMTP id 4547A13A36 for ; Sun, 19 Oct 2003 21:42:49 -0400 (EDT) Received: from Tycho (dsl3-63-249-68-18.cruzio.com [63.249.68.18]) by mail.cruzio.com with SMTP id h9K1glO0058844 for ; Sun, 19 Oct 2003 18:42:47 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Sun, 19 Oct 2003 18:42:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C39670.CD25DCA0" 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 Subject: FW: WebDAV & MacOS X AppleDouble Format X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAENOJMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031020014252.B674FA06BC@frink.w3.org> Resent-Date: Sun, 19 Oct 2003 21:42:52 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C39670.CD25DCA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit WebDAV & MacOS X AppleDouble FormatAccidentally caught by the spam filter. I have added frank.lowney@gcsu.edu to the accept2 list. - Jim -----Original Message----- From: Frank Lowney [mailto:frank.lowney@gcsu.edu] Sent: Sunday, October 19, 2003 5:16 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV & MacOS X AppleDouble Format As most here know, MaxOS X clients (OS built-in WebDAV support tested) send files to a WebDAV-enabled server in AppleDouble format. As I understand it, this is done because files on MacOS X systems have two forks, one for data and another for "resources." The data fork file inherits the original name of the file whereas the resource fork has the characters "._" prepended. This is done in spite of the fact that the resource fork file serves no useful purpose on the server. Thus, my question is why upload this vestigial tail? The "._" prefix makes the file invisible on most but not all system views. Invisible or otherwise, these files accumulate and present a variety of issues to end users and system administrators alike. The only use for these files that I can imagine is that they serve a "round trip" purpose. If the resource fork of a file contains information on the client's local system and is then uploaded to the server and subsequently downloaded to another client machine, does the resource data become reunited with the data fork? If so, one might have an argument to support this practice, albeit a flawed one. One flaw concerns the degree to which these two files can be kept paired together in the same directory. What happens if the resource fork file and the data fork file get separated from one another or mixed-up with files of the same name in other directories? Another flaw concerns common HTML files such as index.html where it is particularly difficult to imagine resource information of sufficient value to justify all of this juggling. I have an indirect line of communication with an Apple engineer who challenged me to show how this was a problem so that he could bring the matter up with his colleagues. If anyone here can add to or clarify what I have offered, I'd be happy to pass that on as well. ----------- The engineer's challenge & my reply: ------------------ ------ Forwarded Messag Does the Mac OS X 10.x WebDAV client convert resource forks into ._ files when copying files to a WebDAV server? If that is the question, the answer is yes. If this is a problem, I need impact information to lobby for changing this behavior and potentially make it configurable. The context. Our experience covers three types of webserver as follows: 1) Apache on MacOS X and MacOS X Server 2) WebSTAR V on MacOS X 3) BEA WebLogic on Solaris (in support of the WebCT Vista Courseware Management System) The problem. The MacOS X Client (what you get via Command-K from the Finder) transmits files via WebDAV in Apple Double format. Thus a file named mypix.jpeg on a local MacOS X system arrives on the server as two files as follows: mypix.jpeg ;containing data fork data ._mypix.jpg ;containing resource fork data The resource data file is normally invisible on most Unix based systems because its name begins with "._" but these files do accumulate over time. Their numbers and total disk space requirements present a number of potential issues including making diagnostic work unnecessarily difficult. These resource fork files are totally useless on the webserver. They do not add to any functionality on the webserver. These files are not always invisible and can confuse both sysadmins using a CLI as well as end users who may see them via a web-based editing system. Examples of the latter include the current version of WebCT Vista, an enterprise-level Courseware Management System that relies upon a BEA Weblogic webserver and an Oracle DB. WebDAV support in Vista is complimented by a web-based file manager that is necessary to certain operations not possible via WebDAV having to do with what Vista calls "shared resources." In the file manager, these "._" prefixed files are visible and a source of great confusion with end users (mostly university faculty) who think that they are seeing double, don't know which of the two files to create links to and so on. Our faculty also use Windows XP where none of these issues obtain. I hope that this impact information is helpful. -- ===================================================================== Dr. Frank Lowney frank.lowney@gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. Please note that my new e-mail address is: frank.lowney@gcsu.edu ------=_NextPart_000_000B_01C39670.CD25DCA0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WebDAV & MacOS X AppleDouble Format
Accidentally caught by the spam filter. I = have added frank.lowney@gcsu.edu to the = accept2=20 list.
 
-=20 Jim
-----Original Message-----
From: Frank Lowney=20 [mailto:frank.lowney@gcsu.edu]
Sent: Sunday, October 19, 2003 = 5:16=20 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 WebDAV & MacOS X AppleDouble Format

As most here know, MaxOS X clients (OS built-in WebDAV support = tested) send=20 files to a WebDAV-enabled server in AppleDouble format.  As I = understand=20 it, this is done because files on MacOS X systems have two forks, one = for data=20 and another for "resources."  The data fork file inherits the = original name=20 of the file whereas the resource fork has the characters "._" = prepended. =20 This is done in spite of the fact that the resource fork file serves no = useful=20 purpose on the server.  Thus, my question is why upload this = vestigial=20 tail?

The "._" prefix makes  the file invisible on most but not all = system=20 views.  Invisible or otherwise, these files accumulate and present = a=20 variety of issues to end users and system administrators alike.

The only use for these files that I can imagine is that they serve = a "round=20 trip" purpose.  If the resource fork of a file contains information = on the=20 client's local system  and is then uploaded to the server and = subsequently=20 downloaded to another client machine, does the resource data become = reunited=20 with the data fork?  If so, one might have an argument to support = this=20 practice, albeit a flawed one.

One flaw concerns the degree to which these two files can be kept = paired=20 together in the same directory.  What happens if the resource fork = file and=20 the data fork file get separated from one another or mixed-up with files = of the=20 same name in other directories?  Another flaw concerns common HTML = files=20 such as index.html  where it is particularly difficult to imagine = resource=20 information of sufficient value to justify all of this juggling.

I have an indirect line of communication with an Apple engineer who = challenged me to show how this was a problem so that he could bring the = matter=20 up with his colleagues.  If anyone here can add to or clarify what = I have=20 offered, I'd be happy to pass that on as well.

----------- The engineer's challenge & my reply:=20 ------------------

------ Forwarded = Messag


Does the=20 Mac OS X 10.x WebDAV client convert resource forks into ._
files = when=20 copying files to a WebDAV server?

If that is the question, the = answer=20 is yes.

If this is a problem, I need impact information to = lobby for=20 changing
this behavior and potentially make = it=20 configurable.

The context.  Our experience covers three types of = webserver as=20 follows:

1) Apache on MacOS X and MacOS X Server

2) WebSTAR V on MacOS X

3) BEA WebLogic on Solaris (in support of the WebCT Vista = Courseware=20 Management System)

The problem.  The MacOS X Client (what you get via = Command-K=20 from the Finder) transmits files via WebDAV in Apple Double = format.  Thus a=20 file named mypix.jpeg on a local MacOS X system arrives on the server as = two=20 files as follows:

mypix.jpeg      ;containing = data=20 fork data
._mypix.jpg     ;containing = resource=20 fork data

The resource data file is normally invisible on most Unix based = systems=20 because its name begins with "._" but these files do accumulate over = time. =20 Their numbers and total disk space requirements present a number of = potential=20 issues including making diagnostic work unnecessarily difficult.  = These=20 resource fork files are totally useless on the webserver.  They do = not add=20 to any functionality on the webserver.

These files are not always invisible and can confuse both sysadmins = using a=20 CLI as well as end users who may see them via a web-based editing = system. =20 Examples of the latter include the current version of WebCT Vista, an=20 enterprise-level Courseware Management System that relies upon a BEA = Weblogic=20 webserver and an Oracle DB.

WebDAV support in Vista is complimented by a web-based file manager = that is=20 necessary to certain operations not possible via WebDAV having to do = with what=20 Vista calls "shared resources."  In the file manager, these "._" = prefixed=20 files are visible and a source of great confusion with end users (mostly = university faculty) who think that they are seeing double, don't know = which of=20 the two files to create links to and so on.

Our faculty also use Windows XP where none of these issues = obtain.

I hope that this impact information is helpful.


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr.=20 Frank Lowney  frank.lowney@gcsu.edu
    Director, = Electronic Instructional Services, a unit of the
    = Office of=20 Information and Instructional Technology,
    = Professional=20 Pages: http://www.gcsu.edu/oiit/eis/
    Personal = Pages:=20 http://www.faculty.de.gcsu.edu/~flowney
Voice: (478)=20 445-5260
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= We=20 don't make instruction effective, we make effective instruction more=20 accessible.

Please note that my new e-mail address is:=20 frank.lowney@gcsu.edu
------=_NextPart_000_000B_01C39670.CD25DCA0-- From w3c-dist-auth-request@w3.org Sun Oct 19 21:43: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 VAA25926 for ; Sun, 19 Oct 2003 21:43:08 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 6E8C8A08B0; Sun, 19 Oct 2003 21:43:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A1E16A08B0 for ; Sun, 19 Oct 2003 21:42:51 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 7686E13A36; Sun, 19 Oct 2003 21:42:51 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by dr-nick.w3.org (Postfix) with ESMTP id 2591D1379E for ; Sun, 19 Oct 2003 21:42:51 -0400 (EDT) Received: from Tycho (dsl3-63-249-68-18.cruzio.com [63.249.68.18]) by mail.cruzio.com with SMTP id h9K1glO2058844; Sun, 19 Oct 2003 18:42:49 -0700 (PDT) From: "Jim Whitehead" To: "Geoffrey M Clemm" Cc: Date: Sun, 19 Oct 2003 18:42:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: redirect ref spec, update on issue lc-85-301 X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICENOJMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031020014300.6E8C8A08B0@frink.w3.org> Resent-Date: Sun, 19 Oct 2003 21:43:00 -0400 (EDT) Content-Transfer-Encoding: 7bit Geoff Clemm writes: > I agree with Julian's rationale for adding this distinction. > This is just modeling the behavior defined by the existing standard, > not introducing new behavior. +1 I agree with Geoff on this issue. - Jim From w3c-dist-auth-request@w3.org Mon Oct 20 10:55: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 KAA29519 for ; Mon, 20 Oct 2003 10:55:00 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 3A66AA12A1; Mon, 20 Oct 2003 10:55:07 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 3B72CA12CA for ; Mon, 20 Oct 2003 10:54:46 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 04D0614A1B; Mon, 20 Oct 2003 10:52:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 68E9813BC3 for ; Mon, 20 Oct 2003 10:52:12 -0400 (EDT) Received: (qmail 358 invoked by uid 65534); 20 Oct 2003 14:52:11 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004) with SMTP; 20 Oct 2003 16:52:11 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: Date: Mon, 20 Oct 2003 16:52:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: DAV request header, was: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAELIINAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031020145507.3A66AA12A1@frink.w3.org> Resent-Date: Mon, 20 Oct 2003 10:55:07 -0400 (EDT) Content-Transfer-Encoding: 7bit Hi. Another thing we'll have to keep in mind is the possible interaction between this header and responses that are both cacheable and vary on the value of this request header... Ideas: - we could just forbid that (the value of the "Dav" request header must not affect cacheable responses) - clarify that whenever the "Dav" request header *does* affect a cacheable response, the server will have to list in the "Vary" response header. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 20 13:01:03 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 NAA03826 for ; Mon, 20 Oct 2003 13:01:02 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 385E2A08C8; Mon, 20 Oct 2003 13:01:00 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5BF4EA08C8 for ; Mon, 20 Oct 2003 13:00:57 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DC86514AD7; Mon, 20 Oct 2003 13:00:56 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (Postfix) with ESMTP id C357114AD6 for ; Mon, 20 Oct 2003 13:00:56 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9KH0uxc544074 for ; Mon, 20 Oct 2003 13:00:56 -0400 Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9KH0r57067002 for ; Mon, 20 Oct 2003 13:00:55 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 20 Oct 2003 13:00:53 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/20/2003 13:00:55, Serialize complete at 10/20/2003 13:00:55 Content-Type: text/plain; charset="US-ASCII" Subject: Re: DAV request header, was: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/OF44108516.9CA92A15-ON85256DC5.005D19E9-85256DC5.005D7787@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031020170100.385E2A08C8@frink.w3.org> Resent-Date: Mon, 20 Oct 2003 13:01:00 -0400 (EDT) I see no reason to forbid the value of the Dav request header from affecting cacheable responses, so if we do anything in this regard, I'd do the clarification. Cheers, Geoff Julian wrote on 10/20/2003 10:52:11 AM: > > Another thing we'll have to keep in mind is the possible interaction between > this header and responses that are both cacheable and vary on the value of > this request header... > > Ideas: > > - we could just forbid that (the value of the "Dav" request header must not > affect cacheable responses) > > - clarify that whenever the "Dav" request header *does* affect a cacheable > response, the server will have to list in the "Vary" response header. From w3c-dist-auth-request@w3.org Tue Oct 21 15:36: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 PAA03092 for ; Tue, 21 Oct 2003 15:36:17 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B6B8BA0509; Tue, 21 Oct 2003 15:36:25 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7CD2EA0509 for ; Tue, 21 Oct 2003 15:36:23 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 5BD55138C7; Tue, 21 Oct 2003 15:36:23 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by dr-nick.w3.org (Postfix) with ESMTP id 13DFC138BF for ; Tue, 21 Oct 2003 15:36:23 -0400 (EDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9LJaMo0020787 for ; Tue, 21 Oct 2003 12:36:22 -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 h9LJaKK04874 for ; Tue, 21 Oct 2003 13:36:20 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9LJaIK04801 for ; Tue, 21 Oct 2003 13:36:18 -0600 (MDT) Message-ID: <103e01c3980a$6c9e8990$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Tue, 21 Oct 2003 12:35:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_103B_01C397CF.C0101610" 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: non-collecton and multistatus response? X-Archived-At: http://www.w3.org/mid/103e01c3980a$6c9e8990$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021193625.B6B8BA0509@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 15:36:25 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_103B_01C397CF.C0101610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From reading the RFC2518, it's not clear to me that if I'm using a delete method to remove a non-collection resource, is it possible that server still returns a multitasks response? Is there a method that if my resource is a non-collection type, I'll be guaranteed that a multitasks response will never be=20 returned? Thx, -Stanley ------=_NextPart_000_103B_01C397CF.C0101610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From reading the RFC2518, it's not = clear to me=20 that
if I'm using a delete method to remove = a=20 non-collection
resource, is it possible that server = still returns=20 a multitasks
response?
 
Is there a method that if my resource = is a=20 non-collection type,
I'll be guaranteed that a multitasks = response will=20 never be
returned?
 
 
Thx,
 
-Stanley
------=_NextPart_000_103B_01C397CF.C0101610-- From w3c-dist-auth-request@w3.org Tue Oct 21 16:05:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05374 for ; Tue, 21 Oct 2003 16:05:26 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 789C2A0775; Tue, 21 Oct 2003 16:04:56 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id AFDB9A077C for ; Tue, 21 Oct 2003 16:04:41 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 9E09414C45; Tue, 21 Oct 2003 16:01:10 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 0D42214C43 for ; Tue, 21 Oct 2003 16:01:10 -0400 (EDT) Received: (qmail 16045 invoked by uid 65534); 21 Oct 2003 20:01:04 -0000 Received: from p3EE2475D.dip.t-dialin.net (HELO lisa) (62.226.71.93) by mail.gmx.net (mp023) with SMTP; 21 Oct 2003 22:01:04 +0200 X-Authenticated: #1915285 From: "Julian Reschke" To: "Stanley Guan" , Date: Tue, 21 Oct 2003 22:00:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <103e01c3980a$6c9e8990$c5b42382@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: non-collecton and multistatus response? X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEFMIOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021200456.789C2A0775@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 16:04:56 -0400 (EDT) Content-Transfer-Encoding: 7bit Stanley, I think it is *unlikely* that you'll get a 207 on a non-collection. However, I wouldn't rely on that, and no, there's no way to enforce a specific server behaviour. 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 Stanley Guan Sent: Tuesday, October 21, 2003 9:35 PM To: w3c-dist-auth@w3.org Subject: non-collecton and multistatus response? From reading the RFC2518, it's not clear to me that if I'm using a delete method to remove a non-collection resource, is it possible that server still returns a multitasks response? Is there a method that if my resource is a non-collection type, I'll be guaranteed that a multitasks response will never be returned? Thx, -Stanley From w3c-dist-auth-request@w3.org Tue Oct 21 16:51: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 QAA08409 for ; Tue, 21 Oct 2003 16:51:36 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 7A0B1A069E; Tue, 21 Oct 2003 16:51:45 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6187FA06CF for ; Tue, 21 Oct 2003 16:51:41 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 979AD14C6D; Tue, 21 Oct 2003 16:48:42 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id 6B0BA14C4D for ; Tue, 21 Oct 2003 16:48:42 -0400 (EDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9LKmgWs004339 for ; Tue, 21 Oct 2003 13:48:42 -0700 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9LKmdA05088 for ; Tue, 21 Oct 2003 14:48:40 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9LKmaA04910 for ; Tue, 21 Oct 2003 14:48:36 -0600 (MDT) Message-ID: <105301c39814$85292560$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Tue, 21 Oct 2003 13:47:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1050_01C397D9.D7A04C50" 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: XML elements in a copy method X-Archived-At: http://www.w3.org/mid/105301c39814$85292560$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021205145.7A0B1A069E@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 16:51:45 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_1050_01C397D9.D7A04C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Maybe my reading of RFC 2518 is not thorough enough. It seems to me = that: XML elements are allowed in a copy method to modify the copying = behavior. But, what kind of XML elements are allowed and how should they be interpreted? Thx, -Stanley ------=_NextPart_000_1050_01C397D9.D7A04C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Maybe my reading of RFC 2518 is not = thorough=20 enough.  It seems to me = that:
   XML elements are allowed = in a copy=20 method to modify the copying behavior.
 
But, what kind of XML elements are = allowed and how=20 should they be
interpreted?
 
Thx,
 
-Stanley
------=_NextPart_000_1050_01C397D9.D7A04C50-- From w3c-dist-auth-request@w3.org Tue Oct 21 16:52:06 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 QAA08462 for ; Tue, 21 Oct 2003 16:52:03 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 162ACA0782; Tue, 21 Oct 2003 16:51:55 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 47EF5A0782 for ; Tue, 21 Oct 2003 16:51:54 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 3464114C7B; Tue, 21 Oct 2003 16:49:05 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id B14D714C34 for ; Tue, 21 Oct 2003 16:49:04 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AC3RA-0007xR-00; Tue, 21 Oct 2003 20:49:04 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AC3R9-0007xG-00; Tue, 21 Oct 2003 20:49:03 +0000 From: "Lisa Dusseault" To: "'Stanley Guan'" , Date: Tue, 21 Oct 2003 13:48:10 -0700 Message-ID: <026f01c39814$a3b0d9b0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0270_01C397D9.F75201B0" 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 In-Reply-To: <103e01c3980a$6c9e8990$c5b42382@us.oracle.com> Old-X-Envelope-To: stanley.guan@oracle.com, w3c-dist-auth@w3.org Subject: RE: non-collecton and multistatus response? X-Archived-At: http://www.w3.org/mid/026f01c39814$a3b0d9b0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021205155.162ACA0782@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 16:51:55 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_0270_01C397D9.F75201B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RFC2518 isn't clear on this, but implementations definitely do return multistatus in response to operations on single items. It's a single code line for the server, rather than two. So the cat's more or less out of the bag on this one. lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stanley Guan Sent: Tuesday, October 21, 2003 12:35 PM To: w3c-dist-auth@w3.org Subject: non-collecton and multistatus response? From reading the RFC2518, it's not clear to me that if I'm using a delete method to remove a non-collection resource, is it possible that server still returns a multitasks response? Is there a method that if my resource is a non-collection type, I'll be guaranteed that a multitasks response will never be returned? Thx, -Stanley ------=_NextPart_000_0270_01C397D9.F75201B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
RFC2518 isn't clear on this, but implementations definitely do = return=20 multistatus in response to operations on single items.  It's a = single code=20 line for the server, rather than two.  So the cat's more or less = out of the=20 bag on this one.
 
lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Stanley Guan
Sent: Tuesday, October 21, 2003 = 12:35=20 PM
To: w3c-dist-auth@w3.org
Subject: non-collecton = and=20 multistatus response?

From reading the RFC2518, it's not = clear to me=20 that
if I'm using a delete method to = remove a=20 non-collection
resource, is it possible that server = still=20 returns a multitasks
response?
 
Is there a method that if my resource = is a=20 non-collection type,
I'll be guaranteed that a multitasks = response=20 will never be
returned?
 
 
Thx,
 
-Stanley
------=_NextPart_000_0270_01C397D9.F75201B0-- From w3c-dist-auth-request@w3.org Tue Oct 21 17:51:03 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 RAA12351 for ; Tue, 21 Oct 2003 17:51:02 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id B5816A059A; Tue, 21 Oct 2003 17:51:12 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 32481A059A for ; Tue, 21 Oct 2003 17:51:10 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id EC61513449; Tue, 21 Oct 2003 17:51:09 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id B681413875 for ; Tue, 21 Oct 2003 17:51:09 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AC4PF-0000DH-00; Tue, 21 Oct 2003 21:51:09 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AC4PD-0000D1-00; Tue, 21 Oct 2003 21:51:08 +0000 From: "Lisa Dusseault" To: "'Stanley Guan'" , Date: Tue, 21 Oct 2003 14:50:09 -0700 Message-ID: <031a01c3981d$4f95d980$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01C397E2.A3370180" 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 In-Reply-To: <105301c39814$85292560$c5b42382@us.oracle.com> Old-X-Envelope-To: stanley.guan@oracle.com, w3c-dist-auth@w3.org Subject: RE: XML elements in a copy method X-Archived-At: http://www.w3.org/mid/031a01c3981d$4f95d980$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021215112.B5816A059A@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 17:51:12 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_031B_01C397E2.A3370180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are correct, but this functionality hasn't been widely implemented. = It turns out the server knows more about what properties can and should be kept live on a COPY=20 operation, so the clients never provided this information and servers = didn't need it anyway. In RFC2518bis this has been removed. =20 lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Stanley Guan Sent: Tuesday, October 21, 2003 1:47 PM To: w3c-dist-auth@w3.org Subject: XML elements in a copy method Hi, =20 Maybe my reading of RFC 2518 is not thorough enough. It seems to me = that: XML elements are allowed in a copy method to modify the copying = behavior. =20 But, what kind of XML elements are allowed and how should they be interpreted? =20 Thx, =20 -Stanley ------=_NextPart_000_031B_01C397E2.A3370180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
You=20 are correct, but this functionality hasn't been widely = implemented.  It=20 turns out the
server=20 knows more about what properties can and should be kept live on a COPY=20
operation, so the clients never provided this information and = servers=20 didn't need it
anyway.  In RFC2518bis this has been = removed.
 
lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Stanley Guan
Sent: Tuesday, October 21, 2003 = 1:47=20 PM
To: w3c-dist-auth@w3.org
Subject: XML elements = in a=20 copy method

Hi,
 
Maybe my reading of RFC 2518 is not = thorough=20 enough.  It seems to me = that:
   XML elements are allowed = in a copy=20 method to modify the copying behavior.
 
But, what kind of XML elements are = allowed and=20 how should they be
interpreted?
 
Thx,
 
-Stanley
------=_NextPart_000_031B_01C397E2.A3370180-- From w3c-dist-auth-request@w3.org Tue Oct 21 18:41: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 SAA15974 for ; Tue, 21 Oct 2003 18:41:09 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id F0080A0522; Tue, 21 Oct 2003 18:41:17 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9B054A0522 for ; Tue, 21 Oct 2003 18:41:13 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 6C60F13B94; Tue, 21 Oct 2003 18:41:13 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by dr-nick.w3.org (Postfix) with ESMTP id 39CEE13B77 for ; Tue, 21 Oct 2003 18:41:13 -0400 (EDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9LMfCnb007007 for ; Tue, 21 Oct 2003 15:41:12 -0700 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9LMfCX18319 for ; Tue, 21 Oct 2003 16:41:12 -0600 (MDT) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9LMfBX18301 for ; Tue, 21 Oct 2003 16:41:11 -0600 (MDT) Message-ID: <109b01c39824$3894db30$c5b42382@us.oracle.com> From: "Stanley Guan" To: References: <031a01c3981d$4f95d980$f8cb90c6@lisalap> Date: Tue, 21 Oct 2003 15:39:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1098_01C397E9.8BDB6010" 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: XML elements in a copy method X-Archived-At: http://www.w3.org/mid/109b01c39824$3894db30$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031021224117.F0080A0522@frink.w3.org> Resent-Date: Tue, 21 Oct 2003 18:41:17 -0400 (EDT) This is a multi-part message in MIME format. ------=_NextPart_000_1098_01C397E9.8BDB6010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageLisa, Then, probably the following statement in RFC2518bis needs=20 to be reworded: 8.9 COPY Method COPY for HTTP/1.1 resources After a successful COPY invocation, all properties on the source resource MUST be duplicated on the destination resource, subject to modifying headers and XML elements, following the definition for copying properties. =20 Thx, -Stanley ----- Original Message -----=20 From: Lisa Dusseault=20 To: 'Stanley Guan' ; w3c-dist-auth@w3.org=20 Sent: Tuesday, October 21, 2003 2:50 PM Subject: RE: XML elements in a copy method You are correct, but this functionality hasn't been widely = implemented. It turns out the server knows more about what properties can and should be kept live on = a COPY=20 operation, so the clients never provided this information and servers = didn't need it anyway. In RFC2518bis this has been removed. lisa -----Original Message----- From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stanley Guan Sent: Tuesday, October 21, 2003 1:47 PM To: w3c-dist-auth@w3.org Subject: XML elements in a copy method Hi, Maybe my reading of RFC 2518 is not thorough enough. It seems to me = that: XML elements are allowed in a copy method to modify the copying = behavior. But, what kind of XML elements are allowed and how should they be interpreted? Thx, -Stanley ------=_NextPart_000_1098_01C397E9.8BDB6010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Lisa,
 
Then, probably the following statement = in=20 RFC2518bis needs
to be reworded:
 
 
8.9 COPY Method
 
COPY for HTTP/1.1 = resources
 
After a successful COPY invocation, all properties on the
source = resource MUST be duplicated on the destination resource,
subject to = modifying=20 headers and XML elements, following the
definition = for=20 copying properties. 
 
Thx,
 
-Stanley
----- Original Message -----
From:=20 Lisa = Dusseault=20
To: 'Stanley Guan' ; w3c-dist-auth@w3.org
Sent: Tuesday, October 21, 2003 = 2:50=20 PM
Subject: RE: XML elements in a = copy=20 method

You=20 are correct, but this functionality hasn't been widely = implemented.  It=20 turns out the
server knows more about what properties can and should be = kept live on=20 a COPY
operation, so the clients never provided this information and = servers=20 didn't need it
anyway.  In RFC2518bis this has been = removed.
 
lisa
-----Original Message-----
From: w3c-dist-auth-request@w3.org= =20 [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stanley=20 Guan
Sent: Tuesday, October 21, 2003 1:47 PM
To: = w3c-dist-auth@w3.org
Subject: XML elements in a copy=20 method

Hi,
 
Maybe my reading of RFC 2518 is not = thorough=20 enough.  It seems to me=20 that:
   XML elements are = allowed in a copy=20 method to modify the copying behavior.
 
But, what kind of XML elements are = allowed and=20 how should they be
interpreted?
 
Thx,
 
-Stanley
------=_NextPart_000_1098_01C397E9.8BDB6010-- From w3c-dist-auth-request@w3.org Fri Oct 24 10:56:39 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 KAA06113 for ; Fri, 24 Oct 2003 10:56:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id 742D8A0A4A; Fri, 24 Oct 2003 10:56:45 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7E60EA09BE for ; Fri, 24 Oct 2003 10:56:36 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id 637941401B; Fri, 24 Oct 2003 10:53:37 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id 551261355A for ; Fri, 24 Oct 2003 10:53:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05677; Fri, 24 Oct 2003 10:53:14 -0400 (EDT) Message-Id: <200310241453.KAA05677@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, 24 Oct 2003 10:53:12 -0400 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-06.txt X-Archived-At: http://www.w3.org/mid/200310241453.KAA05677@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031024145645.742D8A0A4A@frink.w3.org> Resent-Date: Fri, 24 Oct 2003 10:56:45 -0400 (EDT) --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 Filename : draft-ietf-webdav-redirectref-protocol-06.txt Pages : 55 Date : 2003-10-23 This 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. 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-06.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-06.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-06.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-10-24104013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24104013.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Oct 24 16:53:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29315 for ; Fri, 24 Oct 2003 16:53:39 -0400 (EDT) Received: by frink.w3.org (Postfix, from userid 59936) id BECF4A08BB; Fri, 24 Oct 2003 16:52:46 -0400 (EDT) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 26B2AA08BB for ; Fri, 24 Oct 2003 16:52:44 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id DE8F81372B; Fri, 24 Oct 2003 16:52:43 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id A6BBA1351D for ; Fri, 24 Oct 2003 16:52:43 -0400 (EDT) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AD8vK-0005al-00; Fri, 24 Oct 2003 20:52:42 +0000 Received: from [192.168.1.144] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AD8vK-0005aa-00; Fri, 24 Oct 2003 20:52:42 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , Date: Fri, 24 Oct 2003 13:52:42 -0700 Message-ID: <006d01c39a70$c4c3b240$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, w3c-dist-auth@w3.org Subject: RE: DAV request header, was: 3xx vs RFC2518 vs redirect-ref spec X-Archived-At: http://www.w3.org/mid/006d01c39a70$c4c3b240$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031024205246.BECF4A08BB@frink.w3.org> Resent-Date: Fri, 24 Oct 2003 16:52:46 -0400 (EDT) Content-Transfer-Encoding: 7bit If this header can affect caching, then I think we should add "This header MAY affect caching, therefore this header SHOULD NOT be used on GET requests where response caching is most important." Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > Sent: Monday, October 20, 2003 10:01 AM > To: w3c-dist-auth@w3.org > Subject: Re: DAV request header, was: 3xx vs RFC2518 vs > redirect-ref spec > > > > I see no reason to forbid the value of the Dav request header > from affecting cacheable responses, so if we do anything in > this regard, I'd do the clarification. > > Cheers, > Geoff > > Julian wrote on 10/20/2003 10:52:11 AM: > > > > Another thing we'll have to keep in mind is the possible interaction > between > > this header and responses that are both cacheable and vary on the > > value > of > > this request header... > > > > Ideas: > > > > - we could just forbid that (the value of the "Dav" request header > > must > not > > affect cacheable responses) > > > > - clarify that whenever the "Dav" request header *does* affect a > cacheable > > response, the server will have to list in the "Vary" > response header. > > From w3c-dist-auth-request@w3.org Sun Oct 26 18:42: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 SAA04984 for ; Sun, 26 Oct 2003 18:42:36 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 0F13FA05BE; Sun, 26 Oct 2003 18:41:55 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6FBECA05BE for ; Sun, 26 Oct 2003 18:41:51 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 451E213345; Sun, 26 Oct 2003 18:41:51 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id F10A3133EF for ; Sun, 26 Oct 2003 18:41:46 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1ADuW2-0000Cz-00 for w3c-dist-auth@w3c.org; Sun, 26 Oct 2003 23:41:46 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1ADuW1-0000Co-00 for w3c-dist-auth@w3c.org; Sun, 26 Oct 2003 23:41:45 +0000 From: "Lisa Dusseault" To: Date: Sun, 26 Oct 2003 15:41:48 -0800 Message-ID: <00a501c39c1a$b9a050c0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <006a01c3772b$96db9d60$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: RE: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/00a501c39c1a$b9a050c0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031026234155.0F13FA05BE@frink.w3.org> Resent-Date: Sun, 26 Oct 2003 18:41:55 -0500 (EST) Content-Transfer-Encoding: 7bit Was there any consensus on adding this (a section warning how clients can't rely on last modified)? I didn't see any objection but I'd like to see a more positive response or else leave it out. In private mail, Chris also pointed out that the description of Last-Modified in RFC2616 is filled with SHOULD requirements instead of MUST, so clients can't rely on that value anyway (particularly when doing synchronization). Obviously if there is consensus I won't get this new paragraph added before this draft deadline but there will likely be another rev of 2518bis after this deadline anyway. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > Sent: Tuesday, September 09, 2003 4:39 PM > To: 'Chris Knight'; 'Geoffrey M Clemm' > Cc: w3c-dist-auth@w3c.org > Subject: RE: DAV:bindings-last-modified (was RE: > DAV:getlastmodified of collections) > > > > This sounds like the right general idea. > > I'm starting to think that RFC2518 needs a new section, a > non-normative note or warning on the dangers of relying on > the value of > 'getlastmodified'. As far as I can tell: > - some servers allow this to be modified by clients > - on a MOVE, some servers set the destination getlastmodified to > the source's previous value, others set it to the timestamp of the > operation itself > - on a COPY, same thing, but probably not on all the same servers > that do the MOVE that way > - some servers allow underlying file system operations to replace > files with new files with *older* getlastmodified values > - some servers modify getlastmodifed when props change > - the behavior on directories is probably completely random > > Thus, clients can't rely on the value of getlastmodified (or > the Last-Modified header) at all and should use ETags > instead. If the server doesn't support ETags the client is screwed. > In that case, possibly the only reasonable thing is to throw > away your cached version anytime the last modified value > changes an iota, even if it changes to be *earlier* than your cached > version. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Chris Knight > > Sent: Tuesday, September 09, 2003 3:37 PM > > To: Geoffrey M Clemm > > Cc: w3c-dist-auth@w3c.org > > Subject: Re: DAV:bindings-last-modified (was RE: > > DAV:getlastmodified of collections) > > > > > > > > Geoffrey M Clemm wrote: > > > > >I believe that we have concluded that DAV:getlastmodified > depends on > > >what the server returns on a GET on a collection, and > > therefore is not > > >something we can define (since what the server returns on > a GET on a > > >collection is not defined). > > > > > Actually, since many servers do implement GET on a > > collection, how about > > saying "DAV:getlastmodified should be defined for > collections if the > > server supports GET on collections and the value of the > > property would > > be the last time some operation changed what would be the > result of a > > GET operation (and would be the value that would be compared > > against if > > a Last-Modified header was sent on said GET request)"? > > > > Sorry, my brain is not thinking in protocol-spec-speak right > > now, but I > > think you get the idea. > > > > Your other property for bindings would be useful as well, > and I would > > guess that many implementations would make them equivalent > > (as a GET on > > a collection would return an HTML rendering of the bindings > from that > > collection.) > > > > > > > From w3c-dist-auth-request@w3.org Sun Oct 26 19:02: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 TAA05571 for ; Sun, 26 Oct 2003 19:02:18 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id EDB44A052E; Sun, 26 Oct 2003 19:02:27 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 24B7AA052E for ; Sun, 26 Oct 2003 19:02:25 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id C9B1413BDE; Sun, 26 Oct 2003 19:02:24 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.xythos.com (unknown [206.14.210.116]) by dr-nick.w3.org (Postfix) with ESMTP id 7E9FF13B97 for ; Sun, 26 Oct 2003 19:02:24 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1ADuq0-0000Gp-00 for w3c-dist-auth@w3c.org; Mon, 27 Oct 2003 00:02:24 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1ADupx-0000Ge-00 for w3c-dist-auth@w3c.org; Mon, 27 Oct 2003 00:02:22 +0000 From: "Lisa Dusseault" To: Date: Sun, 26 Oct 2003 16:02:22 -0800 Message-ID: <00a601c39c1d$9a907950$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C39BDA.8C6D3950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: RE: DAV:modificationdate (was bindings-last-modified (was RE: DAV :getlastmodified of collections)) X-Archived-At: http://www.w3.org/mid/00a601c39c1d$9a907950$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027000227.EDB44A052E@frink.w3.org> Resent-Date: Sun, 26 Oct 2003 19:02:27 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C39BDA.8C6D3950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've only seen a couple people express interest in this new proposed property. =20 I'd like to know more to see a clear consensus: - Should we add this property, yea or nay - Should it be protected or writable (a writable last modified value = would be very useful to=20 clients doing backups or migrations) - Who will implement it, if it is added to 2518bis (ie within a year or = two of its addition) =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Nevermann, Dr., Peter Sent: Monday, September 08, 2003 8:44 AM To: 'w3c-dist-auth@w3c.org' Subject: RE: DAV:modificationdate (was bindings-last-modified (was RE: = DAV :getlastmodified of collections)) I would prefer a more general new property, e.g. DAV:modificationdate as proposed by Julian some days ago in another thread (I added a few words about *bindings* of a collection to Julian's wording):=20 "A proper way to address this may be to define a new optional = property=20 (if we make it optional, we may be able to get it into RFC52518bis), = for instance:=20 Name: modificationdate=20 Namespace: DAV:=20 Purpose: Records the time and date the resource was modified.=20 Value: date-time =20 Description: The creationdate property should be defined on all DAV=20 compliant resources. If present, it contains a timestamp=20 of the moment when the resource was last modified (i.e., the = moment when content and/or properties last changed,=20 or, when the bindings of a collection last changed).=20 This property is live and protected. The Internet date-time=20 format is defined in [RFC3339], see the ABNF in section 5.6. = COPY/MOVE behavior: This property value SHOULD be kept during a=20 MOVE operation, but is re-initialized when a resource is=20 created with a COPY. It should not be set in a remote COPY.=20 =20 "=20 Probably, w.r.t. properties, we need to clarify whether:=20 1) changes to *all* properties ought to be taken into account for = setting the modification date,=20 or only=20 2) changes to the *dead* properties plus some selected live properties = (e.g. non-protected properties).=20 I would go for 2).=20 Regards,=20 Peter=20 > -----Original Message-----=20 > From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]=20 > Sent: Monday, September 08, 2003 17:19=20 > To: w3c-dist-auth@w3c.org=20 > Subject: DAV:bindings-last-modified (was RE: DAV:getlastmodified of=20 > collections)=20 >=20 >=20 >=20 > I believe that we have concluded that DAV:getlastmodified depends on=20 > what the server returns on a GET on a collection, and therefore is not = > something we can define (since what the server returns on a GET on a=20 > collection is not defined). So what we are really talking about in=20 > this thread is a new property (which without much thought, I've named=20 > DAV:bindings-last-modified).=20 >=20 > This raises the key question: what will the client be using this new=20 > property for. I suggest it be used to keep the structure of a client=20 > tree display synchronized with the names and resources on the server,=20 > in which case the client doesn't care whether the version-controlled=20 > state changes, as long as the named tree of resources is still valid.=20 >=20 > Cheers,=20 > Geoff=20 >=20 > > > "Julian Reschke" wrote on=20 > 09/05/2003 06:08:11=20 > PM:=20 > > > > But then we're missing the case of VERSION-CONTROL on a=20 > versionable=20 > but not=20 > > > > yet version-controlled resource that lives inside a versioned=20 > collection (in=20 > > > > which case I'd say the state of the parent collection *does*=20 > change).=20 >=20 > > > Geoffrey M Clemm=20 > > > I suggest we keep the semantics very simple, and say that=20 > DAV:getlastmodified=20 > > > is changed only by adding a binding, removing a binding,=20 > or changing a=20 > binding=20 > > > to new resource. Putting an existing resource under=20 > version control=20 > does=20 > > > none of these things, so it should not result in an update to=20 > > > DAV:getlastmodified.=20 > > >=20 > > > Note that in general the "version-controlled state" of a=20 > collection=20 > will be=20 > > > different from the "state" of a collection, i.e. adding=20 > and removing a=20 > binding=20 > > > to a non-version-controlled resource does not change the=20 > version-controlled=20 > > > state of a collection, but does change the state of the=20 > collection.=20 > =20 > "Julian Reschke" wrote on 09/08/2003=20 > 09:45:20 AM:=20 > > This seems to imply that the version-controlled state is=20 > not a subset of=20 > the=20 > > state, or more precisely, that you can modify the=20 > version-controlled=20 > state=20 > > without changing the state. This IMHO seems to be a weird=20 > way to define=20 > the=20 > > state of a collection.=20 >=20 >=20 ------=_NextPart_000_00A7_01C39BDA.8C6D3950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I've=20 only seen a couple people express interest in this new proposed = property. =20
I'd=20 like to know more to see a clear consensus:
 - Should we add this property, yea or = nay
 - Should it be protected or writable (a writable last = modified=20 value would be very useful to
clients doing backups or migrations)
 - Who will implement it, if it is added to 2518bis (ie = within a=20 year or two of its addition)
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Nevermann, Dr., Peter
Sent: Monday, September = 08, 2003=20 8:44 AM
To: 'w3c-dist-auth@w3c.org'
Subject: RE:=20 DAV:modificationdate (was bindings-last-modified (was RE: DAV = :getlastmodified=20 of collections))

I would prefer a more general new property, e.g.=20 DAV:modificationdate as proposed by Julian some days ago in another = thread (I=20 added a few words about *bindings* of a collection to Julian's = wording):=20

    "A proper way to address this may = be to=20 define a new optional property
    (if=20 we make it optional, we may be able to get it into RFC52518bis),=20
    for instance:

   =20 Name:        modificationdate=20
    Namespace:   = DAV:=20
    = Purpose:    =20 Records the time and date the resource was modified.
    Value:       = date-time  
    = Description:=20 The creationdate property should be defined on all DAV =
          &nbs= p;=20 compliant resources.  If present, it contains a timestamp=20
          &nbs= p; of=20 the moment when the resource was last modified (i.e., the =
          &nbs= p;=20 moment when content and/or properties last changed,
          &nbs= p; or,=20 when the bindings of a collection last changed).
          &nbs= p; This=20 property is live and protected. The Internet date-time =
          &nbs= p;=20 format is defined in [RFC3339], see the ABNF in section 5.6. =
    COPY/MOVE behavior: This property value = SHOULD be=20 kept during a
          &nbs= p; MOVE=20 operation, but is re-initialized when a resource is
          &nbs= p;=20 created with a COPY. It should not be set in a remote COPY. =
   
   =20 <!ELEMENT modificationdate (#PCDATA) >"

Probably, w.r.t. properties, we need to clarify=20 whether:
1) changes to *all* properties = ought to be=20 taken into account for setting the modification date,
or only
2) changes to the *dead* = properties=20 plus some selected live properties (e.g. non-protected = properties).=20

I would go for 2).

Regards,
Peter

> -----Original Message-----
>=20 From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.co= m]=20
> Sent: Monday, September 08, 2003 17:19 =
> To: w3c-dist-auth@w3c.org
> = Subject:=20 DAV:bindings-last-modified (was RE: DAV:getlastmodified of =
> collections)
> =
>
>
> I=20 believe that we have concluded that DAV:getlastmodified depends = on=20
> what the server returns on a GET on a = collection, and=20 therefore is not
> something we can = define (since=20 what the server returns on a GET on a
> = collection=20 is not defined).  So what we are really talking about in =
> this thread is a new property (which without much = thought, I've=20 named
> = DAV:bindings-last-modified).=20
>
> This raises the = key=20 question: what will the client be using this new
>=20 property for.  I suggest it be used to keep the structure of a=20 client
> tree display synchronized with = the names=20 and resources on the server,
> in which = case the=20 client doesn't care whether the version-controlled
> state changes, as long as the named tree of resources is = still=20 valid.
>
>=20 Cheers,
> Geoff
>=20
> > > "Julian Reschke"=20 <julian.reschke@gmx.de> wrote on
> = 09/05/2003=20 06:08:11
> PM:
> >=20 > > But then we're missing the case of VERSION-CONTROL on a=20
> versionable
> but=20 not
> > > > yet = version-controlled=20 resource that lives inside a versioned
> = collection=20 (in
> > > > which case I'd say = the state=20 of the parent collection *does*
> = change).=20
>
> > > = Geoffrey M=20 Clemm
> > > I suggest we keep the = semantics=20 very simple, and say that
>=20 DAV:getlastmodified
> > > is = changed only by=20 adding a binding, removing a binding,
> = or changing=20 a
> binding
> > >=20 to new resource.  Putting an existing resource under =
> version control
> = does
> > > none of these things, so it should not result = in an=20 update to
> > > = DAV:getlastmodified.=20
> > >
> > = > Note=20 that in general the "version-controlled state" of a
> collection
> will be =
> > > different from the "state" of a collection, = i.e. adding=20
> and removing a
>=20 binding
> > > to a = non-version-controlled=20 resource does not change the
>=20 version-controlled
> > > state of a = collection, but does change the state of the
>=20 collection.
> 
>=20 "Julian Reschke" <julian.reschke@gmx.de> wrote on 09/08/2003=20
> 09:45:20 AM:
> >=20 This seems to imply that the version-controlled state is =
> not a subset of
> = the
> > state, or more precisely, that you can modify the=20
> version-controlled
>=20 state
> > without changing the state. = This IMHO=20 seems to be a weird
> way to define=20
> the
> > = state of a=20 collection.
>
>=20

------=_NextPart_000_00A7_01C39BDA.8C6D3950-- From w3c-dist-auth-request@w3.org Mon Oct 27 12:42: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 MAA27080 for ; Mon, 27 Oct 2003 12:42:49 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 381BAA0EEA; Mon, 27 Oct 2003 12:43:00 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 7ACECA0D3C for ; Mon, 27 Oct 2003 12:42:31 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 0645915836; Mon, 27 Oct 2003 12:37:36 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 89104157E1 for ; Mon, 27 Oct 2003 12:37:35 -0500 (EST) Received: (qmail 25271 invoked by uid 65534); 27 Oct 2003 17:37:31 -0000 Received: from pD950C3B6.dip.t-dialin.net (EHLO gmx.de) (217.80.195.182) by mail.gmx.net (mp021) with SMTP; 27 Oct 2003 18:37:31 +0100 X-Authenticated: #1915285 Message-ID: <3F9D57D6.1020005@gmx.de> Date: Mon, 27 Oct 2003 18:37:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3c.org References: <00a501c39c1a$b9a050c0$f8cb90c6@lisalap> In-Reply-To: <00a501c39c1a$b9a050c0$f8cb90c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: DAV:bindings-last-modified (was RE: DAV:getlastmodified of collections) X-Archived-At: http://www.w3.org/mid/3F9D57D6.1020005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027174300.381BAA0EEA@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 12:43:00 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Was there any consensus on adding this (a section warning how > clients can't rely on last modified)? I didn't see any objection > but I'd like to see a more positive response or else leave it out. > > In private mail, Chris also pointed out that the description of > Last-Modified in RFC2616 is filled with SHOULD requirements instead > of MUST, so clients can't rely on that value anyway (particularly > when doing synchronization). > > Obviously if there is consensus I won't get this new paragraph > added before this draft deadline but there will likely be another > rev of 2518bis after this deadline anyway. It seems to be a good idea to add these kinds of notes. Looking at your list...: >> - some servers allow this to be modified by clients >> - on a MOVE, some servers set the destination getlastmodified to >> the source's previous value, others set it to the timestamp of the >> operation itself >> - on a COPY, same thing, but probably not on all the same servers >> that do the MOVE that way >> - some servers allow underlying file system operations to replace >> files with new files with *older* getlastmodified values >> - some servers modify getlastmodifed when props change >> - the behavior on directories is probably completely random ...we probably should make clear what kind of behaviour indeed is ok according to the spec (to avoid implementers saying "but RFC2518 says it's ok to do this..."). For instance, changing the value of the Last-Modified header to an earlier value as a result of a namespace operation is something I'd call a RFC2616 compliance issue. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 27 12:43: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 MAA27123 for ; Mon, 27 Oct 2003 12:43:46 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id C9753A0BE1; Mon, 27 Oct 2003 12:43:57 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9E2B8A0C2E for ; Mon, 27 Oct 2003 12:43:43 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 6F5BE14358; Mon, 27 Oct 2003 12:43:43 -0500 (EST) Delivered-To: w3c-dist-auth@w3c.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id ED1321332F for ; Mon, 27 Oct 2003 12:43:42 -0500 (EST) Received: (qmail 26602 invoked by uid 65534); 27 Oct 2003 17:43:42 -0000 Received: from pD950C3B6.dip.t-dialin.net (EHLO gmx.de) (217.80.195.182) by mail.gmx.net (mp014) with SMTP; 27 Oct 2003 18:43:42 +0100 X-Authenticated: #1915285 Message-ID: <3F9D594B.4000709@gmx.de> Date: Mon, 27 Oct 2003 18:43:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Cc: w3c-dist-auth@w3c.org References: <00a601c39c1d$9a907950$f8cb90c6@lisalap> In-Reply-To: <00a601c39c1d$9a907950$f8cb90c6@lisalap> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: DAV:modificationdate (was bindings-last-modified (was RE: DAV :getlastmodified of collections)) X-Archived-At: http://www.w3.org/mid/3F9D594B.4000709@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027174357.C9753A0BE1@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 12:43:57 -0500 (EST) Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I've only seen a couple people express interest in this new proposed > property. > I'd like to know more to see a clear consensus: > - Should we add this property, yea or nay > - Should it be protected or writable (a writable last modified value > would be very useful to > clients doing backups or migrations) > - Who will implement it, if it is added to 2518bis (ie within a year or > two of its addition) I think it's useful to define this property, even if it's not widely implemented. For instance, when discussing the behaviour of DAV:getlastmodified (see previous mail) we'd be able to point to this description and say "this is what many people expect DAV:getlastmodified does, but it doesn't". Regarding how to proceed: we probably would be able to implement this property relatively soon. It would be interesting to hear from the Apache/moddav people (Greg?), though... An alternative approach would be to start a separate document that contains all the new things we'd like to see in WebDAV++, but currently don't want to put into RFC2518bis. This document could also serve as new home for an updated description of DAV:source, for instance. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 27 14:26: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 OAA02095 for ; Mon, 27 Oct 2003 14:26:57 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id ED587A074B; Mon, 27 Oct 2003 14:25:20 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6FE15A074B for ; Mon, 27 Oct 2003 14:25:15 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id EF97A14118; Mon, 27 Oct 2003 14:25:14 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by dr-nick.w3.org (Postfix) with ESMTP id A46A013CDE for ; Mon, 27 Oct 2003 14:25:14 -0500 (EST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9RJPEPr002868 for ; Mon, 27 Oct 2003 11:25:14 -0800 (PST) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9RJPDN11303 for ; Mon, 27 Oct 2003 12:25:13 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9RJ0tN12984 for ; Mon, 27 Oct 2003 12:00:55 -0700 (MST) Message-ID: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Mon, 27 Oct 2003 10:59:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_136C_01C39C79.5632C6D0" 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: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/136f01c39cbc$6491b040$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027192520.ED587A074B@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 14:25:20 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_136C_01C39C79.5632C6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is Depth hader allowed in a PROPPATCH method? If specified by the client, what should the server respond? Thx, -Stanley ------=_NextPart_000_136C_01C39C79.5632C6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Is Depth hader allowed in a PROPPATCH = method? =20 If specified
by the client, what should the server=20 respond?
 
Thx,
 
-Stanley
------=_NextPart_000_136C_01C39C79.5632C6D0-- From w3c-dist-auth-request@w3.org Mon Oct 27 15:09: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 PAA05243 for ; Mon, 27 Oct 2003 15:09:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 1503EA0509; Mon, 27 Oct 2003 15:10:06 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 74D9DA0509 for ; Mon, 27 Oct 2003 15:10:03 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 1615713C61; Mon, 27 Oct 2003 15:10:03 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 9666F13326 for ; Mon, 27 Oct 2003 15:10:02 -0500 (EST) Received: (qmail 13744 invoked by uid 65534); 27 Oct 2003 20:09:57 -0000 Received: from pD950C3B6.dip.t-dialin.net (EHLO gmx.de) (217.80.195.182) by mail.gmx.net (mp012) with SMTP; 27 Oct 2003 21:09:57 +0100 X-Authenticated: #1915285 Message-ID: <3F9D7B7D.1070309@gmx.de> Date: Mon, 27 Oct 2003 21:09:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stanley Guan Cc: w3c-dist-auth@w3.org References: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> In-Reply-To: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/3F9D7B7D.1070309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027201006.1503EA0509@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 15:10:06 -0500 (EST) Content-Transfer-Encoding: 7bit Stanley Guan wrote: > Hi, > > Is Depth hader allowed in a PROPPATCH method? If specified > by the client, what should the server respond? > > Thx, > > -Stanley PROPPATCH doesn't specify how a Depth header should be interpreted. Thus, a client cannot rely on any specific server behaviour. I'd assume that most of the servers will ignore the header upon PROPPATCH, thus rejecting the message may cause interoperability problems. So maybe RFC2518bis should clarify this? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 27 15:18: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 PAA06385 for ; Mon, 27 Oct 2003 15:18:37 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 829A0A05FE; Mon, 27 Oct 2003 15:18:46 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 32F22A05FE for ; Mon, 27 Oct 2003 15:18:44 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id BDC6313A20; Mon, 27 Oct 2003 15:18:43 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id 8284A13A1C for ; Mon, 27 Oct 2003 15:18:43 -0500 (EST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9RKIfWs002604; Mon, 27 Oct 2003 12:18:41 -0800 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9RKIfK11982; Mon, 27 Oct 2003 13:18:41 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9RKIdK11948; Mon, 27 Oct 2003 13:18:40 -0700 (MST) Message-ID: <13a901c39cc7$3f3ea180$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Julian Reschke" Cc: References: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> <3F9D7B7D.1070309@gmx.de> Date: Mon, 27 Oct 2003 12:16:46 -0800 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: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/13a901c39cc7$3f3ea180$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027201846.829A0A05FE@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 15:18:46 -0500 (EST) Content-Transfer-Encoding: 7bit Julian, I think it needs to be clarified. Also, can the "set" and "remove" XML elements specify properties belonging to the internal member's? Thx, -Stanley ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" Cc: Sent: Monday, October 27, 2003 12:09 PM Subject: Re: Depth header in PROPPATCH method > > Stanley Guan wrote: > > > Hi, > > > > Is Depth hader allowed in a PROPPATCH method? If specified > > by the client, what should the server respond? > > > > Thx, > > > > -Stanley > > PROPPATCH doesn't specify how a Depth header should be interpreted. > Thus, a client cannot rely on any specific server behaviour. > > I'd assume that most of the servers will ignore the header upon > PROPPATCH, thus rejecting the message may cause interoperability > problems. So maybe RFC2518bis should clarify this? > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Mon Oct 27 15:27:06 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 PAA07122 for ; Mon, 27 Oct 2003 15:27:05 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 736EEA06BB; Mon, 27 Oct 2003 15:27:14 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 1D29EA08D8 for ; Mon, 27 Oct 2003 15:27:03 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id DF72C13CF8; Mon, 27 Oct 2003 15:25:23 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 67CDE13CEB for ; Mon, 27 Oct 2003 15:25:23 -0500 (EST) Received: (qmail 9750 invoked by uid 65534); 27 Oct 2003 20:25:15 -0000 Received: from pD950C3B6.dip.t-dialin.net (EHLO gmx.de) (217.80.195.182) by mail.gmx.net (mp002) with SMTP; 27 Oct 2003 21:25:15 +0100 X-Authenticated: #1915285 Message-ID: <3F9D7F0F.6000001@gmx.de> Date: Mon, 27 Oct 2003 21:24:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stanley Guan Cc: w3c-dist-auth@w3.org References: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> <3F9D7B7D.1070309@gmx.de> <13a901c39cc7$3f3ea180$c5b42382@us.oracle.com> In-Reply-To: <13a901c39cc7$3f3ea180$c5b42382@us.oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/3F9D7F0F.6000001@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027202714.736EEA06BB@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 15:27:14 -0500 (EST) Content-Transfer-Encoding: 7bit Stanley Guan wrote: > Julian, > > I think it needs to be clarified. Also, can the "set" and > "remove" XML elements specify properties belonging > to the internal member's? > > Thx, > > -Stanley No, they can't. What did you think they can? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 27 16:57:13 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 QAA16957 for ; Mon, 27 Oct 2003 16:57:12 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 82BF1A0568; Mon, 27 Oct 2003 16:57:19 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9CD5FA0542 for ; Mon, 27 Oct 2003 16:57:16 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id AFFE613902; Mon, 27 Oct 2003 16:47:07 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 4222313443 for ; Mon, 27 Oct 2003 16:47:07 -0500 (EST) Received: (qmail 6130 invoked by uid 65534); 27 Oct 2003 21:47:06 -0000 Received: from pD950C3B6.dip.t-dialin.net (EHLO gmx.de) (217.80.195.182) by mail.gmx.net (mp009) with SMTP; 27 Oct 2003 22:47:06 +0100 X-Authenticated: #1915285 Message-ID: <3F9D9256.6080100@gmx.de> Date: Mon, 27 Oct 2003 22:47:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Review of draft-ietf-webdav-quota-02.txt X-Archived-At: http://www.w3.org/mid/3F9D9256.6080100@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027215719.82BF1A0568@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 16:57:19 -0500 (EST) Content-Transfer-Encoding: 7bit Issues with draft-ietf-webdav-quota-02.txt Content 01-C01 Organization I think the draft could greatly benefit by a more clean separation of (a) terminology, (b) protocol (property/error code) definition and (c) examples. Proposal for a outline: 1 Introduction/Notation/Terminology 2 Additional live properties 3 Modification to behaviour of existing methods (error marshalling) 4...n Other standard RFC section A (Appendix) Examples of how servers may implement quota I'm happy to help restructuring the document if this is just a amount-of-work issue. 01-C02 DAV:quota-assigned-bytes The issue here seems to be that an additional property is required to make the quota authorable. I honestly haven't understood yet why it's needed. The problem seems to be that as the reported quota may be a "best pick" by the server (there may be multiple quotas in place, but only the most strict will be reported at any point of time). If this is the case this could potentially be fixed by exposing all quotas to the client. At the end of the day, unless we can agree about how this is supposed to work I strongly suggest to leave it out of the base spec and use a vendor-specific property for setting it. 01-C03 quota vs disk space The spec says that servers may expose physical disk limits as quota. a) This is incompatible with NFS from which we're borrowing the semantics (it treats disk limits as a separate property, and so should we) b) Stefan raised interesting usability issue that weren't resolved so far (). 02-C01 Condition Name Use name of precondition, not failure description: instead of 02-C02 allprop marshalling Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach). Editorial: 02-E01 non-ASCII characters in draft 02-E02 sample host names do not conform to RFC2606 02-E03 missing section numbers -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 27 17:49:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25040 for ; Mon, 27 Oct 2003 17:49:33 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id BB646A055B; Mon, 27 Oct 2003 17:49:44 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 34BE6A055B for ; Mon, 27 Oct 2003 17:49:42 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id F0F3913504; Mon, 27 Oct 2003 17:49:41 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by dr-nick.w3.org (Postfix) with ESMTP id 84EAD134B7 for ; Mon, 27 Oct 2003 17:49:41 -0500 (EST) Received: from Tycho (dhcp-63-174.cse.ucsc.edu [128.114.63.174]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h9RMhGq00384; Mon, 27 Oct 2003 14:43:16 -0800 (PST) From: "Jim Whitehead" To: "Julian Reschke" Cc: Date: Mon, 27 Oct 2003 14:44:34 -0800 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 In-Reply-To: <3F9D7B7D.1070309@gmx.de> X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEGCJOAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031027224944.BB646A055B@frink.w3.org> Resent-Date: Mon, 27 Oct 2003 17:49:44 -0500 (EST) Content-Transfer-Encoding: 7bit > I'd assume that most of the servers will ignore the header upon > PROPPATCH, thus rejecting the message may cause interoperability > problems. So maybe RFC2518bis should clarify this? I seem to recall Lisa Dusseault talking about how painful it was for Exchange to implement Depth/PROPPATCH behavior, and hence I suspect there are some servers that do implement this capability. - Jim From w3c-dist-auth-request@w3.org Tue Oct 28 09:41:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25080 for ; Tue, 28 Oct 2003 09:41:28 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 1F3A0A0610; Tue, 28 Oct 2003 09:41:36 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id E785BA0610 for ; Tue, 28 Oct 2003 09:41:30 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id BE4B613A04; Tue, 28 Oct 2003 09:41:30 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (Postfix) with ESMTP id E0949139ED for ; Tue, 28 Oct 2003 09:41:20 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25059; Tue, 28 Oct 2003 09:41:07 -0500 (EST) Message-Id: <200310281441.JAA25059@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, 28 Oct 2003 09:41:07 -0500 Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-05.txt X-Archived-At: http://www.w3.org/mid/200310281441.JAA25059@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028144136.1F3A0A0610@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 09:41:36 -0500 (EST) --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-05.txt Pages : 98 Date : 2003-10-27 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-05.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-05.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-05.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-10-28095932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095932.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Oct 28 12:11: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 MAA08968 for ; Tue, 28 Oct 2003 12:11:53 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id DAFF4A0512; Tue, 28 Oct 2003 12:12:03 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id D5F73A0512 for ; Tue, 28 Oct 2003 12:11:59 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 73BE5135A5; Tue, 28 Oct 2003 12:11:59 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id 3C1EE1339F for ; Tue, 28 Oct 2003 12:11:59 -0500 (EST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9SHBnjK005802; Tue, 28 Oct 2003 09:11:49 -0800 Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9SHBkq06692; Tue, 28 Oct 2003 10:11:46 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9SHBiq06613; Tue, 28 Oct 2003 10:11:44 -0700 (MST) Message-ID: <13ed01c39d76$48655c90$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Julian Reschke" Cc: References: <136f01c39cbc$6491b040$c5b42382@us.oracle.com> <3F9D7B7D.1070309@gmx.de> <13a901c39cc7$3f3ea180$c5b42382@us.oracle.com> <3F9D7F0F.6000001@gmx.de> Date: Tue, 28 Oct 2003 09:09:43 -0800 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: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/13ed01c39d76$48655c90$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028171203.DAFF4A0512@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 12:12:03 -0500 (EST) Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Julian Reschke" To: "Stanley Guan" Cc: Sent: Monday, October 27, 2003 12:24 PM Subject: Re: Depth header in PROPPATCH method > > Stanley Guan wrote: > > > Julian, > > > > I think it needs to be clarified. Also, can the "set" and > > "remove" XML elements specify properties belonging > > to the internal member's? > > > > Thx, > > > > -Stanley > > No, they can't. What did you think they can? In the document, it didn't say it can't. But, it didn't mention the depth header in the proppatch section either. I think it's better to clarify it. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Tue Oct 28 13:13:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14052 for ; Tue, 28 Oct 2003 13:13:05 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id CF6BCA0513; Tue, 28 Oct 2003 13:13:16 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8B45DA0513 for ; Tue, 28 Oct 2003 13:13:13 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id D447413B38; Tue, 28 Oct 2003 13:06:32 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by dr-nick.w3.org (Postfix) with ESMTP id A270A13877 for ; Tue, 28 Oct 2003 13:06:32 -0500 (EST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet01.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9SI6VjK022592; Tue, 28 Oct 2003 10:06:31 -0800 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9SI6TK14237; Tue, 28 Oct 2003 11:06:29 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9SI6RK14177; Tue, 28 Oct 2003 11:06:27 -0700 (MST) Message-ID: <142901c39d7d$ecce6d10$c5b42382@us.oracle.com> From: "Stanley Guan" To: "Julian Reschke" Cc: References: Date: Tue, 28 Oct 2003 10:04:25 -0800 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: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/142901c39d7d$ecce6d10$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028181316.CF6BCA0513@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 13:13:16 -0500 (EST) Content-Transfer-Encoding: 7bit Julian, This seems to say that there are some confusions among implementers on whether a Depth on PROPPATCH is acceptable or not! Thx, -Stanley ----- Original Message ----- From: "Jim Whitehead" To: "Julian Reschke" Cc: Sent: Monday, October 27, 2003 2:44 PM Subject: RE: Depth header in PROPPATCH method > > > I'd assume that most of the servers will ignore the header upon > > PROPPATCH, thus rejecting the message may cause interoperability > > problems. So maybe RFC2518bis should clarify this? > > I seem to recall Lisa Dusseault talking about how painful it was for > Exchange to implement Depth/PROPPATCH behavior, and hence I suspect there > are some servers that do implement this capability. > > - Jim > > From w3c-dist-auth-request@w3.org Tue Oct 28 15:31: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 PAA23751 for ; Tue, 28 Oct 2003 15:31:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 4DFB1A0734; Tue, 28 Oct 2003 15:32:05 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0D38FA0600 for ; Tue, 28 Oct 2003 15:32:00 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id E7E5C13435; Tue, 28 Oct 2003 15:31:59 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by dr-nick.w3.org (Postfix) with ESMTP id D83E113378 for ; Tue, 28 Oct 2003 15:31:59 -0500 (EST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by frink.w3.org (Postfix) with SMTP id 4F1A5A0600 for ; Tue, 28 Oct 2003 15:31:59 -0500 (EST) Received: (qmail 19107 invoked by uid 65534); 28 Oct 2003 19:13:35 -0000 Received: from unknown (EHLO gmx.de) (217.80.194.101) by mail.gmx.net (mp005) with SMTP; 28 Oct 2003 20:13:35 +0100 X-Authenticated: #1915285 Message-ID: <3F9EBFD5.3040202@gmx.de> Date: Tue, 28 Oct 2003 20:13:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stanley Guan Cc: w3c-dist-auth@w3.org References: <142901c39d7d$ecce6d10$c5b42382@us.oracle.com> In-Reply-To: <142901c39d7d$ecce6d10$c5b42382@us.oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Depth header in PROPPATCH method X-Archived-At: http://www.w3.org/mid/3F9EBFD5.3040202@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028203205.4DFB1A0734@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 15:32:05 -0500 (EST) Content-Transfer-Encoding: 7bit Stanley Guan wrote: > Julian, > > This seems to say that there are some confusions among > implementers on whether a Depth on PROPPATCH is > acceptable or not! No, there is really no reason for confusion. PROPPATCH is defined to act on the resource identified by the request URI, nothing else. If some implementers decide to *extend* that it's up to them, but it still is a proprietary extension with no backing from RFC2518. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 28 16:02: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 QAA26519 for ; Tue, 28 Oct 2003 16:02:01 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 06F1EA06CC; Tue, 28 Oct 2003 16:02:11 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 9123BA074B for ; Tue, 28 Oct 2003 16:02:06 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 432F013442; Tue, 28 Oct 2003 16:02:06 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id B5A93133F5 for ; Tue, 28 Oct 2003 16:02:05 -0500 (EST) Received: (qmail 13608 invoked by uid 65534); 28 Oct 2003 20:18:56 -0000 Received: from pD950C265.dip.t-dialin.net (EHLO gmx.de) (217.80.194.101) by mail.gmx.net (mp027) with SMTP; 28 Oct 2003 21:18:56 +0100 X-Authenticated: #1915285 Message-ID: <3F9ECF13.3@gmx.de> Date: Tue, 28 Oct 2003 21:18:27 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: rfc2518-bis-05 issues (part 1) X-Archived-At: http://www.w3.org/mid/3F9ECF13.3@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028210211.06F1EA06CC@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 16:02:11 -0500 (EST) Content-Transfer-Encoding: 8bit Hi. Below is a list of issues I raised against drafts 03 and 04 which IMHO have not been adequately addressed in the latest draft (see [1] for the original message). 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”. [draft 05 now says...] Note that “DAV:” is a scheme name defined solely to provide a namespace for WebDAV XML elements and property names. This practice is discouraged in part because registration of new scheme names 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. Well. The practice is not discouraged because registering new schemes is hard. It's the other way around: registering new schemes is hard because the IETF suggests using existing schemes whenever possible, and in this case, defining a new scheme was not necessary at all. Also, the *other* issue is using just a URI scheme name as a namespace name. This does not conform to RFC2396 (the character sequence "DAV:" is not a legal URI and thus should not have been used as namespace name). So I still think my proposed rewrite is more precise. 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 roundtripped. 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. As a minimum, I'd suggest changing MUST not (which should be "MUST NOT" anyway...) to "SHOULD NOT". Reason: there's a risk of making otherwise compliant servers non-compliant. All we gain in exchange is a possible (!) small improvement in ETag reliability. 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-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). Update re: -05: the spec still uses the term "namespace schema" which isn't a well-defined technical term. Just say "namespace". 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 :-)] Update -05: the grammar was fixed, but the text still reads as if there's something special about DAV:no-lock. Just state that DAV:no-lock is an *example* for a URI that definitively will never identify a WebDAV lock, just like any other URI using the DAV: scheme. 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. Update -05: the old notation is back, this is good. The spec now defines extensibility case-by-case, IMHO it should only define it when it's not the standard extensibilty. Also: "Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized." s/SHOULD/MUST/ Editorial notes: 03-E04 There are still 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 Tue Oct 28 16:37:43 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 QAA27912 for ; Tue, 28 Oct 2003 16:37:43 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 47951A07E0; Tue, 28 Oct 2003 16:37:51 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 0C19AA07E0 for ; Tue, 28 Oct 2003 16:37:47 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id DB3DB13B93; Tue, 28 Oct 2003 16:37:46 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by dr-nick.w3.org (Postfix) with ESMTP id ABDB71347C for ; Tue, 28 Oct 2003 16:37:46 -0500 (EST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9SLbk86001938 for ; Tue, 28 Oct 2003 13:37:46 -0800 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 h9SLbjX15492 for ; Tue, 28 Oct 2003 14:37:45 -0700 (MST) Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9SLbjX15480 for ; Tue, 28 Oct 2003 14:37:45 -0700 (MST) Message-ID: <145a01c39d9b$6ecac4e0$c5b42382@us.oracle.com> From: "Stanley Guan" To: Date: Tue, 28 Oct 2003 13:35:39 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1457_01C39D58.60730760" 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: properties vs. internal members X-Archived-At: http://www.w3.org/mid/145a01c39d9b$6ecac4e0$c5b42382@us.oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031028213751.47951A07E0@frink.w3.org> Resent-Date: Tue, 28 Oct 2003 16:37:51 -0500 (EST) This is a multi-part message in MIME format. ------=_NextPart_000_1457_01C39D58.60730760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I imagine this issue might have been actively discussed before. But, it doesn't seem to be symmetric in the way that properties and internal members are treated in the spec. For retrieving a list of properties from a collection, DAV provides a clear definition of how a server should return them in an XML doc. As for retrieving a list of internal members from a collection which is deemed an important operation to me, DAV only provides a vague description on how it might work: GET when=20 applied to a collection may return the contents of an "index.html"=20 resource, a human-readable view of the contents of the collection,=20 or something else altogether. Hence it is possible that the result=20 of a GET on a collection will bear no correlation to the membership=20 of the collection.=20 Can some one explain why internal members are treated in this way? =20 Thanks in advance! -Stanley ------=_NextPart_000_1457_01C39D58.60730760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I imagine this issue might have been = actively=20 discussed before.  But,
it doesn't seem to be symmetric in the = way that=20 properties and internal
members are treated in the = spec.
 
For retrieving  a list of = properties from a=20 collection, DAV provides a
clear definition of how a server should = return them=20 in an XML doc.
As for retrieving a list of internal = members from a=20 collection which
is deemed an important operation to me, = DAV only=20 provides a vague
description on how it might = work:
 
    GET = when=20
   applied to a collection may return the contents of an=20 "index.html"
   resource, a human-readable view of the = contents of=20 the collection,
   or something else altogether. Hence it = is=20 possible that the result
   of a GET on a collection will = bear no=20 correlation to the membership
   of the collection.=20
 
Can some = one explain why=20 internal members are treated in this way?  =
 
Thanks in = advance!
 
 
-Stanley

 ------=_NextPart_000_1457_01C39D58.60730760-- From w3c-dist-auth-request@w3.org Wed Oct 29 06:07:06 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 GAA02994 for ; Wed, 29 Oct 2003 06:07:06 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id D12E9A0749; Wed, 29 Oct 2003 06:07:15 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id A5A7BA089B for ; Wed, 29 Oct 2003 06:07:12 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 45C2E1350C; Wed, 29 Oct 2003 06:07:12 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id C90BF134D6 for ; Wed, 29 Oct 2003 06:07:11 -0500 (EST) Received: (qmail 30041 invoked by uid 65534); 29 Oct 2003 11:07:10 -0000 Received: from unknown (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp010) with SMTP; 29 Oct 2003 12:07:10 +0100 X-Authenticated: #1915285 Message-ID: <3F9F9F5D.4010606@gmx.de> Date: Wed, 29 Oct 2003 12:07:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: rfc2518-bis-05 issues (part 2) X-Archived-At: http://www.w3.org/mid/3F9F9F5D.4010606@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031029110715.D12E9A0749@frink.w3.org> Resent-Date: Wed, 29 Oct 2003 06:07:15 -0500 (EST) Content-Transfer-Encoding: 7bit Hi. Below is a list of issues I raised against drafts 02, 03 and 04 which IMHO have not been adequately addressed in the latest draft (see [1] for the original message). C02-10) Section 8.2.2 (...) Also: the example for propfind/allprop is missing. Why was it removed? 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. Update -05: thanks for adding the location extension element. We may want to also say that it should only be used when the status for the response is 3xx. 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 Oct 29 10:56: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 KAA15639 for ; Wed, 29 Oct 2003 10:56:56 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id DCB13A0969; Wed, 29 Oct 2003 10:56:45 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 6418CA0969 for ; Wed, 29 Oct 2003 10:56:40 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 19BEE135CC; Wed, 29 Oct 2003 10:56:40 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id A5569135B7 for ; Wed, 29 Oct 2003 10:56:38 -0500 (EST) Received: (qmail 30069 invoked by uid 65534); 29 Oct 2003 15:56:37 -0000 Received: from unknown (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp010) with SMTP; 29 Oct 2003 16:56:37 +0100 X-Authenticated: #1915285 Message-ID: <3F9FE335.706@gmx.de> Date: Wed, 29 Oct 2003 16:56:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: rfc2518-bis-05 issues (part 3) X-Archived-At: http://www.w3.org/mid/3F9FE335.706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031029155645.DCB13A0969@frink.w3.org> Resent-Date: Wed, 29 Oct 2003 10:56:45 -0500 (EST) Content-Transfer-Encoding: 7bit Hi. Below is a list of issues I raised against draft04 which IMHO have not been adequately addressed in the latest draft (see [1] for the original message). 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-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-C09, sect 8.1.3 ...speaks of "consistent" usage of addresses without precisely defining what that means. 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-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. 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-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. Update -05: this now reads: This can mean that the server reports the live property as "Not Found" if that's the most appropriate behavior for that live property at the destination, as long as the live property is still supported with the same semantics. I'm not sure I understand what that means. The contradiction is still there. "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-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". Update 05: this now says "single scope". That doesn't seem to be clearer. What does it mean? 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. Update -05: now it says PUT instead of GET. Aha! Anyway, I don't think this belongs into a description of a live property. 04-C31, section 14.6 "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. (note the term occurs twice, only one instance was changed; also, just use "property name" -- this includes both local name and namespace). 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 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. Update -05: the sentence with the reference was removed. Why not keep it and just fix the reference? 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-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 [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 30 16: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 QAA11997 for ; Thu, 30 Oct 2003 16:18:20 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 95E9AA0710; Thu, 30 Oct 2003 16:18:29 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 5780EA0710 for ; Thu, 30 Oct 2003 16:18:26 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id E26A613651; Thu, 30 Oct 2003 16:18:25 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 0A4CF135BD for ; Thu, 30 Oct 2003 16:18:25 -0500 (EST) Received: (qmail 20864 invoked by uid 65534); 30 Oct 2003 21:18:24 -0000 Received: from p3EE24827.dip.t-dialin.net (EHLO gmx.de) (62.226.72.39) by mail.gmx.net (mp027) with SMTP; 30 Oct 2003 22:18:24 +0100 X-Authenticated: #1915285 Message-ID: <3FA1801B.7070008@gmx.de> Date: Thu, 30 Oct 2003 22:18:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: rfc2518-bis-05 issues (part 4) X-Archived-At: http://www.w3.org/mid/3FA1801B.7070008@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031030211829.95E9AA0710@frink.w3.org> Resent-Date: Thu, 30 Oct 2003 16:18:29 -0500 (EST) Content-Transfer-Encoding: 7bit This is a summary of either new issues or issues with changes between drafts 04 and 05. 05-C01 media types Looking at the current W3 TAG discussion about XML media types we may want to consider deprecating "text/xml" and making "application/xml" a SHOULD. 05-C02 "illformed" Section 8.1.1 s/ill-formed/non-wellformed/ 05-C03 OPTIONS * 9.1 contains the new paragraph: This header must also appear on responses to OPTIONS requests to the special '*' Request-URI as defined in HTTP/1.1. In this case it means that the repository supports the named features in at least some internal namespaces. 1) I don't remember this being discussed anywhere. 2) This is impossible to implement with the Java Servlet API, so it's unlikely to be implemented 3) This clearly contradicts RFC2616, sectopn 9.2 (): "If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof)." 05-C04 DAV request header Thanks for adding it, however I think we need to do some more work: As an optional request header, this header allows the client to advertise compliance with named features. Clients need not advertise 1, 2 or bis because a WebDAV server currently doesn't need that information to decide how to respond to requests defined in this specification or in HTTP/1.1. However, future extensions may define client compliance codes. When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests. 1) Just say generally that only those feature names are allowed where the spec explicitly defines what it means (in a request!). For RFC2518bis this means that none of the feature names defined here may be used. 2) "When used as a request header, the DAV header MAY affect caching so this header SHOULD NOT be used on all GET requests." - this is misleading. Either it is allowed on GET, or it isn't. If the request header affects a cacheable GET result, the origin server MUST specify that in the "Vary" header. 05-C05 Multistatus format Section 12: When a Multi-Status body is returned in response to a PROPFIND or another request with a single scope, all URLs appearing in the body must be equal to or inside the request-URI, thus the URLs MAY be absolute or MAY be relative. What is a "single" scope. Ans what does it mean for a URI to be "inside" another? It continues saying: When a Multi-Status body is returned in response to MOVE or COPY, relative URIs resolution is ambiguous (the request had both a source and a destination URL). Thus, URLs appearing in the responses to MOVE or COPY SHOULD be absolute and fully-qualified URLs. What is a "fully-qualified" URL? If this is meant to say that the URI, when relative, MUST start with a "/", then it should be more clear about that. 05-C06 12.1 3xx handling The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax as defined in RFC2518 did not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. Additionally, this specification defines a new element that servers MAY use in the response element to provide a location value in Multi-Status (see section 13.29). I think we can improve that: - "not to use" -- be clear what this means -- is it using a "200" status element instead? - when the server chooses not to return the 3xx code, should it include the location element nevertheless (I think it should) 05-C07 XML Extensibility (section 13) I still think we should make statements about extensibility once. The current notation (adding verbose text to each and every element description) just makes the spec less readable and harder to maintain. Note that already the descriptions are partly broken (for instance in 13.18). In particular: Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. s/SHOULD/MUST/ 05-C08 propfind DTD Says: Should be: 05-C09 Properties Some property values are calculated by the server and it is not appropriate to allow client changes, thus they are protected. Existing server implementations already have different sets of RFC2518 properties protected, but clients can have some expectations which properties are normally protected. The value of a protected property may not be changed even by a user with permission to edit other properties. The value of an unprotected property may be changed by some users with appropriate permissions. This definition seems to slightly differ from what RFC3253 says. That seems to be a bad idea (here is seems to identify "calculated" with "protected"; in RFC3253 there's a clear difference between "protected" and "computed"). 05-C10 Properties (COPY/MOVE behaviour) This somehow combines statements about how the property behaves upon COPY and MOVE (good) and some statements about what happens in "remote" operations. I think the latter is very confusing. Either a copy is done using COPY, or it isn't. If a server decides to emulate a copy operation using PROPPATCH and PUT, the standard considerations for these methods apply. 05-C11 "mandatory" properties This is actually an old issue. For instance: Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non-null state). Basically this says that the property should be there, unless it isn't. Just say that it's optional in these cases. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 31 11:36: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 LAA06420 for ; Fri, 31 Oct 2003 11:36:00 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id 7CCFDA06AA; Fri, 31 Oct 2003 11:36:12 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 8A4EFA06AA for ; Fri, 31 Oct 2003 11:36:09 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 69C1A13988; Fri, 31 Oct 2003 11:36:09 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id DD4C513C00 for ; Fri, 31 Oct 2003 11:36:08 -0500 (EST) Received: (qmail 21105 invoked by uid 65534); 31 Oct 2003 16:35:57 -0000 Received: from unknown (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 31 Oct 2003 17:35:57 +0100 X-Authenticated: #1915285 Message-ID: <3FA28F6A.4040807@gmx.de> Date: Fri, 31 Oct 2003 17:35:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: w3c-dist-auth@w3.org References: <3FA1801B.7070008@gmx.de> In-Reply-To: <3FA1801B.7070008@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: rfc2518-bis-05 issues (part 4) X-Archived-At: http://www.w3.org/mid/3FA28F6A.4040807@gmx.de To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8073 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031031163612.7CCFDA06AA@frink.w3.org> Resent-Date: Fri, 31 Oct 2003 11:36:12 -0500 (EST) Content-Transfer-Encoding: 7bit Here's another minor issue: 05-C12 location element DTD Section 13.29: Name: location Namespace: DAV: Purpose: In normal responses (not Multi-Status), some status codes go along with a Location header. When these status codes are used in a Multi-Status response, this element is used instead. Description: Contains a single href element with the same URI that would be used in a Location header. Extensibility: MAY be extended with additional child elements or attributes which SHOULD be ignored if not recognized. The DTD fragment should be: -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 31 11:46: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 LAA07640 for ; Fri, 31 Oct 2003 11:46:55 -0500 (EST) Received: by frink.w3.org (Postfix, from userid 59936) id B9221A0E9E; Fri, 31 Oct 2003 11:46:21 -0500 (EST) X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id 50F77A0E44 for ; Fri, 31 Oct 2003 11:46:02 -0500 (EST) Received: by dr-nick.w3.org (Postfix) id 53D3413FDC; Fri, 31 Oct 2003 11:42:08 -0500 (EST) Delivered-To: w3c-dist-auth@w3.org Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (Postfix) with SMTP id 8476B1425E for ; Fri, 31 Oct 2003 11:42:07 -0500 (EST) Received: (qmail 11315 invoked by uid 65534); 31 Oct 2003 16:42:03 -0000 Received: from unknown (EHLO gmx.de) (217.5.201.10) by mail.gmx.net (mp014) with SMTP; 31 Oct 2003 17:42:03 +0100 X-Authenticated: #1915285 Message-ID: <3FA290DA.2030801@gmx.de> Date: Fri, 31 Oct 2003 17:42:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: redirect ref spec: pseudo property issue resolved X-Archived-At: http://www.w3.org/mid/3FA290DA.2030801@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/8074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: <20031031164621.B9221A0E9E@frink.w3.org> Resent-Date: Fri, 31 Oct 2003 11:46:21 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, I have updated to use the new DAV:location extension element (inside DAV:response), as specified in RFC2518bis-05 (thanks, Lisa!). This change resolves another two open last call issues regarding the usage of pseudo properties. Note that this change *does* introduce an incompatibility to older drafts!. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760