From w3c-dist-auth-request@w3.org Thu Jun 5 14:47: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 OAA10589 for ; Thu, 5 Jun 2003 14:47:23 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55IlNe7029882; Thu, 5 Jun 2003 14:47:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h55Il8ce029764; Thu, 5 Jun 2003 14:47:08 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 14:47:08 -0400 (EDT) Resent-Message-Id: <200306051847.h55Il8ce029764@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55Il6e7029730 for ; Thu, 5 Jun 2003 14:47:06 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h55Il5iC019857 for ; Thu, 5 Jun 2003 14:47:06 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h55Iinb28894 for ; Thu, 5 Jun 2003 11:44:49 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 5 Jun 2003 11:48:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Meeting at IETF-57 in Vienna X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGENPHLAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7629 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI, there will be a WebDAV Working Group meeting at the Vienna IETF meeting (IETF-57). Currently the meeting is scheduled for Tuesday, July 15, 2003, in the afternoon (this day/time is subject to change). For more information on the IETF-57 meeting, including how to register, and it's exact location: http://www.ietf.org/meetings/IETF-57.html - Jim From w3c-dist-auth-request@w3.org Thu Jun 5 17:17:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17549 for ; Thu, 5 Jun 2003 17:17:21 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55LHMe7020353; Thu, 5 Jun 2003 17:17:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h55LHJc1020325; Thu, 5 Jun 2003 17:17:19 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 17:17:19 -0400 (EDT) Resent-Message-Id: <200306052117.h55LHJc1020325@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55LHHe7020289 for ; Thu, 5 Jun 2003 17:17:17 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h55LHFiC030724 for ; Thu, 5 Jun 2003 17:17:15 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19O26k-0004ql-00; Thu, 05 Jun 2003 21:17:14 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19O26k-0004qa-00; Thu, 05 Jun 2003 21:17:14 +0000 From: "Lisa Dusseault" To: "'Jim Whitehead'" , "'WebDAV'" Date: Thu, 5 Jun 2003 14:17:19 -0700 Message-ID: <03e001c32ba7$d961bd60$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: ejw@cse.ucsc.edu, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h55LHHe7020289 Subject: RE: Meeting at IETF-57 in Vienna X-Archived-At: http://www.w3.org/mid/03e001c32ba7$d961bd60$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7630 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit The cutoff date for submitting new drafts of existing documents before the Vienna meeting is June 30 (and the cutoff for new drafts is a week earlier). Let's use this as a deadline to try to get our various documents updated so we can discuss them and/or progress them: - ACL - RFC2518 bis - Bindings - Search - Quota In addition, our charter is sadly out of date. If somebody is interested in taking a stab at bringing that up-to-date it would be greatly appreciated. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Whitehead > Sent: Thursday, June 05, 2003 11:48 AM > To: WebDAV > Subject: Meeting at IETF-57 in Vienna > > > > FYI, there will be a WebDAV Working Group meeting at the > Vienna IETF meeting (IETF-57). Currently the meeting is > scheduled for Tuesday, July 15, 2003, in the afternoon (this > day/time is subject to change). > > For more information on the IETF-57 meeting, including how to > register, and it's exact location: > http://www.ietf.org/meetings/IETF-57.html - Jim From w3c-dist-auth-request@w3.org Thu Jun 5 18:24: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 SAA20577 for ; Thu, 5 Jun 2003 18:24:19 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55MOKe7003361; Thu, 5 Jun 2003 18:24:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h55MOCWW003277; Thu, 5 Jun 2003 18:24:12 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 18:24:12 -0400 (EDT) Resent-Message-Id: <200306052224.h55MOCWW003277@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h55MOAe7003225 for ; Thu, 5 Jun 2003 18:24:10 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h55MO5iC013418 for ; Thu, 5 Jun 2003 18:24:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20567; Thu, 5 Jun 2003 18:24:02 -0400 (EDT) Message-Id: <200306052224.SAA20567@ietf.org> To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: The IESG Reply-to: iesg@ietf.org Date: Thu, 05 Jun 2003 18:24:02 -0400 Subject: Last Call: WebDAV Ordered Collections Protocol to Proposed Standard X-Archived-At: http://www.w3.org/mid/200306052224.SAA20567@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7631 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The IESG has received a request from the WWW Distributed Authoring and Versioning Working Group to consider WebDAV Ordered Collections Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-08.txt From w3c-dist-auth-request@w3.org Mon Jun 9 12:45: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 MAA11716 for ; Mon, 9 Jun 2003 12:45:48 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h59Gjpe7019876; Mon, 9 Jun 2003 12:45:51 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h59GjCcC019768; Mon, 9 Jun 2003 12:45:12 -0400 (EDT) Resent-Date: Mon, 9 Jun 2003 12:45:12 -0400 (EDT) Resent-Message-Id: <200306091645.h59GjCcC019768@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h59GjAe7019731 for ; Mon, 9 Jun 2003 12:45:10 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.9/8.12.9) with SMTP id h59Gj8iC004911 for ; Mon, 9 Jun 2003 12:45:09 -0400 Received: from lisa ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Mon, 09 Jun 2003 18:44:22 +0200 From: "Julian Reschke" To: "Chris Newman" , Cc: , Date: Mon, 9 Jun 2003 18:44: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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <2147483647.1054926753@nifty-jr.west.sun.com> X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Last Call: WebDAV Ordered Collections Protocol to Proposed Standard X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEGPHIAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7632 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, You are right -- the last call draft doesn't try to specify server maintained orderings. Looking at your draft, it seems to apply to server-side sorting, which may have it's place in WebDAV SEARCH [1]. Note that the plan for WebDAV SEARCH is to make use of collations as defined in XSLT 2.0 and XQuery, once they become ready. So you may want to check how your work fits into that framework as well. As far as I understand, there's currently nobody working actively on WebDAV ordered collections with server-maintained orderings. So I don't think it's a good idea to delay publication of this work to cover something nobody currently is interested in. Regards, Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM] > Sent: Saturday, June 07, 2003 4:13 AM > To: iesg@ietf.org > Cc: w3c-dist-auth@w3.org; julian.reschke@greenbytes.de; ejw@cse.ucsc.edu > Subject: Re: Last Call: WebDAV Ordered Collections Protocol to Proposed > Standard > > > I wrote a draft which attempts to create a framework for > server-side ordering > that can be consumed by multiple IETF protocols: > > http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-00.txt > > I request that an expert in the webdav community review my draft > to make sure > that is compatible with the webdav ordering draft. From a brief > skim of the > webdav ordering draft it appears it has left "server-maintained" > ordering as a > future work item, so I expect no problems. However, it would be a good > validation of the webdav ordering extensibility model to confirm it is > compatible. > > It is possible the webdav ordering draft could support server-maintained > ordering through a relatively minor revision to reference my > draft. While that > would undoubtedly cause some delay in final publication, it may be worth > consideration by the working group. > > - Chris > > begin quotation by The IESG on 2003/6/5 18:24 -0400: > > > > > The IESG has received a request from the WWW Distributed Authoring > > and Versioning Working Group to consider WebDAV Ordered Collections > > Protocol as a Proposed > > Standard. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-19. > > > > Files can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-pro > tocol-08.txt > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Jun 12 07:00: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 HAA03024 for ; Thu, 12 Jun 2003 07:00:05 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5CB06Sn006237; Thu, 12 Jun 2003 07:00:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5CAxlHr006118; Thu, 12 Jun 2003 06:59:47 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 06:59:47 -0400 (EDT) Resent-Message-Id: <200306121059.h5CAxlHr006118@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5CAxjSn006085 for ; Thu, 12 Jun 2003 06:59:45 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5CAxiiC003956 for ; Thu, 12 Jun 2003 06:59:45 -0400 Received: (qmail 18891 invoked by uid 65534); 12 Jun 2003 10:59:38 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011) with SMTP; 12 Jun 2003 12:59:38 +0200 From: "Julian Reschke" To: "WebDAV" Cc: , "Jim Whitehead" Date: Thu, 12 Jun 2003 12:59:38 +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: Consideration of WebDAV Ordered Collections Protocol as Proposed Standard X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOENKHIAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7633 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. Ted Hardie has raised the following issue with the current draft of the ordering protocol... In section 6.1 we say: "Note to implementors: this specification does not mandate a specific implementation of MOVE operations within the same parent collection. Therefore, servers may either implement this as a simple rename operation (preserving the collection member's position), or as a sequence of "remove" and "add" (causing the semantics of "adding a new member" to apply). Future revisions of this specification may specify this behaviour more precisely based on future implementation experience." The issue here is that *if* we don't want to mandate a specific server behaviour, we should at least give client developers some guidance about how to achieve what they want (in this case a simple "rename" within the same parent collection where the ordering -- if present -- is preserved). The pseudo-code for this would be: 1) PROPFIND/Depth 1 on parent collection, getting DAV:ordering-type 2) if DAV:ordering-type not present or == "dav:unordered", just proceed as before 3) determine position of member to be renamed (such as "first" or "after x") 4) add Position header to MOVE request, specifying the previous position This should work with both kinds of servers (the one implementing this as UNBIND/BIND will obey the Position header, the other one will simply ignore it and thereby preserve the ordering). Is everybody OK with this example being added to the draft? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jun 12 13:33: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 NAA20134 for ; Thu, 12 Jun 2003 13:33:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5CHXaSn015561; Thu, 12 Jun 2003 13:33:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5CHXG9X015386; Thu, 12 Jun 2003 13:33:16 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 13:33:16 -0400 (EDT) Resent-Message-Id: <200306121733.h5CHXG9X015386@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5CHXCSn015346 for ; Thu, 12 Jun 2003 13:33:12 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5CHXBiC019224 for ; Thu, 12 Jun 2003 13:33:12 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h5CHVTi16494 for ; Thu, 12 Jun 2003 10:31:29 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 12 Jun 2003 10:32: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 V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Consideration of WebDAV Ordered Collections Protocol as Proposed Standard X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEGIHNAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7634 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added "geoffrey.clemm@us.ibm.com" to the accept2 list. - Jim -----Original Message----- From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] Sent: Thursday, June 12, 2003 6:15 AM To: WebDAV Subject: [Moderator Action] RE: Consideration of WebDAV Ordered Collections Protocol as Proposed Standard Adding that is fine with me. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/12/2003 06:59:38 AM: > > Hi. > > Ted Hardie has raised the following issue with the current draft of the > ordering protocol... > > In section 6.1 we say: > > "Note to implementors: this specification does not mandate a specific > implementation of MOVE operations within the same parent collection. > Therefore, servers may either implement this as a simple rename operation > (preserving the collection member's position), or as a sequence of "remove" > and "add" (causing the semantics of "adding a new member" to apply). Future > revisions of this specification may specify this behaviour more precisely > based on future implementation experience." > > The issue here is that *if* we don't want to mandate a specific server > behaviour, we should at least give client developers some guidance about how > to achieve what they want (in this case a simple "rename" within the same > parent collection where the ordering -- if present -- is preserved). > > The pseudo-code for this would be: > > 1) PROPFIND/Depth 1 on parent collection, getting DAV:ordering-type > > 2) if DAV:ordering-type not present or == "dav:unordered", just proceed as > before > > 3) determine position of member to be renamed (such as "first" or "after x") > > 4) add Position header to MOVE request, specifying the previous position > > > This should work with both kinds of servers (the one implementing this as > UNBIND/BIND will obey the Position header, the other one will simply ignore > it and thereby preserve the ordering). > > Is everybody OK with this example being added to the draft? > > > Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Jun 17 15:18: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 PAA05511 for ; Tue, 17 Jun 2003 15:18:55 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HJItSn003163; Tue, 17 Jun 2003 15:18:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5HJIaXV003154; Tue, 17 Jun 2003 15:18:36 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 15:18:36 -0400 (EDT) Resent-Message-Id: <200306171918.h5HJIaXV003154@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HJIZSn003121 for ; Tue, 17 Jun 2003 15:18:35 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5HJIYiC002019 for ; Tue, 17 Jun 2003 15:18:35 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 17 Jun 2003 20:18:33 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id UAA02289 for ; Tue, 17 Jun 2003 20:17:37 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id UAA23137; Tue, 17 Jun 2003 20:17:36 +0100 (BST) Message-ID: <3EEF6950.8F3477BB@cs.bris.ac.uk> Date: Tue, 17 Jun 2003 20:17:36 +0100 From: "B. Shadgar" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: WebDAV effeciancy X-Archived-At: http://www.w3.org/mid/3EEF6950.8F3477BB@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7635 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I am wondering if somebody can reference me a practical statistic of comparing the HTTP functionality to the WebDAV functionality with regard to remote Web authoring. I'm especially interested about the rate of speed, security, and flexibility. Any thing more is most welcome. Thanks in advance for your help. Regards, Bita. From w3c-dist-auth-request@w3.org Tue Jun 17 15:29:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06302 for ; Tue, 17 Jun 2003 15:29:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HJTZSn004538; Tue, 17 Jun 2003 15:29:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5HJTXms004512; Tue, 17 Jun 2003 15:29:33 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 15:29:33 -0400 (EDT) Resent-Message-Id: <200306171929.h5HJTXms004512@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HJTWSn004479 for ; Tue, 17 Jun 2003 15:29:32 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5HJTWiC004097 for ; Tue, 17 Jun 2003 15:29:32 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19SM95-0005ib-00; Tue, 17 Jun 2003 19:29:31 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19SM94-0005iQ-00; Tue, 17 Jun 2003 19:29:30 +0000 From: "Lisa Dusseault" To: "'B. Shadgar'" , "'WebDAV'" Date: Tue, 17 Jun 2003 12:29:31 -0700 Message-ID: <028e01c33506$c7789430$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <3EEF6950.8F3477BB@cs.bris.ac.uk> Old-X-Envelope-To: shadgar@cs.bris.ac.uk, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5HJTWSn004479 Subject: RE: WebDAV effeciancy X-Archived-At: http://www.w3.org/mid/028e01c33506$c7789430$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7636 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Bita, What do you mean by comparing the HTTP functionality to the WebDAV functionality? WebDAV extends HTTP in order to do proper authoring, so there is no real functionality comparison based on authoring. HTTP doesn't do the authoring functions that WebDAV adds, that's why WebDAV had to add these fucntions. Since WebDAV extends HTTP: - they both have exactly the same theoretical speed/flexibility capabilities for downloading documents and uploading documents (these are the most common HTTP actions that are also common WebDAV actions) - they have exactly the same security features One could imagine doing performance comparisons between WebDAV functionality and, for example, the Microsoft FrontPage extensions which do many of the same functions. Or one could compare a WebDAV authoring site to a site using HTML forms for authoring (like Yahoo PageWizards). Perhaps I've misunderstood your question. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of B. Shadgar > Sent: Tuesday, June 17, 2003 12:18 PM > To: WebDAV > Subject: WebDAV effeciancy > > > > Hi all, > > I am wondering if somebody can reference me a practical > statistic of comparing the HTTP functionality to the WebDAV > functionality with regard to remote Web authoring. I'm > especially interested about the rate of speed, security, and > flexibility. Any thing more is most welcome. > > Thanks in advance for your help. > > Regards, > Bita. > > From w3c-dist-auth-request@w3.org Tue Jun 17 16:17: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 QAA08862 for ; Tue, 17 Jun 2003 16:17:23 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HKHNSn018886; Tue, 17 Jun 2003 16:17:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5HKGuE9018868; Tue, 17 Jun 2003 16:16:56 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 16:16:56 -0400 (EDT) Resent-Message-Id: <200306172016.h5HKGuE9018868@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HKGtSn018818 for ; Tue, 17 Jun 2003 16:16:55 -0400 (EDT) Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5HKGsiC017213 for ; Tue, 17 Jun 2003 16:16:55 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 17 Jun 2003 21:16:34 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id VAA12848; Tue, 17 Jun 2003 21:14:56 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id VAA23242; Tue, 17 Jun 2003 21:14:55 +0100 (BST) Message-ID: <3EEF76BE.C02C059B@cs.bris.ac.uk> Date: Tue, 17 Jun 2003 21:14:54 +0100 From: "B. Shadgar" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Lisa Dusseault , WebDAV References: <028e01c33506$c7789430$fdcb90c6@lisalap> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV effeciancy X-Archived-At: http://www.w3.org/mid/3EEF76BE.C02C059B@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7637 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Bita, > > What do you mean by comparing the HTTP functionality to the WebDAV > functionality? WebDAV extends HTTP in order to do proper authoring, so > there is no real functionality comparison based on authoring. HTTP doesn't > do the authoring functions that WebDAV adds, that's why WebDAV had to add > these fucntions. > > Since WebDAV extends HTTP: > - they both have exactly the same theoretical speed/flexibility > capabilities for downloading documents and uploading documents (these are > the most common HTTP actions that are also common WebDAV actions) > - they have exactly the same security features > > One could imagine doing performance comparisons between WebDAV functionality > and, for example, the Microsoft FrontPage extensions which do many of the > same functions. Or one could compare a WebDAV authoring site to a site > using HTML forms for authoring (like Yahoo PageWizards). > > Perhaps I've misunderstood your question. > > Lisa Lisa, I haven't expressed my question correctly - sorry. By WebDAV and HTTP, in fact I meant comparing the process of communication between the WebDAV servers and clients compare to the HTTP ones. I agree with you that WebDAV is an extension on HTTP and provide all functionality of the HTTP, added some new functionality regarding the metadata, access control, locking and so on. However, since there is more processing for those new functionality in environment based on the WebDAV protocol, I am wondering how much this would effect on the speed. Also many functionality of the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you mentioned like Microsoft FrontPage). So if the security is the same and if the speed may be low (not sure), why would the user choose WebDAV rather HTTP? Thanks, Bita. From w3c-dist-auth-request@w3.org Tue Jun 17 17:06:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11631 for ; Tue, 17 Jun 2003 17:06:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HL6WSn004872; Tue, 17 Jun 2003 17:06:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5HL6IOH004786; Tue, 17 Jun 2003 17:06:18 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 17:06:18 -0400 (EDT) Resent-Message-Id: <200306172106.h5HL6IOH004786@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HL6HSn004748 for ; Tue, 17 Jun 2003 17:06:17 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5HL6GiC000308 for ; Tue, 17 Jun 2003 17:06:16 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h5HL63228355 for ; Tue, 17 Jun 2003 14:06:05 -0700 (PDT) Message-ID: <3EEF82BB.5050804@cse.ucsc.edu> Date: Tue, 17 Jun 2003 14:06:03 -0700 From: Elias Sinderson 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: WebDAV References: <028e01c33506$c7789430$fdcb90c6@lisalap> <3EEF76BE.C02C059B@cs.bris.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WebDAV effeciancy X-Archived-At: http://www.w3.org/mid/3EEF82BB.5050804@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7638 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit B. Shadgar wrote: >[...] many functionality of the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you >mentioned like Microsoft FrontPage). So if the security is the same and if the speed may be low (not sure), why would the user choose WebDAV rather HTTP? > I'm actually implementing a SOAP-WebDAV proxy service that provides WebDAV functionality to clients that do not speak WebDAV, yet have a HTTP stack and can do XML processing (and, hence, SOAP as well). I'll be running some performance tests and can send them to you when they're available if you're still interested. Ignoring the performance issue momentarily, however, there are several reasons one should use WebDAV over HTTP POST, SOAP, and cetera. Without digressing into a full discussion of architectural styles and ideals not appropriate for this forum, I'll summarize what I feel is the main consideration. One of the reasons that the web has been so successful is that, at the protocol level, there is a standardized interface for interacting with web resources. WebDAV has extended the HTTP protocol to provide functionality necessary for distributed and collaborative authoring. SOAP breaks this genericity of interface by allowing arbitrary methods with arbitrary functionality to be exposed as a web service. So, while it is possible to provide WebDAV-like functionality using SOAP, there is no guarantee of interoperability between clients and servers taking this approach. Another, somewhat lesser, concern has to do with the opacity of URLs. A SOAP based web service that provides WebDAV functionality is essentially manipulating web resources indirectly; behind the scenes, as it were, so the resource you would address a PROPPATCH to isn't the same resource that you would address a GET to, even though you are intending them to be the same... Regarding performance, I have stong suspicions that straight WebDAV would be faster than any SOAP-based service due to the overhead in marshalling/demarshalling the request and response bodies. Again, I'll be testing this empirically in the next couple of months. That being said, there are compelling reasons why such a service might be desirable. As I mentioned above, some classes of devices don't support WebDAV, but can do SOAP over HTTP and it may be desireable to provide WebDAV functionality to these devices until their protocol stack is enhanced. Further, it allows one to insert extra processing (such as transactional support, for example) into the mix. This home grown solution is somewhat half-baked though, since it only allows for the client to interoperate with a single server/service implementation. Hope this has shed a little light on your questions... Cheers, Elias From w3c-dist-auth-request@w3.org Tue Jun 17 19:34: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 TAA16154 for ; Tue, 17 Jun 2003 19:34:53 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HNYtSn028776; Tue, 17 Jun 2003 19:34:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5HNYZLZ028724; Tue, 17 Jun 2003 19:34:35 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 19:34:35 -0400 (EDT) Resent-Message-Id: <200306172334.h5HNYZLZ028724@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5HNYXSn028691 for ; Tue, 17 Jun 2003 19:34:34 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5HNYXiC031583 for ; Tue, 17 Jun 2003 19:34:33 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19SPyC-0000ds-00; Tue, 17 Jun 2003 23:34:32 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19SPyB-0000dh-00; Tue, 17 Jun 2003 23:34:31 +0000 From: "Lisa Dusseault" To: , "'WebDAV'" Date: Tue, 17 Jun 2003 16:34:32 -0700 Message-ID: <02a201c33529$01dc1e40$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <3EEF76BE.C02C059B@cs.bris.ac.uk> Old-X-Envelope-To: shadgar@compsci.bristol.ac.uk, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5HNYXSn028691 Subject: RE: WebDAV effeciancy X-Archived-At: http://www.w3.org/mid/02a201c33529$01dc1e40$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7639 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I haven't expressed my question correctly - sorry. By WebDAV > and HTTP, in fact I meant comparing the process of > communication between the WebDAV servers and clients compare > to the HTTP ones. > > I agree with you that WebDAV is an extension on HTTP and > provide all functionality of the HTTP, added some new > functionality regarding the metadata, access control, locking > and so on. However, since there is more processing for those > new functionality in environment based on the WebDAV > protocol, I am wondering how much this would effect on the > speed. Also many functionality of the WebDAV can be > implemented by HTTP POST method, Soap and so on ( as you > mentioned like Microsoft FrontPage). So if the security is > the same and if the speed may be low (not sure), why would > the user choose WebDAV rather HTTP? > A WebDAV server can be implemented that has the same performance as an HTTP server, for the HTTP functions. THat is to say, as long as the server is being used only for HTTP functions, it would have the same performance and scalability. A thousand GET requests can theoretically be handled in the same time whether or not you've got WebDAV. When the server's usage includes WebDAV requests as well, obviously this can change things -- and now it really depends on the scenario. - When users start using WebDAV functionality, are they doing *more* requests? On top of the thousand GET requests per minute, are users now also doing a thousand PROPFIND requests? Obviously this is twice as many requests and takes more processing time on the server. - On the other hand, when users start using WebDAV does this *replace* HTTP requests? Imagine 500 of our 1000 GET requests are directory listings, so when WebDAV replaces the server generated directory listings, there are then 500 GET requests and 500 PROPFIND requests in an average period. Now the server can be *faster* because it should be faster to generate and send 500 PROPFIND responses than to compile 500 dynamically-generated GET responses with the same directory listings. That's because in the HTTP scenario the server is responsible for generating the presentation (in HTML) of the info, whereas in WebDAV the client is responsible for presentation. This kind of analysis can be extended. In general, and on average, I think we find that when the server has to do presentation it has more work to do, and thus has worse performance and worse scalability. WebDAV generally allows the server to do less presentation work, which should improve its performance and scalability (as long as the overall usage patterns do not change, which they might). An example of this was documented at Microsoft in the development of Outlook Web Access for Exchange 2000. When the server had to do all the presentation work itself, the OWA server could not handle so many users. When the server offloaded the presentation work using scripting, stylesheets and WebDAV, the number of users that could be handled increased by a very significant amount. If the client supported WebDAV without needing scripting and stylesheets (if it had all its own presentation logic) then even more clients could have been handled. So in a general authoring scenario, I would expect WebDAV to be much more scalable and high-performing than a HTTP interface that uses forms (like Yahoo PageWizards). Now let's consider FrontPage. FrontPage is very much like WebDAV in the semantic operations it defines. Thus, we would expect its performance to be very much like WebDAV. They both extend HTTP, it's just that FrontPage does it in different ways. But both FrontPage and WebDAV leave the presetnation layer to the client so they have similar characteristics. SOAP is an entirely theoretical case. There doesn't exist a set of authoring operations defined for SOAP. So how could we compare them? SOAP is a protocol for delivering XML payload but it doesn't define any schemas for payloads that would allow authoring operations, like LOCK and UNLOCK and metadata operations. If you were to write a new schema for SOAP to define authoring operations, since SOAP is based on HTTP as well it might be as scalable as WebDAV, but it would likely be less scalable (because there is overhead in SOAP that WebDAV doesn't seem to need). There are a number of factors you didn't mention, beyond performance/scalability, why a user would choose WebDAV authoring rather than a non-standard HTTP-based client authoring solution. - WebDAV allows clients to syncrhonize data in order to maintain sites (sitecopy), for offline usage or to run automated backups (Xythos WFC). - WebDAV allows clients to control the UI. Your UI can be Command-line (like cadaver) Mac-like (WebDAV-FS, Goliath) Windows Explorer (Xythos WFC, Web Folders) A search-oriented file "locator" rather than explorer (KCura) - WebDAV allows users to save straight from Office and Adobe authoring applications (and any other app that chooses to support WebDAV). This saves the upload step. - WebDAV allows the user/client to choose a language and supports sight/hearing disabled usage better than HTML. - WebDAV allows locks to be obtained automatically by the authoring application. HTTP-based authoring sites either don't support locking or make the user get locks manually (like www.sharemation.com) Beyond this I suggest you preorder my book, though it's not out quite yet. (http://www.amazon.com/exec/obidos/tg/detail/-/0130652083/qid=1055892821/sr= 1-1/ref=sr_1_1/103-3410589-6207009?v=glance&s=books) Lisa From w3c-dist-auth-request@w3.org Wed Jun 18 11:51: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 LAA13941 for ; Wed, 18 Jun 2003 11:51:29 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IFpVSn029877; Wed, 18 Jun 2003 11:51:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5IFpJmN029743; Wed, 18 Jun 2003 11:51:19 -0400 (EDT) Resent-Date: Wed, 18 Jun 2003 11:51:19 -0400 (EDT) Resent-Message-Id: <200306181551.h5IFpJmN029743@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IFpISn029685 for ; Wed, 18 Jun 2003 11:51:18 -0400 (EDT) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5IFpGiC002683 for ; Wed, 18 Jun 2003 11:51:17 -0400 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.11.6/8.9.3) id h5IFmXh24404; Wed, 18 Jun 2003 17:48:33 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 17:48:32 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Wed, 18 Jun 2003 17:48:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: BIND: precondition DAV:locked-update-allowed X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47F33@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7640 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: What return code should a BIND request return, if the precondition DAV:locked-update-allowed is violated, i.e. the collection identified by the request-URI is write-locked, but no appropriate token has been specified in an If request header? 1) 409 "Conflict" with in the response-body 2) 423 "Locked" 3) 423 "Locked" with in the response-body My feeling is that 2) would be correct. Thanks, Peter From w3c-dist-auth-request@w3.org Wed Jun 18 12:12: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 MAA14707 for ; Wed, 18 Jun 2003 12:12:42 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IGChSn006699; Wed, 18 Jun 2003 12:12:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5IGCgpi006683; Wed, 18 Jun 2003 12:12:42 -0400 (EDT) Resent-Date: Wed, 18 Jun 2003 12:12:42 -0400 (EDT) Resent-Message-Id: <200306181612.h5IGCgpi006683@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IGCeSn006650 for ; Wed, 18 Jun 2003 12:12:40 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5IGCdiC009961 for ; Wed, 18 Jun 2003 12:12:40 -0400 Received: (qmail 26320 invoked by uid 65534); 18 Jun 2003 16:12:33 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp027) with SMTP; 18 Jun 2003 18:12:33 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Wed, 18 Jun 2003 18:12:33 +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: BIND: precondition DAV:locked-update-allowed X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEKEHJAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7641 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd say that 3) would always be better (because more specific) than 2). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, Dr., Peter > Sent: Wednesday, June 18, 2003 5:48 PM > To: 'w3c-dist-auth@w3.org' > Subject: BIND: precondition DAV:locked-update-allowed > > > > What return code should a BIND request return, if the precondition > DAV:locked-update-allowed is violated, i.e. the collection > identified by the > request-URI is write-locked, but no appropriate token has been > specified in > an If request header? > > 1) 409 "Conflict" with in the > response-body > > 2) 423 "Locked" > > 3) 423 "Locked" with in the > response-body > > My feeling is that 2) would be correct. > > Thanks, > Peter > From w3c-dist-auth-request@w3.org Wed Jun 18 12: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 MAA15526 for ; Wed, 18 Jun 2003 12:35:54 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IGZtSn013397; Wed, 18 Jun 2003 12:35:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5IGZroP013374; Wed, 18 Jun 2003 12:35:53 -0400 (EDT) Resent-Date: Wed, 18 Jun 2003 12:35:53 -0400 (EDT) Resent-Message-Id: <200306181635.h5IGZroP013374@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IGZpSn013317 for ; Wed, 18 Jun 2003 12:35:51 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5IGZoiC016777 for ; Wed, 18 Jun 2003 12:35:51 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h5IGZW202269 for ; Wed, 18 Jun 2003 09:35:35 -0700 (PDT) Message-ID: <3EF094D4.7020602@cse.ucsc.edu> Date: Wed, 18 Jun 2003 09:35:32 -0700 From: Elias Sinderson 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: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: BIND: precondition DAV:locked-update-allowed X-Archived-At: http://www.w3.org/mid/3EF094D4.7020602@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7642 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think that, while (2) is correct, (3) is more correct as providing greater detail is preferred. Cheers, Elias Nevermann, Dr., Peter wrote: >What return code should a BIND request return, if the precondition >DAV:locked-update-allowed is violated, i.e. the collection identified by the >request-URI is write-locked, but no appropriate token has been specified in >an If request header? > >1) 409 "Conflict" with in the >response-body > >2) 423 "Locked" > >3) 423 "Locked" with in the >response-body > >My feeling is that 2) would be correct. > >Thanks, >Peter > > From w3c-dist-auth-request@w3.org Wed Jun 18 17:07: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 RAA00084 for ; Wed, 18 Jun 2003 17:07:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IL7xSn018022; Wed, 18 Jun 2003 17:07:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5IL6mad017708; Wed, 18 Jun 2003 17:06:48 -0400 (EDT) Resent-Date: Wed, 18 Jun 2003 17:06:48 -0400 (EDT) Resent-Message-Id: <200306182106.h5IL6mad017708@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5IL6kSn017672 for ; Wed, 18 Jun 2003 17:06:46 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5IL6kiC031689 for ; Wed, 18 Jun 2003 17:06:46 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19Sk8j-0002ks-00 for w3c-dist-auth@w3c.org; Wed, 18 Jun 2003 21:06:45 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19Sk8j-0002kh-00 for w3c-dist-auth@w3c.org; Wed, 18 Jun 2003 21:06:45 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 18 Jun 2003 14:06:46 -0700 Message-ID: <040801c335dd$87883100$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5IL6kSn017672 Subject: FW: Preparing WGs for the upcoming meeting in Vienna X-Archived-At: http://www.w3.org/mid/040801c335dd$87883100$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7643 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Pauls notes are great to prepare for an upcoming IETF ... -----Original Message----- From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org] On Behalf Of Paul Hoffman / VPNC Sent: Wednesday, June 11, 2003 9:56 AM To: wgchairs@ietf.org Subject: Preparing WGs for the upcoming meeting in Vienna Greetings again. The meeting in Vienna in a few weeks will probably be the first for many of the people in your WGs. A little WG-wide nudge a few weeks before the face-to-face meeting might get more effective results. This might be a good time to send a message to the WG mailing list, wearing your WG hat, reminding folks: - Newcomers can learn a lot ahead of time by reading the Tao of the IETF at . The newcomer orientation on Sunday (this year, at 1PM) is useful, but it is even more useful if they have read the Tao first. - It is a good idea to at least skim the WG archives for the past four months before the meeting to help prevent rehashing items that have already been decided and to help focus on items that need more review. - Similarly, it is a good idea to re-read the WG's charter before the meeting. Heck, many WG chairs could get value from this... - Many IETF areas have area-wide meetings. People who are interested in more than just one WG can get a feel for what is happening in other areas by going to these meetings. - The "Note Well" notice is serious. It can be found at , and will be given on paper in the registration packets. --Paul Hoffman, Director --VPN Consortium From w3c-dist-auth-request@w3.org Thu Jun 19 15:07: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 PAA11320 for ; Thu, 19 Jun 2003 15:07:27 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5JJ7MSn019536; Thu, 19 Jun 2003 15:07:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5JJ6Hu7019005; Thu, 19 Jun 2003 15:06:17 -0400 (EDT) Resent-Date: Thu, 19 Jun 2003 15:06:17 -0400 (EDT) Resent-Message-Id: <200306191906.h5JJ6Hu7019005@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5JJ6FSn018968 for ; Thu, 19 Jun 2003 15:06:15 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5JJ6EiC013576 for ; Thu, 19 Jun 2003 15:06:15 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h5JJ5Pi23334 for ; Thu, 19 Jun 2003 12:05:25 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 19 Jun 2003 12:06:49 -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 V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Problem: Apache + WebDav + CGI = Security Hole X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIEDEHPAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7644 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Jon Rifkin [mailto:jon@bluet.ucc.uconn.edu] Sent: Thursday, June 19, 2003 10:19 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Problem: Apache + WebDav + CGI = Security Hole Apache + WebDav + CGI = Security Hole THE PROBLEM I'm trying to provide a webserver that allows users to maintain separate websites and use WebDav to manage their content. After much development it has occurred to me that I've created a *serious security hole*, for while Apache/WebDav restricts users from each other's websites, CGI scripts have no such restriction, that is ... * Any user's CGI script can write into any another user's website. For example, suppose you have two websites webserver.org/alice webserver.org/bob where the websites 'alice' and 'bob' are managed by their respective webmasters. Webdav prevents Alice from writing in Bob's directory and vice versa. So far so good. But, suppose Alice and Bob upload CGI scripts to their websites. These scripts will be able to write *anywhere* in the webserver document tree, that is Alice's CGI script will be able to write into Bob's website and vice versa, because (1) Both Alice's and Bob's scripts run as the apache user. (2) The apache user town's the entire webserver document tree. (3) Thus, the script will be able to write in any website in the document tree. THE SOLUTION This is where I need help. Are there any easy and/or standard or even feasible ways to do this? I am currently investigating several ideas each with a unique set of tradeoffs. (1) Using a traditional Unix file system with separate users for each website and SuExec to enforce permissions on cgi-scripts. Will WebDav even run on such a configuration? I've never tried it. The down side for me is that Apache SuExec can only assign User,Group CGI permission according to Unix home directories (I had hoped to create website independent of the Unix user mechanism) or by Virtual Host, which means all my web sites must be Virtual Hosted and I must still assign Unix accounts. (2) Two instances of Apache, one instance on port 8080 running WebDav but *not* CGI for webmaster to upload content, the other instance on port 80 running CGI but *not* WebDav for normal web clients. The two instances would run as different Users,Groups so that CGI scripts will run as users who can read but not write to the document tree. The down side here is that CGI scripts will not be able to use the file system for storage. Any data stored from CGI scripts would need to be written to a database such as MySQL. (3) If I had 6 months to spend, maybe some combination of Apache module and kernel module would allow Apache to limit CGI script file access to specifically configured directories. This would require that the kernel support a relatively granular ACL for process dependent file access that can be manipulated by Apache. Any suggestions would be most welcome. - Jon Rifkin ============================================================================ == # Jon Rifkin # 860-486-5530 # jon.rifkin@uconn.edu # Information Technology Services # University of Connecticut From w3c-dist-auth-request@w3.org Fri Jun 20 10:02:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06607 for ; Fri, 20 Jun 2003 10:02:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5KE2BSn008087; Fri, 20 Jun 2003 10:02:11 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5KE11Lm007372; Fri, 20 Jun 2003 10:01:01 -0400 (EDT) Resent-Date: Fri, 20 Jun 2003 10:01:01 -0400 (EDT) Resent-Message-Id: <200306201401.h5KE11Lm007372@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5KE0xSn007339 for ; Fri, 20 Jun 2003 10:00:59 -0400 (EDT) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5KE0wiC010546 for ; Fri, 20 Jun 2003 10:00:58 -0400 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.11.6/8.9.3) id h5KE0uh21167; Fri, 20 Jun 2003 16:00:56 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 16:00:56 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Fri, 20 Jun 2003 16:00:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: BIND and DAV response header from OPTIONS X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47F37@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7645 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It is not specified in the Binding Extensions draft what to include in the DAV response header from an OPTIONS request when the server supports binding. Could it be e.g.: DAV: 1, 2, binding, .... ? Regards, Peter From w3c-dist-auth-request@w3.org Fri Jun 20 10: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 KAA07828 for ; Fri, 20 Jun 2003 10:14:39 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5KEEeSn012220; Fri, 20 Jun 2003 10:14:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5KEEUK3012178; Fri, 20 Jun 2003 10:14:30 -0400 (EDT) Resent-Date: Fri, 20 Jun 2003 10:14:30 -0400 (EDT) Resent-Message-Id: <200306201414.h5KEEUK3012178@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5KEETSn012143 for ; Fri, 20 Jun 2003 10:14:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5KEERiC015368 for ; Fri, 20 Jun 2003 10:14:28 -0400 Received: (qmail 12191 invoked by uid 65534); 20 Jun 2003 14:14:21 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003) with SMTP; 20 Jun 2003 16:14:21 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Fri, 20 Jun 2003 16:14:21 +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: BIND and DAV response header from OPTIONS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEABHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7646 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, Dr., Peter > Sent: Friday, June 20, 2003 4:01 PM > To: 'w3c-dist-auth@w3.org' > Subject: BIND and DAV response header from OPTIONS > > > > It is not specified in the Binding Extensions draft what to include in the > DAV response header from an OPTIONS request when the server supports > binding. > > Could it be e.g.: > DAV: 1, 2, binding, .... ? It could. But then, what do you need it for? I'd assume that the "Allow" header, DAV:supported-method-set and DAV:supported-live-property-set would be sufficient? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jun 20 23:05: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 XAA17962 for ; Fri, 20 Jun 2003 23:05:01 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5L352Sn009556; Fri, 20 Jun 2003 23:05:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5L34nlk009400; Fri, 20 Jun 2003 23:04:49 -0400 (EDT) Resent-Date: Fri, 20 Jun 2003 23:04:49 -0400 (EDT) Resent-Message-Id: <200306210304.h5L34nlk009400@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5L34mSn009348 for ; Fri, 20 Jun 2003 23:04:48 -0400 (EDT) Received: from swordfish ([216.241.35.41]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5L34liC003506 for ; Fri, 20 Jun 2003 23:04:47 -0400 Received: from matt by swordfish with local (Exim 3.35 #1 (Debian)) id 19TYgD-0007tz-00 for ; Fri, 20 Jun 2003 21:04:41 -0600 Date: Fri, 20 Jun 2003 21:04:41 -0600 From: Matt Gushee To: w3c-dist-auth@w3.org Message-ID: <20030621030440.GB12229@swordfish> Reply-To: Matt Gushee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Subject: Prevalence of Digest Auth? X-Archived-At: http://www.w3.org/mid/20030621030440.GB12229@swordfish Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7647 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hello, all-- I am working on WebDAV support for the 4Suite XML server (http://4suite.org), and I am trying to determine, from a practical perspective, how important it is to provide Digest authentication. Of course, full compliance with the relevant specs is one of our goals, but due to time constraints that is probably not going to happen the first time around. Anyway, I have been trying to find out which WebDAV products (clients and servers both) actually use Digest authentication, but have found virtually no helpful information on the Web. Can anyone shed some light on this for me? Thanks in advance for any information you have. -- Matt Gushee When a nation follows the Way, Englewood, Colorado, USA Horses bear manure through mgushee@havenrock.com its fields; http://www.havenrock.com/ When a nation ignores the Way, Horses bear soldiers through its streets. --Lao Tzu (Peter Merel, trans.) From w3c-dist-auth-request@w3.org Sat Jun 21 18:04: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 SAA16539 for ; Sat, 21 Jun 2003 18:04:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LM46Sn010516; Sat, 21 Jun 2003 18:04:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5LM2iba009916; Sat, 21 Jun 2003 18:02:44 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 18:02:44 -0400 (EDT) Resent-Message-Id: <200306212202.h5LM2iba009916@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LM2fSn009863 for ; Sat, 21 Jun 2003 18:02:41 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5LM2fiC003839 for ; Sat, 21 Jun 2003 18:02:41 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19TqRU-0005dm-00 for w3c-dist-auth@w3c.org; Sat, 21 Jun 2003 22:02:40 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19TqRT-0005db-00 for w3c-dist-auth@w3c.org; Sat, 21 Jun 2003 22:02:39 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 21 Jun 2003 15:02:45 -0700 Message-ID: <003e01c33840$d84f6490$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5LM2fSn009863 Subject: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/003e01c33840$d84f6490$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7648 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit One of the remaining issues on how lock-null resources have been replaced by locked empty resources (resources whose behavior is normal, rather than different, and just happen to be locked and empty) is what Content-Type to use. I had previously favoured a specific Content-type just so all servers behaved identically, and that's what most recently appears in the draft. However, Julian's arguments are swaying me. Here's our recent exchange on this subject: > > > 7.4.: "SHOULD default to a content-type of > > > "application/octet-stream". " > > > > > > No. I don't think there's consensus for that, and requiring a > > > specific content type seems to have no value at all to > clients (see > > > also 8.11, "Locking Unmapped URLs"). > > > > We disagree. I find that specificity improves the > interoperability of > > a standard. Nobody has explained why specificity hurts in > this case. > > But in fact, nobody has stated how it helps either. For all > practical purposes, clients will treat > application/octet-stream and a missing content type the same > way. However, when there is no content type header, a client > is *allowed* to guess, while it's not allowed to do that when > it's present. > I hadn't thought that a client ought to know when it may guess the content-type. OTOH, there is no content-type to guess, so I'm not sure it helps to leave it null. So here's some possible new language: A locked empty resource: "SHOULD default to a null content-type. When the client sends a PUT request to overwrite the empty resource with a body the client SHOULD provide the correct content-type, and the server MUST then set the content-type." Does this violate HTTP -- IOW, does HTTP require a content-type for all resources? Is that requirement a theoretical, or practical requirement, or neither? Should we discuss elsewhere whether a resource may exist with a null content-type and a non-zero length body? Should we discuss what the client or server do in that case? Another idea occurred to me that we could define a content-type specifically for "unknown" or "empty" body though that would have more ramifications. What else needs to be said? Lisa From w3c-dist-auth-request@w3.org Sat Jun 21 19:27: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 TAA18501 for ; Sat, 21 Jun 2003 19:27:14 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LNRHSn017172; Sat, 21 Jun 2003 19:27:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5LNRDQs017151; Sat, 21 Jun 2003 19:27:13 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 19:27:13 -0400 (EDT) Resent-Message-Id: <200306212327.h5LNRDQs017151@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LNRCSn017118 for ; Sat, 21 Jun 2003 19:27:12 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5LNRBiC014410 for ; Sat, 21 Jun 2003 19:27:11 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19TrlH-0005tM-00 for w3c-dist-auth@w3c.org; Sat, 21 Jun 2003 23:27:11 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19TrlG-0005tB-00 for w3c-dist-auth@w3c.org; Sat, 21 Jun 2003 23:27:10 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 21 Jun 2003 16:27:15 -0700 Message-ID: <004401c3384c$a6a44800$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5LNRCSn017118 Subject: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/004401c3384c$a6a44800$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7649 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Currently rfc2518bis-03 says: "HTTP 1.1 suggests the use of the ETag header in responses to GET and PUT requests. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem. A client might fail to renew a lock, for example when the lock times out and the client is accidentally offline or in the middle of a long upload. When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user whether it has changed. Timestamps do not solve this problem nearly as well as ETags. "WebDAV servers SHOULD support strong ETags for all resources that may be PUT. 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. "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. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed." Some history on how we got here: RFC2518 doesn't require ETags, nor does HTTP. But the overwrite problem isn't truly soluble without support for ETags (or some other untested new mechanism). Thus, at the early-2003 interim meeting, the attendees agreed to strengthen requirements for ETags. Draft 2518bis-02 required: "WebDAV servers MUST support ETags correctly and MUST return the ETag header in all GET and PUT responses. " However this was argued on the list to be too strong, and was weakened to the language already shown in -03. So, what now? Does the current language (03) make mod_dav or IIS (or other implementations) uncompliant with 03? Is that a problem? Would it be a bad idea to upgrade mod_dav or IIS to become compliant with RFC2518bis if it goes to RFC with these requirements? I'd point out that there are other changes that already make servers slightly uncompliant with RFC2518bis -- e.g. the removal of specially-behaving lock-null resources makes existing servers supporting lock-null resources "uncompliant". But being uncompliant with a spec that the server doesn't declare compliance to shouldn't be a problem! A server will continue to be compliant with 2518 because that can never be replaced. Server implementors may upgrade their code/product to become compliant with RF2518BIS (whatever rfc number that turns out to be) and then declare compliance with that new, more stable standard. IF the language must be weakened, is there any point to this at all? I'm afraid we've got to make a hard choice. Either we do something real to encourage ETag support, even though it makes existing servers "uncompliant". Or we do nothing, and we leave the problem unmitigated. As a server implementor, my personal opinion is that it's a good idea to make, and follow, stricter requirements for ETag support. It's so helpful to clients and users (in terms of robust and reliable distributed authoring) that it's worth the cost. Lisa From w3c-dist-auth-request@w3.org Sat Jun 21 19:55: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 TAA18767 for ; Sat, 21 Jun 2003 19:55:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LNtxSn019339; Sat, 21 Jun 2003 19:55:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5LNtv4I019314; Sat, 21 Jun 2003 19:55:57 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 19:55:57 -0400 (EDT) Resent-Message-Id: <200306212355.h5LNtv4I019314@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5LNtuSn019281 for ; Sat, 21 Jun 2003 19:55:56 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5LNttiC017443 for ; Sat, 21 Jun 2003 19:55:55 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19TsD4-0005yG-00 for w3c-dist-auth@w3.org; Sat, 21 Jun 2003 23:55:54 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19TsD4-0005y5-00 for w3c-dist-auth@w3.org; Sat, 21 Jun 2003 23:55:54 +0000 From: "Lisa Dusseault" To: Date: Sat, 21 Jun 2003 16:55:56 -0700 Message-ID: <004501c33850$aa2ef890$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5LNtuSn019281 Subject: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/004501c33850$aa2ef890$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7650 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Are there any more opinions on the use of DTDs? Has the consensus reversed? I thought the consensus was clear way back when I made the change to move from a specific list of children to the definition form of ANY (where appropriate) plus a list of possible children in English rather than DTD. Originally, there was a lot of discussion that overall seemed to favour DTDs that allowed both extensibility and validation. FOr example: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0242.html - Juergen Reuter http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0055.html - Jim Amsden http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0082.html - James Hunt http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0201.html - Julian Reschke http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0060.html - Lauren Wood http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0061.html ^ Are we back to the idea of throwing out the DTDs altogether? That would be OK by me. Sometimes English can be more accurate than a limited formal language. Say, why do so many names on this list begin with 'J'? Clearly Geoff should spell his name Jeoff & I should change my name to Jelisa or something. Lisa > I agree with all of his points. The only one I was tempted > to question was "Section 13: XML element definitions", where > he suggested going back to the old syntax for DTD's. But > upon further reflection, although I believe the new more > flexible notation should be used when defining all new > elements, for compatibility with old servers, we should > probably maintain the element order defined by 2518, so I > actually agree with that point as well (:-). > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 18, 2003 7:52 AM > To: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > 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: > > locktoken?) > > > For consistency with RFC2518, RFC3253 and the ACL spec we > really should stay with the old notation. > From w3c-dist-auth-request@w3.org Sat Jun 21 22:32: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 WAA20942 for ; Sat, 21 Jun 2003 22:32:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5M2WsSn003063; Sat, 21 Jun 2003 22:32:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5M2WjoY003049; Sat, 21 Jun 2003 22:32:45 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 22:32:45 -0400 (EDT) Resent-Message-Id: <200306220232.h5M2WjoY003049@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5M2WiSn003016 for ; Sat, 21 Jun 2003 22:32:44 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5M2WhiC003441 for ; Sat, 21 Jun 2003 22:32:43 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19Tueo-0006Lb-00; Sun, 22 Jun 2003 02:32:42 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19Tuen-0006LQ-00; Sun, 22 Jun 2003 02:32:41 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Sat, 21 Jun 2003 19:32:46 -0700 Message-ID: <004a01c33866$912470d0$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: julian.reschke@gmx.de, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5M2WiSn003016 Subject: RE: Status of PROPFIND allprop/include X-Archived-At: http://www.w3.org/mid/004a01c33866$912470d0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7651 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I started putting the allprop/include proposal into RFC2518bis. THen I realized that in some of our discussions, we've leaned towards deprecating 'allprop' entirely in favour of 'propname' to help server performance (and client performance, at least in so far as client must still download the entire Multistatus response and parse it even when it contains useless info). How often do clients really want all the *values* of all dead properties? I understand readily how clients want to see a list of the names of all dead properties. But if I've added a dead property to my home directory which is called "sharefromstestuser_x0040_1_x003a_1501" in the namespace "http://www.xythos.com/namespaces/StorageServer" (this is how Sharemation remembers what your bookmarks are) what client cares what the value of that dead property is? Next question, what's the harm? Well, it takes time to look up all the values of dead properties, escape them or encapsulate them, marshal them in XML and send them down the wire. So the risk of making 'allprop' more useful through an 'include' syntax is that it makes 'allprop' more likely to be used even though much of the information returned may be useless. I think it might be even more useful and efficient to combine the 'propname' syntax with the specific list of all the properties the client really wants the values for. E.g. PROPFIND blah Host: foo.bar Content-Type: text/xml Now the client gets the property values that will truely be useful, plus find out the list of properties that exist that might or might not be useful. Comments? Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Sunday, May 04, 2003 12:46 PM > To: w3c-dist-auth@w3.org > Cc: Jim Whitehead; Lisa Dusseault > Subject: Status of PROPFIND allprop/include > > > Jim, Lisa, > > in > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0073.html I tried to summarize the consensus of the attendees at the interim meeting regarding the allprop/include issue. 1) I'd like to confirm that this was the solution we agreed upon? 2) I'd like to gather feedback on how we proceed with this change. One approach (a) would be that I update http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-03.htm l with the new marshalling and let this be published as experimental RFC (the drawback being that it uses elements in the DAV: namespace, thus should really be a WG submission). Another approach (b) would be to start a new WG document, and try to get it published as "proposed standard" ASAP. What I really *don't* want to do is to wait for RFC2518bis, partly because it's unclear when we'll be done with it, and also because at that point of time we really should already have interoperable implementations of this. Regards, Julian From w3c-dist-auth-request@w3.org Sun Jun 22 05:52: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 FAA08580 for ; Sun, 22 Jun 2003 05:52:12 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5M9phSn016148; Sun, 22 Jun 2003 05:51:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5M9pVng016124; Sun, 22 Jun 2003 05:51:31 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 05:51:31 -0400 (EDT) Resent-Message-Id: <200306220951.h5M9pVng016124@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5M9pTSn016087 for ; Sun, 22 Jun 2003 05:51:29 -0400 (EDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5M9pSiC032701 for ; Sun, 22 Jun 2003 05:51:28 -0400 Received: (qmail 23738 invoked by uid 65534); 22 Jun 2003 09:51:08 -0000 Received: from p3EE24724.dip.t-dialin.net (HELO lisa) (62.226.71.36) by mail.gmx.net (mp022) with SMTP; 22 Jun 2003 11:51:08 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Sun, 22 Jun 2003 11:50:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <004a01c33866$912470d0$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Status of PROPFIND allprop/include X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEDFHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7652 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > I started putting the allprop/include proposal into RFC2518bis. THen I Great! > realized that in some of our discussions, we've leaned towards deprecating > 'allprop' entirely in favour of 'propname' to help server performance (and > client performance, at least in so far as client must still download the > entire Multistatus response and parse it even when it contains useless > info). Yes, we did. We also discussed this in January during the Interim meeting, and therefore changed the syntax. Don't you remember? (I think by accident you've been looking at the original proposal rather the updated one). > How often do clients really want all the *values* of all dead > properties? I > understand readily how clients want to see a list of the names of all dead > properties. But if I've added a dead property to my home > directory which is > called "sharefromstestuser_x0040_1_x003a_1501" in the namespace > "http://www.xythos.com/namespaces/StorageServer" (this is how Sharemation > remembers what your bookmarks are) what client cares what the > value of that > dead property is? The client sometimes can be a library or a proxy/gateway that simply has no knowledge about what *it's* client will be interested in. Consider an API that offers access to dead properties of a remote resource. It will perform much better if it's able to simply get *all* properties in one request. > Next question, what's the harm? Well, it takes time to look up all the > values of dead properties, escape them or encapsulate them, > marshal them in > XML and send them down the wire. > > So the risk of making 'allprop' more useful through an 'include' syntax is > that it makes 'allprop' more likely to be used even though much of the > information returned may be useless. Yes, that's why ww decided to extend "prop" instead. > I think it might be even more useful and efficient to combine the > 'propname' > syntax with the specific list of all the properties the client > really wants > the values for. E.g. > > PROPFIND blah > Host: foo.bar > Content-Type: text/xml > > > > > > > > > > > > > Now the client gets the property values that will truely be useful, plus > find out the list of properties that exist that might or might not be > useful. 1) This breaks RFC2518 servers (prop and propname are not allowed at the same time) and 2) the client still will need to requests where before one was enough. So again, here's what we dicussed in January and agreed upon: --- during the WG meeting, we briefly discussed our allprop/include proposal (see [1] for latest draft). Among the attendees (:-)), there was consensus that a feature like this is useful and should be incorporated into RFC2518bis. A slight change was applied to the syntax -- instead of using DAV:allprop with a specific include extension, the logic was reversed, such as: ... named properties... The updated DTD for propfind thus would be: (one advantage being that we're not extending DAV:allprop which is already increasingly misnamed). --- (see ). BTW: in the meantime I updated my original proposal with an appendix describing January's agreement: Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 06:30: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 GAA09139 for ; Sun, 22 Jun 2003 06:30:01 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MAU3Sn023310; Sun, 22 Jun 2003 06:30:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MAU1BE023274; Sun, 22 Jun 2003 06:30:01 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 06:30:01 -0400 (EDT) Resent-Message-Id: <200306221030.h5MAU1BE023274@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MATxSn023208 for ; Sun, 22 Jun 2003 06:29:59 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MATwiC007114 for ; Sun, 22 Jun 2003 06:29:59 -0400 Received: (qmail 1111 invoked by uid 65534); 22 Jun 2003 10:29:47 -0000 Received: from p3EE24724.dip.t-dialin.net (HELO lisa) (62.226.71.36) by mail.gmx.net (mp002) with SMTP; 22 Jun 2003 12:29:47 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Sun, 22 Jun 2003 12:29:23 +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: <004501c33850$aa2ef890$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEDGHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7653 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, June 22, 2003 1:56 AM > To: w3c-dist-auth@w3.org > Subject: Reconsidering DTDs and validity (was RE: I-D > ACTION:draft-ietf-webdav-rfc2518bis-03.txt) > > > > > Are there any more opinions on the use of DTDs? Has the > consensus reversed? > I thought the consensus was clear way back when I made the change to move > from a specific list of children to the definition form of ANY (where > appropriate) plus a list of possible children in English rather > than DTD. Can you point to where this was discussed? > Originally, there was a lot of discussion that overall seemed to > favour DTDs > that allowed both extensibility and validation. FOr example: > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0242.html - > Juergen Reuter > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0055. > html - Jim > Amsden > http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0082.html - > James Hunt > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0201.html - > Julian Reschke > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0060.html - > Lauren Wood > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0061.html ^ > > Are we back to the idea of throwing out the DTDs altogether? Well. DTDs can *not* be used for validating WebDAV request/response bodies (hopefully we agree on that?). Thus new specs must make sure that they are clear about the fact that the role of DTD fragments. Usage of DTD fragments in RFC2518, RFC3253, ACL and the ordering spec *is* consistent. In the Ordering Spec I am trying to summarize how the DTD fragments need to be read [1]: . -- 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: 1. element names use the "DAV:" namespace, 2. element ordering is irrelevant, 3. extension elements (elements not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise, 4. extension attributes (attributes not already defined as valid for this element) may be added anywhere, except when explicitly stated otherwise. -- Again, this is consistent with all WebDAV specs that are RFCs (or hopefully will be soon). The change I'm objecting to is: > > 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: > > > > > locktoken?) > The "old" syntax in theory allows programmatic checking of XML bodies (with the caveats listed above), while the "new" syntax just uses prose. However, the main problem is it's inconsistency with all the other specs that we have. I would find it very confusing if the way DTD fragments in WebDAV specs need to be read depend on which spec (or which revision of a spec) you're looking at. Julian [1] From w3c-dist-auth-request@w3.org Sun Jun 22 07:09: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 HAA09730 for ; Sun, 22 Jun 2003 07:09:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MB9ZSn026051; Sun, 22 Jun 2003 07:09:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MB9S9J026021; Sun, 22 Jun 2003 07:09:28 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 07:09:28 -0400 (EDT) Resent-Message-Id: <200306221109.h5MB9S9J026021@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MB9QSn025984 for ; Sun, 22 Jun 2003 07:09:26 -0400 (EDT) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MB9KiC012033 for ; Sun, 22 Jun 2003 07:09:26 -0400 Received: from manyfish.co.uk ([62.253.142.244]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030622110919.SQXX16215.mta06-svc.ntlworld.com@manyfish.co.uk> for ; Sun, 22 Jun 2003 12:09:19 +0100 Received: from monolith.fishnet (localhost.localdomain [127.0.0.1]) by manyfish.co.uk (8.12.8/8.12.5) with ESMTP id h5MB7pST032027 for ; Sun, 22 Jun 2003 12:07:51 +0100 Received: (from joe@localhost) by monolith.fishnet (8.12.8/8.12.8/Submit) id h5MB7oA4032026 for w3c-dist-auth@w3.org; Sun, 22 Jun 2003 12:07:50 +0100 Date: Sun, 22 Jun 2003 12:07:50 +0100 From: Joe Orton To: w3c-dist-auth@w3.org Message-ID: <20030622110750.GA31836@manyfish.co.uk> Mail-Followup-To: w3c-dist-auth@w3.org References: <004501c33850$aa2ef890$fdcb90c6@lisalap> 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: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/20030622110750.GA31836@manyfish.co.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7654 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think it's important to retain some of the ordering constraints given by the DTD fragments in 2518 - specifically it is useful that a client can assume that in the response element, a propstat MUST be preceded by an href. Since a propstat cannot be interpreted without knowing which URI it applies to, if this constraint is missing, the client is required to be able to batch propstats in memory until the href arrives. With this constaint, propstats can always be processed on the fly. joe From w3c-dist-auth-request@w3.org Sun Jun 22 09: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 JAA11147 for ; Sun, 22 Jun 2003 09:50:25 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MDnKSn018111; Sun, 22 Jun 2003 09:49:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MDlTUx017872; Sun, 22 Jun 2003 09:47:29 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 09:47:29 -0400 (EDT) Resent-Message-Id: <200306221347.h5MDlTUx017872@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MDlRSn017839 for ; Sun, 22 Jun 2003 09:47:27 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MDlQiC002529 for ; Sun, 22 Jun 2003 09:47:27 -0400 Received: (qmail 4216 invoked by uid 65534); 22 Jun 2003 13:47:16 -0000 Received: from p3EE2480B.dip.t-dialin.net (HELO lisa) (62.226.72.11) by mail.gmx.net (mp025) with SMTP; 22 Jun 2003 15:47:16 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Sun, 22 Jun 2003 15:47:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <003e01c33840$d84f6490$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MDlRSn017839 Subject: RE: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEDIHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7655 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Lisa, > ... > I hadn't thought that a client ought to know when it may guess > the content-type. OTOH, there is no content-type to guess, so I'm > not sure it helps to leave it null. So here's some possible new language: > > A locked empty resource: > "SHOULD default to a null content-type. When the client sends a > PUT request to overwrite the empty resource with a body the > client SHOULD provide the correct content-type, and the server > MUST then set the content-type." I think the new wording would be much better. > Does this violate HTTP -- IOW, does HTTP require a content-type > for all resources? Is that requirement a theoretical, or > practical requirement, or neither? From [1]: "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream". " This sounds to me like a client MUST NOT ever guess the content type when it's supplied by the server. Thus the server should not try to guess the type itself, unless it happen to know it. > Should we discuss elsewhere whether a resource may exist with a > null content-type and a non-zero length body? Should we discuss > what the client or server do in that case? I think that is the same discussion. If we can agree on the fact that an absent content type is better than a "guessed" content type, this will automatically apply to those empty resources created by LOCK as well. > Another idea occurred to me that we could define a content-type > specifically for "unknown" or "empty" body though that would have > more ramifications. No no no. If the server doesn't know the content type, don't guess. The client may know more than the server. However, if the server starts guessing, a client MUST NOT try to guess on it's own. See [2]: "The following are the key architectural points of this finding: 1. MIME headers sent by a server are authoritative. [Design choice] 2. User agent behavior that misrepresents the user or the server is harmful. [Principle]" > What else needs to be said? I'm not sure how interoperability is improved by mandating a specific content type. An empty resource created by LOCK doesn't have entity body yet, so the question about the content type is really moot. Nobody knows until such time that the client actually PUTs something. Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 10:09: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 KAA12032 for ; Sun, 22 Jun 2003 10:09:44 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ME9jSn020582; Sun, 22 Jun 2003 10:09:45 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5ME7VBb020356; Sun, 22 Jun 2003 10:07:31 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 10:07:31 -0400 (EDT) Resent-Message-Id: <200306221407.h5ME7VBb020356@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ME7TSn020323 for ; Sun, 22 Jun 2003 10:07:29 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5ME7SiC004639 for ; Sun, 22 Jun 2003 10:07:29 -0400 Received: (qmail 10323 invoked by uid 65534); 22 Jun 2003 14:07:15 -0000 Received: from p3EE2480B.dip.t-dialin.net (HELO lisa) (62.226.72.11) by mail.gmx.net (mp006) with SMTP; 22 Jun 2003 16:07:15 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Sun, 22 Jun 2003 16:06:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <004401c3384c$a6a44800$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5ME7TSn020323 Subject: RE: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEDJHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7656 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > ... > > So, what now? Does the current language (03) make mod_dav or IIS > (or other implementations) uncompliant with 03? Is that a I think so, because both use a "promotion strategy", in which upon PUT only a weak ETag is returned, which, after some delay, is "promoted" into a strong ETag. > problem? Would it be a bad idea to upgrade mod_dav or IIS to > become compliant with RFC2518bis if it goes to RFC with these Of course that would be good, but these servers use this approach for a very good reason (being that they *can't' produce the strong variant at resource creation time). > requirements? I'd point out that there are other changes that > already make servers slightly uncompliant with RFC2518bis -- e.g. > the removal of specially-behaving lock-null resources makes > existing servers supporting lock-null resources "uncompliant". True. > But being uncompliant with a spec that the server doesn't declare > compliance to shouldn't be a problem! A server will continue to > be compliant with 2518 because that can never be replaced. Server > implementors may upgrade their code/product to become compliant > with RF2518BIS (whatever rfc number that turns out to be) and > then declare compliance with that new, more stable standard. True as well. My primary concern is that if we put in a change that isn't and furthermore *won't* be implemented by the two must widely used implementations, we have a severe problem with the spec. So it would be really good to understand the issue (maybe Greg Stein can say something about it) and find out whether at least Apache/mod_dav is going to be updated. I personally see no use in the "promotion" strategy. If you can't produce a useful ETag upon PUT, don't. > IF the language must be weakened, is there any point to this at > all? I'm afraid we've got to make a hard choice. Either we do > something real to encourage ETag support, even though it makes > existing servers "uncompliant". Or we do nothing, and we leave > the problem unmitigated. But then there's the risk that popular servers like mod_dav never will be updated to RFC2518bis conformance, just because it ask for things that can't be implemented. Or worse yet, the servers may claim compliance although they don't comply. So I agree to any kind of text that explains *why* strong ETags are important, but I object to make them mandatory unless we can at least mod_dav support them properly. > As a server implementor, my personal opinion is that it's a good > idea to make, and follow, stricter requirements for ETag support. > It's so helpful to clients and users (in terms of robust and > reliable distributed authoring) that it's worth the cost. How do you calculate the cost in the case of mod_dav/fs, where clearly robust strong ETags can't be calculated without having additional metadata? Keep in mind that mod_dav is just an extension to the base HTTP server, such mod_dav's ETag handling must be identical to Apache/Httpd's. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 10:23: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 KAA12666 for ; Sun, 22 Jun 2003 10:23:00 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MEN1Sn021520; Sun, 22 Jun 2003 10:23:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MEN0aV021502; Sun, 22 Jun 2003 10:23:00 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 10:23:00 -0400 (EDT) Resent-Message-Id: <200306221423.h5MEN0aV021502@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MEMwSn021469 for ; Sun, 22 Jun 2003 10:22:58 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MEMviC006230 for ; Sun, 22 Jun 2003 10:22:58 -0400 Received: (qmail 4421 invoked by uid 65534); 22 Jun 2003 14:22:42 -0000 Received: from p3EE2480B.dip.t-dialin.net (HELO lisa) (62.226.72.11) by mail.gmx.net (mp013) with SMTP; 22 Jun 2003 16:22:42 +0200 From: "Julian Reschke" To: "Joe Orton" , Date: Sun, 22 Jun 2003 16:22:19 +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: <20030622110750.GA31836@manyfish.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEDKHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7657 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton > Sent: Sunday, June 22, 2003 1:08 PM > To: w3c-dist-auth@w3.org > Subject: Re: Reconsidering DTDs and validity (was RE: I-D > ACTION:draft-ietf-webdav-rfc2518bis-03.txt) > > > > I think it's important to retain some of the ordering constraints given > by the DTD fragments in 2518 - specifically it is useful that a client I really don't care much about the issue. However, we really really need to decide this, and then stay consistent. The current situation obviously is problematic. *If* we decide that ordering *is* relevant, we should clarify that both servers and clients must reject messages that do not comply. I don't want to end up in a situation where some clients work with non-compliant servers, while others don't. However, my feeling is that *currently* almost everybody ignores the ordering, and that server behaviour is *not* consistent. Thus from a standards progress point of view, it would make sense for RFC2518bis just to state that the ordering is irrelevant. > can assume that in the response element, a propstat MUST be preceded by > an href. > > Since a propstat cannot be interpreted without knowing which URI it > applies to, if this constraint is missing, the client is required to be > able to batch propstats in memory until the href arrives. With this > constaint, propstats can always be processed on the fly. Stream processing of response bodies is a very interesting problem. However, I think even if you can rely on ordering, it is still hard. For instance, how do you process: http://www.foo.bar/file Box type A J.J. Johnson HTTP/1.1 200 OK HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. This is malformed: & A compliant client must reject this reponse, because the body is malformed. BTW: you will need to batch the propstat element until you've reached the DAV:status element (confirming it's a "200") anyway. I don't see a big difference to waiting for the closing response tag. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 13:26: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 NAA14348 for ; Sun, 22 Jun 2003 13:26:16 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MHPmSn005937; Sun, 22 Jun 2003 13:25:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MHPZD4005918; Sun, 22 Jun 2003 13:25:35 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 13:25:35 -0400 (EDT) Resent-Message-Id: <200306221725.h5MHPZD4005918@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MHPSSn005881 for ; Sun, 22 Jun 2003 13:25:28 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MHPSiC029033 for ; Sun, 22 Jun 2003 13:25:28 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19U8al-0000eG-00; Sun, 22 Jun 2003 17:25:27 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19U8al-0000e5-00; Sun, 22 Jun 2003 17:25:27 +0000 From: "Lisa Dusseault" To: "Jason Crawford" , "Webdav WG" Date: Sun, 22 Jun 2003 10:25:33 -0700 Message-ID: <006901c338e3$498f0ff0$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: ccjason@us.ibm.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MHPSSn005881 Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY X-Archived-At: http://www.w3.org/mid/006901c338e3$498f0ff0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7658 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit WRITE_DAV_PROP: This issue is at least addressed in RFC2518bis, if not completely closed. It was addressed separately for each property in the definition for that property. E.g. the definition for 'displayname' says "This property is live and MAY be protected." BACKGROUND "It would be helpful to note which specifications are considered to be necessary background reading for reading the WebDAV spec." Unless somebody comes up with specific suggestions what references to add, let's CLOSE this issue. NULL_RESOURCE: "Add a forward reference ... in the definition of Null Resource in the Terminology section." This definition is now gone, so the issue should be resolved REJECTED. CONSISTENCY: The issue is described as "Disagreement over whether a DAV URI namespace needs to be consistent." Roy suggested removing the following definition from RFC2518: "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." However, consistency is not a requirement. RFC2518 goes on: "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL namespace be consistent. However, certain WebDAV methods are prohibited from producing results that cause namespace inconsistencies." To proceed on this issue, somebody who agrees that there is a problem here needs to suggest new wording, since we can't simply remove the definition without rewriting or removing the next few paragraphs and the definitions of some methods. If nobody suggests new wording or explains why we need to remove a definition that isn't even a requirement, I suggest we keep it the way it is and resolve the issue CLOSED. (We can always reopen an issue if somebody later decides to propose something concrete.) Lisa From w3c-dist-auth-request@w3.org Sun Jun 22 13:55: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 NAA14667 for ; Sun, 22 Jun 2003 13:55:18 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MHtISn010270; Sun, 22 Jun 2003 13:55:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MHtGmA010251; Sun, 22 Jun 2003 13:55:16 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 13:55:16 -0400 (EDT) Resent-Message-Id: <200306221755.h5MHtGmA010251@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MHtCSn010218 for ; Sun, 22 Jun 2003 13:55:12 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MHtCiC001999 for ; Sun, 22 Jun 2003 13:55:12 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19U93X-0000hQ-00; Sun, 22 Jun 2003 17:55:11 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19U93X-0000hF-00; Sun, 22 Jun 2003 17:55:11 +0000 From: "Lisa Dusseault" To: "Jason Crawford" , "'Webdav WG'" Date: Sun, 22 Jun 2003 10:55:17 -0700 Message-ID: <006a01c338e7$711c8080$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: ccjason@us.ibm.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MHtCSn010218 Subject: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS X-Archived-At: http://www.w3.org/mid/006a01c338e7$711c8080$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7659 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit OVERLAP_5.3_AND_8.7.2: This issue is redundant with issue REMOVE_SECTION_5.3. Section 5.3 is removed so this issue must also be closed. XML_LANG_CLARIFY: This issue can be marked as "inBis" if not CLOSED. I believe the current language arouses no further objections: "XML's support for multiple human languages, using the “xml:lang” attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute." COPY_LIVE_PROPS: This issue can be marked as "inBis" if not CLOSED. A "COPY/MOVE behaviour" section was added to each property definition in 03 and changes made to section 8.10, and there have been no objections to this. 302_AND_MULTISTATUS: This issue can be marked as "inBis" if not CLOSED. Section 12 of draft -03 contains an explanation of how the Location header may appear on a Multistatus response and how the client must handle that. Lisa From w3c-dist-auth-request@w3.org Sun Jun 22 14:34:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15215 for ; Sun, 22 Jun 2003 14:33:55 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MIXfSn013066; Sun, 22 Jun 2003 14:33:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MIXbJv013034; Sun, 22 Jun 2003 14:33:37 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 14:33:37 -0400 (EDT) Resent-Message-Id: <200306221833.h5MIXbJv013034@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MIXZSn013001 for ; Sun, 22 Jun 2003 14:33:35 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MIXYiC006462 for ; Sun, 22 Jun 2003 14:33:35 -0400 Received: (qmail 27299 invoked by uid 65534); 22 Jun 2003 18:33:28 -0000 Received: from p3EE24720.dip.t-dialin.net (HELO lisa) (62.226.71.32) by mail.gmx.net (mp001) with SMTP; 22 Jun 2003 20:33:28 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Jason Crawford" , "Webdav WG" Date: Sun, 22 Jun 2003 20:33:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <006901c338e3$498f0ff0$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MIXZSn013001 Subject: RE: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEEAHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7660 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, June 22, 2003 7:26 PM > To: Jason Crawford; Webdav WG > Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, > CONSISTENCY > > > > > WRITE_DAV_PROP: This issue is at least addressed in RFC2518bis, > if not completely closed. It was addressed separately for each > property in the definition for that property. E.g. the > definition for 'displayname' says "This property is live and MAY > be protected." Agreed. We should close this after the next draft is submitted and everybody had a chance to look at it (unless it didn't change since -03 in case we can do that right now). > BACKGROUND "It would be helpful to note which specifications are > considered to be necessary background reading for reading the > WebDAV spec." Unless somebody comes up with specific suggestions > what references to add, let's CLOSE this issue. Agreed. > NULL_RESOURCE: "Add a forward reference ... in the definition of > Null Resource in the Terminology section." This definition is > now gone, so the issue should be resolved REJECTED. Agreed (note that the Terminology section indeed defines "null resource"). > CONSISTENCY: The issue is described as "Disagreement over > whether a DAV URI namespace needs to be consistent." Roy > suggested > .html> removing the following definition from RFC2518: > "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." > However, consistency is not a requirement. RFC2518 goes on: > "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL > namespace be consistent. However, certain WebDAV methods are > prohibited from producing results that cause namespace > inconsistencies." > To proceed on this issue, somebody who agrees that there is a > problem here needs to suggest new wording, since we can't simply > remove the definition without rewriting or removing the next few > paragraphs and the definitions of some methods. If nobody > suggests new wording or explains why we need to remove a > definition that isn't even a requirement, I suggest we keep it > the way it is and resolve the issue CLOSED. (We can always > reopen an issue if somebody later decides to propose something concrete.) I think 5.1 is sufficiently clear, so mark this one as closed. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 14:54: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 OAA15412 for ; Sun, 22 Jun 2003 14:54:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MIsASn016095; Sun, 22 Jun 2003 14:54:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MIs5Fl016069; Sun, 22 Jun 2003 14:54:05 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 14:54:05 -0400 (EDT) Resent-Message-Id: <200306221854.h5MIs5Fl016069@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MIs4Sn016036 for ; Sun, 22 Jun 2003 14:54:04 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MIs3iC009501 for ; Sun, 22 Jun 2003 14:54:03 -0400 Received: (qmail 6429 invoked by uid 65534); 22 Jun 2003 18:53:54 -0000 Received: from p3EE24720.dip.t-dialin.net (HELO lisa) (62.226.71.32) by mail.gmx.net (mp006) with SMTP; 22 Jun 2003 20:53:54 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Jason Crawford" , "'Webdav WG'" Date: Sun, 22 Jun 2003 20:53:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <006a01c338e7$711c8080$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MIs4Sn016036 Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEEBHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7661 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, June 22, 2003 7:55 PM > To: Jason Crawford; 'Webdav WG' > Subject: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, > COPY_LIVE_PROPS > > > > > OVERLAP_5.3_AND_8.7.2: This issue is redundant with issue > REMOVE_SECTION_5.3. Section 5.3 is removed so this issue must > also be closed. Agreed. > XML_LANG_CLARIFY: This issue can be marked as "inBis" if not > CLOSED. I believe the current language arouses no further objections: > "XML's support for multiple human languages, using the “xml:lang” > attribute, handles cases where the same character set is employed > by multiple human languages. Note that xml:lang scope is > recursive, so a xml:lang attribute on any element containing a > property name element applies to the property value unless it has > been overridden by a more locally scoped attribute." Agreed. > COPY_LIVE_PROPS: This issue can be marked as "inBis" if not > CLOSED. A "COPY/MOVE behaviour" section was added to each > property definition in 03 and changes made to section 8.10, and > there have been no objections to this. Agreed (should be closed when the next draft is available). > 302_AND_MULTISTATUS: This issue can be marked as "inBis" if not > CLOSED. Section 12 of draft -03 contains an explanation of how > the Location header may appear on a Multistatus response and how > the client must handle that. This currently says: "When the 302 and 303 status codes are returned as the only status code for a response, HTTP1.1 uses the Location response 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." What's the rationale for allowing servers not to return 3xx response status in multistatus? And what should they return *instead*? I think this needs more discussion... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Jun 22 15:22: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 PAA16831 for ; Sun, 22 Jun 2003 15:22:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MJM5Sn021101; Sun, 22 Jun 2003 15:22:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MJM28Q021071; Sun, 22 Jun 2003 15:22:02 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 15:22:02 -0400 (EDT) Resent-Message-Id: <200306221922.h5MJM28Q021071@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MJM0Sn020990 for ; Sun, 22 Jun 2003 15:22:00 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MJLxiC014143 for ; Sun, 22 Jun 2003 15:21:59 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19UAPW-0000tD-00; Sun, 22 Jun 2003 19:21:58 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19UAPV-0000t2-00; Sun, 22 Jun 2003 19:21:57 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Jason Crawford'" , "'Webdav WG'" Date: Sun, 22 Jun 2003 12:22:03 -0700 Message-ID: <006c01c338f3$90250720$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: ccjason@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MJM0Sn020990 Subject: RE: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY X-Archived-At: http://www.w3.org/mid/006c01c338f3$90250720$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7662 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sorry, I was sufficiently clear which were changed in 03. The null resource definition will be deleted in draft 04 -- I only got around to that recently. All the other changes were made in 03 and I currently do not have plans to change that text in 04. Obviously I'm working on 04 this weekend. I plan to submit the draft by the draft deadline if not before. Lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, June 22, 2003 11:33 AM > To: Lisa Dusseault; Jason Crawford; Webdav WG > Subject: RE: Issues and status, WRITE_DAV_PROP, BACKGROUND, > NULL_RESOURCE, CONSISTENCY > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Sunday, June 22, 2003 7:26 PM > > To: Jason Crawford; Webdav WG > > Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, > NULL_RESOURCE, > > CONSISTENCY > > > > > > > > > > WRITE_DAV_PROP: This issue is at least addressed in RFC2518bis, > > if not completely closed. It was addressed separately for each > > property in the definition for that property. E.g. the > > definition for 'displayname' says "This property is live and MAY > > be protected." > > Agreed. We should close this after the next draft is > submitted and everybody had a chance to look at it (unless it > didn't change since -03 in case we can do that right now). > > > BACKGROUND "It would be helpful to note which specifications are > > considered to be necessary background reading for reading the > > WebDAV spec." Unless somebody comes up with specific suggestions > > what references to add, let's CLOSE this issue. > > Agreed. > > > NULL_RESOURCE: "Add a forward reference ... in the definition of > > Null Resource in the Terminology section." This definition is > > now gone, so the issue should be resolved REJECTED. > > Agreed (note that the Terminology section indeed defines > "null resource"). > > > CONSISTENCY: The issue is described as "Disagreement over > > whether a DAV URI namespace needs to be consistent." Roy > > suggested > > > .html> removing the following definition from RFC2518: > > "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." > > However, consistency is not a requirement. RFC2518 goes on: > > "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL > > namespace be consistent. However, certain WebDAV methods are > > prohibited from producing results that cause namespace > > inconsistencies." > > To proceed on this issue, somebody who agrees that there is a > > problem here needs to suggest new wording, since we can't simply > > remove the definition without rewriting or removing the next few > > paragraphs and the definitions of some methods. If nobody > > suggests new wording or explains why we need to remove a > > definition that isn't even a requirement, I suggest we keep it > > the way it is and resolve the issue CLOSED. (We can always > > reopen an issue if somebody later decides to propose > something concrete.) > > I think 5.1 is sufficiently clear, so mark this one as closed. > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Sun Jun 22 15:35:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17040 for ; Sun, 22 Jun 2003 15:35:21 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MJZMSn024253; Sun, 22 Jun 2003 15:35:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MJZIIP024229; Sun, 22 Jun 2003 15:35:18 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 15:35:18 -0400 (EDT) Resent-Message-Id: <200306221935.h5MJZIIP024229@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MJZHSn024196 for ; Sun, 22 Jun 2003 15:35:17 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MJZGiC016461 for ; Sun, 22 Jun 2003 15:35:16 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19UAcO-0000xW-00; Sun, 22 Jun 2003 19:35:16 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19UAcN-0000xL-00; Sun, 22 Jun 2003 19:35:15 +0000 From: "Lisa Dusseault" To: "Jason Crawford" , "'Webdav WG'" Date: Sun, 22 Jun 2003 12:35:18 -0700 Message-ID: <007001c338f5$6bc6cec0$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: ccjason@us.ibm.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5MJZHSn024196 Subject: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/007001c338f5$6bc6cec0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7663 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED. Draft -03 says that MKCOL can return 302 and there have been no objections so far. IMPLIED_LWS: This issue can be marked "inBis" if not CLOSED. Draft -03 says that the HTTP rules are imported "including the rules about implied linear white-space." PUT_AND_INTERMEDIATE_COLLECTIONS: This issue can be marked "inBis" if not CLOSED. Draft -03 says "The server MUST NOT create those intermediate collections automatically.” INTEROP_DELETE_AND_MULTISTATUS: This is the old issue respecting how HTTP clients might be confused by a 207 response to a DELETE message, believing it to be a success message . Have we got consensus to continue using 207, on the basis that by now it would break far more WebDAV clients to *stop* using 207? - Julian says continue using 207 but has also proposed switching to a 4XX - Roy argues it violates RFC2616 - My vote is to continue using 207 - The interim meeting attendees in Jan 2003 were unanimous in continuing with 207 - John DeSoi points out that Netscape uses DELETE and 2XX should not be redefined - Bob Denny says let's not violate RFC2616 - Geoff Clemm might want to clarify his position I don't think we have consensus yet overall. Please discuss, clarify, or even simply restate your position. Lisa From w3c-dist-auth-request@w3.org Sun Jun 22 16:22: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 QAA17686 for ; Sun, 22 Jun 2003 16:22:53 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMsSn001991; Sun, 22 Jun 2003 16:22:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MKMqXG001969; Sun, 22 Jun 2003 16:22:52 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 16:22:52 -0400 (EDT) Resent-Message-Id: <200306222022.h5MKMqXG001969@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMkSn001873 for ; Sun, 22 Jun 2003 16:22:46 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMhiC023792 for ; Sun, 22 Jun 2003 16:22:44 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA27815 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Jun 2003 13:22:42 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA27784 sender obsfucated@us.ibm.com; Sun, 22 Jun 2003 13:22:40 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5MKM99X112122; Sun, 22 Jun 2003 16:22:09 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5MKM8VG026282; Sun, 22 Jun 2003 16:22:08 -0400 To: "Lisa Dusseault" Cc: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Jason Crawford Message-ID: Date: Sun, 22 Jun 2003 16:22:10 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/22/2003 16:22:08, Serialize complete at 06/22/2003 16:22:08 Content-Type: multipart/alternative; boundary="=_alternative 006EF47485256D4D_=" Subject: Re: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/OF258111A7.197C1410-ON85256D4D.006EA638@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7664 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006EF47485256D4D_= Content-Type: text/plain; charset="us-ascii" > As a server implementor, my personal opinion is that it's a good idea to make, > and follow, stricter requirements for ETag support. It's so helpful to clients > and users (in terms of robust and reliable distributed authoring) that it's > worth the cost. IMO... strong ETag support should be a SHOULD. It should be made clear why a server designer should support it and it should be up to the server designer to make the final informed decision based on all the constraints he faces. --=_alternative 006EF47485256D4D_= Content-Type: text/html; charset="us-ascii"
> As a server implementor, my personal opinion is that it's a good idea to make,
> and follow, stricter requirements for ETag support.  It's so helpful to clients
> and users (in terms of robust and reliable distributed authoring) that it's
> worth the cost.

IMO... strong ETag support should be a SHOULD.  It should be made clear
why a server designer should support it and it should be up to the server
designer to make the final informed decision based on all the constraints
he faces.
--=_alternative 006EF47485256D4D_=-- From w3c-dist-auth-request@w3.org Sun Jun 22 16:22: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 QAA17689 for ; Sun, 22 Jun 2003 16:22:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMwSn002054; Sun, 22 Jun 2003 16:22:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MKMw0K002047; Sun, 22 Jun 2003 16:22:58 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 16:22:58 -0400 (EDT) Resent-Message-Id: <200306222022.h5MKMw0K002047@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMkSn001871 for ; Sun, 22 Jun 2003 16:22:46 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MKMhiC023793 for ; Sun, 22 Jun 2003 16:22:44 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA27818 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Jun 2003 13:22:42 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA27783 sender obsfucated@us.ibm.com; Sun, 22 Jun 2003 13:22:40 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5MKM99X087118; Sun, 22 Jun 2003 16:22:09 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5MKM8VF026282; Sun, 22 Jun 2003 16:22:08 -0400 To: "Lisa Dusseault" Cc: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Jason Crawford Message-ID: Date: Sun, 22 Jun 2003 16:22:10 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/22/2003 16:22:07, Serialize complete at 06/22/2003 16:22:07 Content-Type: multipart/alternative; boundary="=_alternative 006E9D9A85256D4D_=" Subject: Re: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/OFF507CD84.80D78E15-ON85256D4D.006E36E6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7665 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E9D9A85256D4D_= Content-Type: text/plain; charset="us-ascii" On Saturday, 06/21/2003 at 03:02 MST, "Lisa Dusseault" wrote: > One of the remaining issues on how lock-null resources have been replaced by > locked empty resources (resources whose behavior is normal, rather than > different, and just happen to be locked and empty) is what Content-Type to > use. I had previously favoured a specific Content-type just so all servers > behaved identically, and that's what most recently appears in the draft. > However, Julian's arguments are swaying me. Here's our recent exchange on this > subject: I tend to agree with Lisa's thinking. (I don't understand Julian's :-)) Specificity is good. We should specify what should be returned (including possibly no Content-Type). We should specify this as a SHOULD, not a MUST. --=_alternative 006E9D9A85256D4D_= Content-Type: text/html; charset="us-ascii"
On Saturday, 06/21/2003 at 03:02 MST, "Lisa Dusseault" <nnlisa___at___xythos.com@smallcue.com> wrote:
> One of the remaining issues on how lock-null resources have been replaced by
> locked empty resources (resources whose behavior is normal, rather than
> different, and just happen to be locked and empty) is what Content-Type to
> use.  I had previously favoured a specific Content-type just so all servers
> behaved identically, and that's what most recently appears in the draft.  
> However, Julian's arguments are swaying me.  Here's our recent exchange on this
> subject:
I tend to agree with Lisa's thinking.  (I don't understand Julian's :-))
Specificity is good.  We should specify what should be returned (including
possibly no Content-Type).  We should specify this as a SHOULD, not a
MUST.
--=_alternative 006E9D9A85256D4D_=-- From w3c-dist-auth-request@w3.org Sun Jun 22 16:38:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17968 for ; Sun, 22 Jun 2003 16:38:37 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKcNSn005322; Sun, 22 Jun 2003 16:38:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MKc0TB005259; Sun, 22 Jun 2003 16:38:00 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 16:38:00 -0400 (EDT) Resent-Message-Id: <200306222038.h5MKc0TB005259@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKbxSn005226 for ; Sun, 22 Jun 2003 16:37:59 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5MKbwiC026016 for ; Sun, 22 Jun 2003 16:37:58 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA28523 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Jun 2003 13:37:58 -0700 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA28503 sender obsfucated@us.ibm.com; Sun, 22 Jun 2003 13:37:56 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5MKbPtd040768; Sun, 22 Jun 2003 16:37:25 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5MKbOq8134100; Sun, 22 Jun 2003 16:37:25 -0400 To: "Lisa Dusseault" Cc: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Jason Crawford Message-ID: Date: Sun, 22 Jun 2003 16:37:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/22/2003 16:37:24, Serialize complete at 06/22/2003 16:37:24 Content-Type: multipart/alternative; boundary="=_alternative 0070B83885256D4D_=" Subject: Re: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY X-Archived-At: http://www.w3.org/mid/OF771707F1.55D6A300-ON85256D4D.00707DA7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7666 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070B83885256D4D_= Content-Type: text/plain; charset="us-ascii" Sounds good. I've updated the issue document. --=_alternative 0070B83885256D4D_= Content-Type: text/html; charset="us-ascii"
Sounds good.  I've updated the issue document. --=_alternative 0070B83885256D4D_=-- From w3c-dist-auth-request@w3.org Sun Jun 22 16:38: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 QAA17988 for ; Sun, 22 Jun 2003 16:38:54 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKctSn005444; Sun, 22 Jun 2003 16:38:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5MKctMf005437; Sun, 22 Jun 2003 16:38:55 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 16:38:55 -0400 (EDT) Resent-Message-Id: <200306222038.h5MKctMf005437@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5MKcsSn005394 for ; Sun, 22 Jun 2003 16:38:54 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5MKcriC026116 for ; Sun, 22 Jun 2003 16:38:54 -0400 Received: (qmail 25105 invoked by uid 65534); 22 Jun 2003 20:38:47 -0000 Received: from p3EE24831.dip.t-dialin.net (HELO lisa) (62.226.72.49) by mail.gmx.net (mp016) with SMTP; 22 Jun 2003 22:38:47 +0200 From: "Julian Reschke" To: "Jason Crawford" , "Lisa Dusseault" Cc: "Webdav WG" Date: Sun, 22 Jun 2003 22:38:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C3390F.050F0930" 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: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEEFHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7667 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3390F.050F0930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jason, just to clarify: I don't have a problem specifying it, as long as we specify that *no* content type should be returned. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Sunday, June 22, 2003 10:22 PM To: Lisa Dusseault Cc: Webdav WG Subject: Re: RFC2518bis issue: content type for locked empty resource On Saturday, 06/21/2003 at 03:02 MST, "Lisa Dusseault" wrote: > One of the remaining issues on how lock-null resources have been replaced by > locked empty resources (resources whose behavior is normal, rather than > different, and just happen to be locked and empty) is what Content-Type to > use. I had previously favoured a specific Content-type just so all servers > behaved identically, and that's what most recently appears in the draft. > However, Julian's arguments are swaying me. Here's our recent exchange on this > subject: I tend to agree with Lisa's thinking. (I don't understand Julian's :-)) Specificity is good. We should specify what should be returned (including possibly no Content-Type). We should specify this as a SHOULD, not a MUST. ------=_NextPart_000_0011_01C3390F.050F0930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jason,
 
just=20 to clarify: I don't have a problem specifying it, as long as we specify = that=20 *no* content type should be returned.
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Sunday, June 22, 2003 10:22 PM
To: = Lisa=20 Dusseault
Cc: Webdav WG
Subject: Re: RFC2518bis = issue:=20 content type for locked empty resource


On Saturday, 06/21/2003 at 03:02 MST, "Lisa = Dusseault"=20 <nnlisa___at___xythos.com@smallcue.com> wrote:
> One of = the=20 remaining issues on how lock-null resources have been replaced by =
>=20 locked empty resources (resources whose behavior is normal, rather = than=20
> different, and just happen to be locked and empty) is what=20 Content-Type to
> use.  I had previously favoured a = specific=20 Content-type just so all servers
> behaved identically, and = that's what=20 most recently appears in the draft.  
> However, Julian's = arguments=20 are swaying me.  Here's our recent exchange on this
>=20 subject:
I tend to agree = with Lisa's=20 thinking.  (I don't understand Julian's :-))
Specificity is good.  We should = specify what=20 should be returned (including
possibly=20 no Content-Type).  We should specify this as a SHOULD, not = a=20
MUST. =
------=_NextPart_000_0011_01C3390F.050F0930-- From w3c-dist-auth-request@w3.org Mon Jun 23 07:31: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 HAA16678 for ; Mon, 23 Jun 2003 07:30:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBUbSn002002; Mon, 23 Jun 2003 07:30:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NBUQRT001975; Mon, 23 Jun 2003 07:30:26 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 07:30:26 -0400 (EDT) Resent-Message-Id: <200306231130.h5NBUQRT001975@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBUJSn001937 for ; Mon, 23 Jun 2003 07:30:19 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5NBUIiC018552 for ; Mon, 23 Jun 2003 07:30:19 -0400 Received: (qmail 21600 invoked by uid 65534); 23 Jun 2003 11:30:13 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009) with SMTP; 23 Jun 2003 13:30:13 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Jason Crawford" , "'Webdav WG'" Date: Mon, 23 Jun 2003 13:30:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <007001c338f5$6bc6cec0$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5NBUJSn001937 Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFGHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7668 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, June 22, 2003 9:35 PM > To: Jason Crawford; 'Webdav WG' > Subject: Issues: MKCOL_AND_302, IMPLIED_LWS, > PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS > > > > > > MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED. > Draft -03 says that MKCOL can return 302 and there have been no > objections so far. It doesn't say anything specific about MKCOL and redirects. Or am I missing something? Speaking of which: section 12.1 talks only about 302 and 303 in Multistatus. It should talk about all 3xx codes, in particular 301. > IMPLIED_LWS: This issue can be marked "inBis" if not CLOSED. > Draft -03 says that the HTTP rules are imported "including the > rules about implied linear white-space." Agreed. > PUT_AND_INTERMEDIATE_COLLECTIONS: This issue can be marked > "inBis" if not CLOSED. Draft -03 says "The server MUST NOT > create those intermediate collections automatically.” Agreed. > INTEROP_DELETE_AND_MULTISTATUS: This is the old issue respecting > how HTTP clients might be confused by a 207 response to a DELETE > message, believing it to be a success message > .html>. Have we got consensus to continue using 207, on the > basis that by now it would break far more WebDAV clients to > *stop* using 207? > > - Julian says continue using 207 but has also proposed switching to a 4XX > > > - Roy argues it violates RFC2616 > > > - My vote is to continue using 207 > > - The interim meeting attendees in Jan 2003 were unanimous in > continuing with 207 > > - John DeSoi points out that Netscape uses DELETE and 2XX should > not be redefined > > - Bob Denny says let's not violate RFC2616 > > - Geoff Clemm might want to clarify his position > > > I don't think we have consensus yet overall. Please discuss, > clarify, or even simply restate your position. I think Roy has made a very good point about clients that do DELETE and are not aware of 207 being a valid (error) code for DELETE. Thus my proposal is not to use 207 when the operation did not entirely succeed, but instead use a 4xx code (keeping the multistatus response body). I think at this point there are only few clients which will actually properly process a 207 on DELETE, and those can probably easily upgraded. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jun 23 07:49: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 HAA17115 for ; Mon, 23 Jun 2003 07:49:28 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBnSSn007513; Mon, 23 Jun 2003 07:49:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NBnFf6007475; Mon, 23 Jun 2003 07:49:15 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 07:49:15 -0400 (EDT) Resent-Message-Id: <200306231149.h5NBnFf6007475@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBnDSn007442 for ; Mon, 23 Jun 2003 07:49:13 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NBnDiC023880 for ; Mon, 23 Jun 2003 07:49:13 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5NBn49X130456 for ; Mon, 23 Jun 2003 07:49:04 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5NBn3p7069284 for ; Mon, 23 Jun 2003 07:49:03 -0400 In-Reply-To: To: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 07:48:57 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 07:49:03, Serialize complete at 06/23/2003 07:49:03 Content-Type: multipart/alternative; boundary="=_alternative 0040E7A885256D4E_=" Subject: RE: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, CONSISTENCY X-Archived-At: http://www.w3.org/mid/OFF9C35F6E.FD7E30D1-ON85256D4E.0040D564-85256D4E.0040E7AD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7669 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0040E7A885256D4E_= Content-Type: text/plain; charset="US-ASCII" I also agree we can close these issues. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/22/2003 02:33:18 PM: > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Sunday, June 22, 2003 7:26 PM > > To: Jason Crawford; Webdav WG > > Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE, > > CONSISTENCY > > > > > > > > > > WRITE_DAV_PROP: This issue is at least addressed in RFC2518bis, > > if not completely closed. It was addressed separately for each > > property in the definition for that property. E.g. the > > definition for 'displayname' says "This property is live and MAY > > be protected." > > Agreed. We should close this after the next draft is submitted and > everybody had a chance to look at it (unless it didn't change since > -03 in case we can do that right now). > > > BACKGROUND "It would be helpful to note which specifications are > > considered to be necessary background reading for reading the > > WebDAV spec." Unless somebody comes up with specific suggestions > > what references to add, let's CLOSE this issue. > > Agreed. > > > NULL_RESOURCE: "Add a forward reference ... in the definition of > > Null Resource in the Terminology section." This definition is > > now gone, so the issue should be resolved REJECTED. > > Agreed (note that the Terminology section indeed defines "null resource"). > > > CONSISTENCY: The issue is described as "Disagreement over > > whether a DAV URI namespace needs to be consistent." Roy > > suggested > > > .html> removing the following definition from RFC2518: > > "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." > > However, consistency is not a requirement. RFC2518 goes on: > > "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL > > namespace be consistent. However, certain WebDAV methods are > > prohibited from producing results that cause namespace > > inconsistencies." > > To proceed on this issue, somebody who agrees that there is a > > problem here needs to suggest new wording, since we can't simply > > remove the definition without rewriting or removing the next few > > paragraphs and the definitions of some methods. If nobody > > suggests new wording or explains why we need to remove a > > definition that isn't even a requirement, I suggest we keep it > > the way it is and resolve the issue CLOSED. (We can always > > reopen an issue if somebody later decides to propose something concrete.) > > I think 5.1 is sufficiently clear, so mark this one as closed. > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --=_alternative 0040E7A885256D4E_= Content-Type: text/html; charset="US-ASCII"
I also agree we can close these issues.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/22/2003 02:33:18 PM:

>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Sunday, June 22, 2003 7:26 PM
> > To: Jason Crawford; Webdav WG
> > Subject: Issues and status, WRITE_DAV_PROP, BACKGROUND, NULL_RESOURCE,
> > CONSISTENCY
> >
> >
> >
> >
> > WRITE_DAV_PROP:  This issue is at least addressed in RFC2518bis,
> > if not completely closed.  It was addressed separately for each
> > property in the definition for that property.  E.g. the
> > definition for 'displayname' says "This property is live and MAY
> > be protected."
>
> Agreed. We should close this after the next draft is submitted and
> everybody had a chance to look at it (unless it didn't change since
> -03 in case we can do that right now).
>
> > BACKGROUND "It would be helpful to note which specifications are
> > considered to be necessary background reading for reading the
> > WebDAV spec."  Unless somebody comes up with specific suggestions
> > what references to add, let's CLOSE this issue.
>
> Agreed.
>
> > NULL_RESOURCE: "Add a forward reference ... in the definition of
> > Null Resource in the Terminology section."  This definition is
> > now gone, so the issue should be resolved REJECTED.
>
> Agreed (note that the Terminology section indeed defines "null resource").
>
> > CONSISTENCY:  The issue is described as "Disagreement over
> > whether a DAV URI namespace needs to be consistent."  Roy
> > suggested
> > <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155
> > .html> removing the following definition from RFC2518:
> >    "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."
> > However, consistency is not a requirement.  RFC2518 goes on:
> >    "Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
> >    namespace be consistent.  However, certain WebDAV methods are
> >    prohibited from producing results that cause namespace
> >    inconsistencies."
> > To proceed on this issue, somebody who agrees that there is a
> > problem here needs to suggest new wording, since we can't simply
> > remove the definition without rewriting or removing the next few
> > paragraphs and the definitions of some methods.  If nobody
> > suggests new wording or explains why we need to remove a
> > definition that isn't even a requirement, I suggest we keep it
> > the way it is and resolve the issue CLOSED.  (We can always
> > reopen an issue if somebody later decides to propose something concrete.)
>
> I think 5.1 is sufficiently clear, so mark this one as closed.
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
--=_alternative 0040E7A885256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 07:58: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 HAA17310 for ; Mon, 23 Jun 2003 07:58:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBwaSn009910; Mon, 23 Jun 2003 07:58:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NBwZr7009888; Mon, 23 Jun 2003 07:58:35 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 07:58:35 -0400 (EDT) Resent-Message-Id: <200306231158.h5NBwZr7009888@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NBwXSn009830 for ; Mon, 23 Jun 2003 07:58:33 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NBwXiC026243 for ; Mon, 23 Jun 2003 07:58:33 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5NBwOxr176964 for ; Mon, 23 Jun 2003 07:58:24 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5NBwMJ3027390 for ; Mon, 23 Jun 2003 07:58:23 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 07:58:16 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 07:58:22, Serialize complete at 06/23/2003 07:58:22 Content-Type: multipart/alternative; boundary="=_alternative 0041C34285256D4E_=" Subject: RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/OFD5CADD42.9CE9E413-ON85256D4E.004108D9-85256D4E.0041C345@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7670 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0041C34285256D4E_= Content-Type: text/plain; charset="US-ASCII" I'd suggest that we start with a generic statement that DTD implied ordering is to be ignored, but that the definition of a particular element can explicitly declare that ordering matters. WRT this particular case, I don't think that the amount of memory/time required on the client to read in the propstat before knowing what URL it is for is significant enough to matter (but like Julian, I don't care strongly either way, so I wouldn't object if the consensus is to make ordering matter in this particular element). Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:22:19 AM: > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton > > Sent: Sunday, June 22, 2003 1:08 PM > > To: w3c-dist-auth@w3.org > > Subject: Re: Reconsidering DTDs and validity (was RE: I-D > > ACTION:draft-ietf-webdav-rfc2518bis-03.txt) > > > > > > > > I think it's important to retain some of the ordering constraints given > > by the DTD fragments in 2518 - specifically it is useful that a client > > I really don't care much about the issue. However, we really really need to > decide this, and then stay consistent. The current situation obviously is > problematic. > > *If* we decide that ordering *is* relevant, we should clarify that both > servers and clients must reject messages that do not comply. I don't want to > end up in a situation where some clients work with non-compliant servers, > while others don't. > > However, my feeling is that *currently* almost everybody ignores the > ordering, and that server behaviour is *not* consistent. Thus from a > standards progress point of view, it would make sense for RFC2518bis just to > state that the ordering is irrelevant. > > > can assume that in the response element, a propstat MUST be preceded by > > an href. > > > > Since a propstat cannot be interpreted without knowing which URI it > > applies to, if this constraint is missing, the client is required to be > > able to batch propstats in memory until the href arrives. With this > > constaint, propstats can always be processed on the fly. > > Stream processing of response bodies is a very interesting problem. However, > I think even if you can rely on ordering, it is still hard. For instance, > how do you process: > > > > http://www.foo.bar/file > > > > Box type A > > > J.J. Johnson > > > HTTP/1.1 200 OK > > > > HTTP/1.1 403 Forbidden > The user does not have access to > the DingALing property. > > > > This is malformed: & > > > A compliant client must reject this reponse, because the body is malformed. > > BTW: you will need to batch the propstat element until you've reached the > DAV:status element (confirming it's a "200") anyway. I don't see a big > difference to waiting for the closing response tag. > > > Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0041C34285256D4E_= Content-Type: text/html; charset="US-ASCII"
I'd suggest that we start with a generic statement that DTD implied
ordering is to be ignored, but that the definition of a particular
element can explicitly declare that ordering matters.  

WRT this particular case, I don't think that the amount of memory/time
required on the client to read in the propstat before knowing what
URL it is for is significant enough to matter (but like Julian,
I don't care strongly either way, so I wouldn't object if the consensus
is to make ordering matter in this particular element).

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:22:19 AM:

>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton
> > Sent: Sunday, June 22, 2003 1:08 PM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: Reconsidering DTDs and validity (was RE: I-D
> > ACTION:draft-ietf-webdav-rfc2518bis-03.txt)
> >
> >
> >
> > I think it's important to retain some of the ordering constraints given
> > by the DTD fragments in 2518 - specifically it is useful that a client
>
> I really don't care much about the issue. However, we really really need to
> decide this, and then stay consistent. The current situation obviously is
> problematic.
>
> *If* we decide that ordering *is* relevant, we should clarify that both
> servers and clients must reject messages that do not comply. I don't want to
> end up in a situation where some clients work with non-compliant servers,
> while others don't.
>
> However, my feeling is that *currently* almost everybody ignores the
> ordering, and that server behaviour is *not* consistent. Thus from a
> standards progress point of view, it would make sense for RFC2518bis just to
> state that the ordering is irrelevant.
>
> > can assume that in the response element, a propstat MUST be preceded by
> > an href.
> >
> > Since a propstat cannot be interpreted without knowing which URI it
> > applies to, if this constraint is missing, the client is required to be
> > able to batch propstats in memory until the href arrives.  With this
> > constaint, propstats can always be processed on the fly.
>
> Stream processing of response bodies is a very interesting problem. However,
> I think even if you can rely on ordering, it is still hard. For instance,
> how do you process:
>
>    <D:multistatus xmlns:D="DAV:">
>      <D:response>
>           <D:href>http://www.foo.bar/file</D:href>
>           <D:propstat>
>                <D:prop xmlns:R="http://www.foo.bar/boxschema/">
>                     <R:bigbox>
>                          <R:BoxType>Box type A</R:BoxType>
>                     </R:bigbox>
>                     <R:author>
>                          <R:Name>J.J. Johnson</R:Name>
>                     </R:author>
>                </D:prop>
>                <D:status>HTTP/1.1 200 OK</D:status>
>           </D:propstat>
>           <D:propstat>
>                <D:prop><R:DingALing/><R:Random/></D:prop>
>                <D:status>HTTP/1.1 403 Forbidden</D:status>
>                <D:responsedescription> The user does not have access to
>    the DingALing property.
>                </D:responsedescription>
>           </D:propstat>
>      </D:response>
>     This is malformed: &
>    </D:multistatus>
>
> A compliant client must reject this reponse, because the body is malformed.
>
> BTW: you will need to batch the propstat element until you've reached the
> DAV:status element (confirming it's a "200") anyway. I don't see a big
> difference to waiting for the closing response tag.
>
>
> Julian
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0041C34285256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 08:09: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 IAA17532 for ; Mon, 23 Jun 2003 08:09:50 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NC9oSn012872; Mon, 23 Jun 2003 08:09:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NC9nnl012847; Mon, 23 Jun 2003 08:09:49 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 08:09:49 -0400 (EDT) Resent-Message-Id: <200306231209.h5NC9nnl012847@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NC9mSn012813 for ; Mon, 23 Jun 2003 08:09:48 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NC9kiC028554 for ; Mon, 23 Jun 2003 08:09:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5NC9f9X022584 for ; Mon, 23 Jun 2003 08:09:41 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5NC9dp7034358 for ; Mon, 23 Jun 2003 08:09:40 -0400 In-Reply-To: To: "Webdav WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 08:09:33 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 08:09:40, Serialize complete at 06/23/2003 08:09:40 Content-Type: multipart/alternative; boundary="=_alternative 0042CBA285256D4E_=" Subject: RE: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/OFAEC5B9D4.A49FACD0-ON85256D4E.0042A61E-85256D4E.0042CBA4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7671 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0042CBA285256D4E_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian that the most/best we can do is explain why it is a SHOULD. In particular, making it a MUST is very likely to cause new client writers to write clients that will fail to to work with a large number of existing servers, and that I think would be a serious problem. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:06:55 AM: > > > ... > > > > So, what now? Does the current language (03) make mod_dav or IIS > > (or other implementations) uncompliant with 03? Is that a > > I think so, because both use a "promotion strategy", in which upon > PUT only a weak ETag is returned, which, after some delay, is > "promoted" into a strong ETag. > > > problem? Would it be a bad idea to upgrade mod_dav or IIS to > > become compliant with RFC2518bis if it goes to RFC with these > > Of course that would be good, but these servers use this approach > for a very good reason (being that they *can't' produce the strong > variant at resource creation time). > > > requirements? I'd point out that there are other changes that > > already make servers slightly uncompliant with RFC2518bis -- e.g. > > the removal of specially-behaving lock-null resources makes > > existing servers supporting lock-null resources "uncompliant". > > True. > > > But being uncompliant with a spec that the server doesn't declare > > compliance to shouldn't be a problem! A server will continue to > > be compliant with 2518 because that can never be replaced. Server > > implementors may upgrade their code/product to become compliant > > with RF2518BIS (whatever rfc number that turns out to be) and > > then declare compliance with that new, more stable standard. > > True as well. > > My primary concern is that if we put in a change that isn't and > furthermore *won't* be implemented by the two must widely used > implementations, we have a severe problem with the spec. So it would > be really good to understand the issue (maybe Greg Stein can say > something about it) and find out whether at least Apache/mod_dav is > going to be updated. > > I personally see no use in the "promotion" strategy. If you can't > produce a useful ETag upon PUT, don't. > > > IF the language must be weakened, is there any point to this at > > all? I'm afraid we've got to make a hard choice. Either we do > > something real to encourage ETag support, even though it makes > > existing servers "uncompliant". Or we do nothing, and we leave > > the problem unmitigated. > > But then there's the risk that popular servers like mod_dav never > will be updated to RFC2518bis conformance, just because it ask for > things that can't be implemented. Or worse yet, the servers may > claim compliance although they don't comply. > > So I agree to any kind of text that explains *why* strong ETags are > important, but I object to make them mandatory unless we can at > least mod_dav support them properly. > > > As a server implementor, my personal opinion is that it's a good > > idea to make, and follow, stricter requirements for ETag support. > > It's so helpful to clients and users (in terms of robust and > > reliable distributed authoring) that it's worth the cost. > > How do you calculate the cost in the case of mod_dav/fs, where > clearly robust strong ETags can't be calculated without having > additional metadata? Keep in mind that mod_dav is just an extension > to the base HTTP server, such mod_dav's ETag handling must be > identical to Apache/Httpd's. > > Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --=_alternative 0042CBA285256D4E_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian that the most/best we can do is explain why
it is a SHOULD.  In particular, making it a MUST is very likely
to cause new client writers to write clients that will fail to
to work with a large number of existing servers, and that I think
would be a serious problem.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:06:55 AM:

>
> > ...
> >
> > So, what now?  Does the current language (03) make mod_dav or IIS
> > (or other implementations) uncompliant with 03?  Is that a
>
> I think so, because both use a "promotion strategy", in which upon
> PUT only a weak ETag is returned, which, after some delay, is
> "promoted" into a strong ETag.
>
> > problem?  Would it be a bad idea to upgrade mod_dav or IIS to
> > become compliant with RFC2518bis if it goes to RFC with these
>
> Of course that would be good, but these servers use this approach
> for a very good reason (being that they *can't' produce the strong
> variant at resource creation time).
>
> > requirements?  I'd point out that there are other changes that
> > already make servers slightly uncompliant with RFC2518bis -- e.g.
> > the removal of specially-behaving lock-null resources makes
> > existing servers supporting lock-null resources "uncompliant".  
>
> True.
>
> > But being uncompliant with a spec that the server doesn't declare
> > compliance to shouldn't be a problem!  A server will continue to
> > be compliant with 2518 because that can never be replaced. Server
> > implementors may upgrade their code/product to become compliant
> > with RF2518BIS (whatever rfc number that turns out to be) and
> > then declare compliance with that new, more stable standard.
>
> True as well.
>
> My primary concern is that if we put in a change that isn't and
> furthermore *won't* be implemented by the two must widely used
> implementations, we have a severe problem with the spec. So it would
> be really good to understand the issue (maybe Greg Stein can say
> something about it) and find out whether at least Apache/mod_dav is
> going to be updated.
>
> I personally see no use in the "promotion" strategy. If you can't
> produce a useful ETag upon PUT, don't.
>
> > IF the language must be weakened, is there any point to this at
> > all?  I'm afraid we've got to make a hard choice.  Either we do
> > something real to encourage ETag support, even though it makes
> > existing servers "uncompliant".  Or we do nothing, and we leave
> > the problem unmitigated.
>
> But then there's the risk that popular servers like mod_dav never
> will be updated to RFC2518bis conformance, just because it ask for
> things that can't be implemented. Or worse yet, the servers may
> claim compliance although they don't comply.
>
> So I agree to any kind of text that explains *why* strong ETags are
> important, but I object to make them mandatory unless we can at
> least mod_dav support them properly.
>
> > As a server implementor, my personal opinion is that it's a good
> > idea to make, and follow, stricter requirements for ETag support.
> >  It's so helpful to clients and users (in terms of robust and
> > reliable distributed authoring) that it's worth the cost.  
>
> How do you calculate the cost in the case of mod_dav/fs, where
> clearly robust strong ETags can't be calculated without having
> additional metadata? Keep in mind that mod_dav is just an extension
> to the base HTTP server, such mod_dav's ETag handling must be
> identical to Apache/Httpd's.
>
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
--=_alternative 0042CBA285256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 08:20:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17798 for ; Mon, 23 Jun 2003 08:20:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NCKwSn015789; Mon, 23 Jun 2003 08:20:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NCKuOR015764; Mon, 23 Jun 2003 08:20:56 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 08:20:56 -0400 (EDT) Resent-Message-Id: <200306231220.h5NCKuOR015764@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NCKsSn015719 for ; Mon, 23 Jun 2003 08:20:54 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NCKriC030924 for ; Mon, 23 Jun 2003 08:20:54 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5NCKm9X091124 for ; Mon, 23 Jun 2003 08:20:48 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5NCKkJ3086802 for ; Mon, 23 Jun 2003 08:20:47 -0400 In-Reply-To: <007001c338f5$6bc6cec0$fdcb90c6@lisalap> To: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 08:20:39 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 08:20:46, Serialize complete at 06/23/2003 08:20:46 Content-Type: multipart/alternative; boundary="=_alternative 0043CFCD85256D4E_=" Subject: Re: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/OF4700CB8E.50482D5C-ON85256D4E.00435F4A-85256D4E.0043CFD0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7672 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0043CFCD85256D4E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIHJlc29sdXRpb25zIG9uIHRoZSBmaXJzdCAzIGlzc3VlcyBhcmUgZmluZSB3aXRoIG1lLiAg V1JUIHRvDQpJTlRFUk9QX0RFTEVURV9BTkRfTVVMVElTVEFUVVMsIG15IHBvc2l0aW9uIHdhcyB0 aGF0IGEgcGFydGlhbCBkZWxldGUNCmlzIGJldHRlciBjbGFzc2lmaWVkIGFzIGEgImZhaWx1cmUi IChpLmUuIGEgbmV3IDR4eCBjb2RlKSwgc28gdW5sZXNzDQp3ZSBpZGVudGlmaWVkIGEgY2xpZW50 IHRoYXQgcmVhbGx5IGRlcGVuZGVkIG9uIGEgMjA3IHJlc3BvbnNlIGZyb20NCkRFTEVURSwgSSdk IGJlIGluIGZhdm9yIG9mIG1ha2luZyB0aGlzIGNoYW5nZSAoaS5lLiBpbnRyb2R1Y2luZyBhDQo0 eHggY29kZSB0aGF0IG1lYW5zICJwYXJ0aWFsIGZhaWx1cmUiLCBhbmQgd2hvc2UgYm9keSBpcyB0 aGUgc2FtZQ0KREFWOm11bHRpc3RhdHVzIGN1cnJlbnRseSBmb3VuZCBpbiBhIDIwNykuDQoNCkNo ZWVycywNCkdlb2ZmIA0KDQpMaXNhIHdyb3RlIG9uIDA2LzIyLzIwMDMgMDM6MzU6MTggUE06DQoN Cj4gDQo+IA0KPiANCj4gTUtDT0xfQU5EXzMwMjogVGhpcyBpc3N1ZSBjYW4gYmUgbWFya2VkICJp bkJpcyIgaWYgbm90IENMT1NFRC4gDQo+IERyYWZ0IC0wMyBzYXlzIHRoYXQgTUtDT0wgY2FuIHJl dHVybiAzMDIgYW5kIHRoZXJlIGhhdmUgYmVlbiBubyANCj4gb2JqZWN0aW9ucyBzbyBmYXIuDQo+ IA0KPiBJTVBMSUVEX0xXUzogVGhpcyBpc3N1ZSBjYW4gYmUgbWFya2VkICJpbkJpcyIgaWYgbm90 IENMT1NFRC4gIERyYWZ0IA0KPiAtMDMgc2F5cyB0aGF0IHRoZSBIVFRQIHJ1bGVzIGFyZSBpbXBv cnRlZCAiaW5jbHVkaW5nIHRoZSBydWxlcyBhYm91dA0KPiBpbXBsaWVkIGxpbmVhciB3aGl0ZS1z cGFjZS4iDQo+IA0KPiBQVVRfQU5EX0lOVEVSTUVESUFURV9DT0xMRUNUSU9OUzogVGhpcyBpc3N1 ZSBjYW4gYmUgbWFya2VkICJpbkJpcyIgDQo+IGlmIG5vdCBDTE9TRUQuICBEcmFmdCAtMDMgc2F5 cyAiVGhlIHNlcnZlciBNVVNUIE5PVCBjcmVhdGUgdGhvc2UgDQo+IGludGVybWVkaWF0ZSBjb2xs ZWN0aW9ucyBhdXRvbWF0aWNhbGx5LuKAnQ0KPiANCj4gSU5URVJPUF9ERUxFVEVfQU5EX01VTFRJ U1RBVFVTOiBUaGlzIGlzIHRoZSBvbGQgaXNzdWUgcmVzcGVjdGluZyBob3cNCj4gSFRUUCBjbGll bnRzIG1pZ2h0IGJlIGNvbmZ1c2VkIGJ5IGEgMjA3IHJlc3BvbnNlIHRvIGEgREVMRVRFIA0KPiBt ZXNzYWdlLCBiZWxpZXZpbmcgaXQgdG8gYmUgYSBzdWNjZXNzIG1lc3NhZ2UgIDxodHRwOi8vbGlz dHMudzMuDQo+IG9yZy9BcmNoaXZlcy9QdWJsaWMvdzNjLWRpc3QtYXV0aC8xOTk5QXBySnVuLzAw NjIuaHRtbD4uICBIYXZlIHdlIA0KPiBnb3QgY29uc2Vuc3VzIHRvIGNvbnRpbnVlIHVzaW5nIDIw Nywgb24gdGhlIGJhc2lzIHRoYXQgYnkgbm93IGl0IA0KPiB3b3VsZCBicmVhayBmYXIgbW9yZSBX ZWJEQVYgY2xpZW50cyB0byAqc3RvcCogdXNpbmcgMjA3Pw0KPiANCj4gLSBKdWxpYW4gc2F5cyBj b250aW51ZSB1c2luZyAyMDcgYnV0IGhhcyBhbHNvIHByb3Bvc2VkIHN3aXRjaGluZyB0byBhIA0K NFhYDQo+IDxodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy93M2MtZGlzdC1hdXRo LzIwMDNKYW5NYXIvMDA0OS5odG1sPg0KPiA8aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9Q dWJsaWMvdzNjLWRpc3QtYXV0aC8yMDAzSmFuTWFyLzAwNjUuaHRtbD4NCj4gLSBSb3kgYXJndWVz IGl0IHZpb2xhdGVzIFJGQzI2MTYgDQo+IDxodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1 YmxpYy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA0Ni5odG1sPiANCg0KPiAtIE15IHZvdGUg aXMgdG8gY29udGludWUgdXNpbmcgMjA3DQo+IDxodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVz L1B1YmxpYy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA0NC5odG1sPg0KPiAtIFRoZSBpbnRl cmltIG1lZXRpbmcgYXR0ZW5kZWVzIGluIEphbiAyMDAzIHdlcmUgdW5hbmltb3VzIGluIA0KPiBj b250aW51aW5nIHdpdGggMjA3DQo+IDxodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1Ymxp Yy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA0NC5odG1sPg0KPiAtIEpvaG4gRGVTb2kgcG9p bnRzIG91dCB0aGF0IE5ldHNjYXBlIHVzZXMgREVMRVRFIGFuZCAyWFggc2hvdWxkIG5vdA0KPiBi ZSByZWRlZmluZWQNCj4gPGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3czYy1k aXN0LWF1dGgvMjAwM0phbk1hci8wMDU3Lmh0bWw+DQo+IC0gQm9iIERlbm55IHNheXMgbGV0J3Mg bm90IHZpb2xhdGUgUkZDMjYxNg0KPiA8aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJs aWMvdzNjLWRpc3QtYXV0aC8yMDAzSmFuTWFyLzAwNDguaHRtbD4NCj4gLSBHZW9mZiBDbGVtbSBt aWdodCB3YW50IHRvIGNsYXJpZnkgaGlzIHBvc2l0aW9uDQo+IDxodHRwOi8vbGlzdHMudzMub3Jn L0FyY2hpdmVzL1B1YmxpYy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA2NS5odG1sPg0KPiAN Cj4gSSBkb24ndCB0aGluayB3ZSBoYXZlIGNvbnNlbnN1cyB5ZXQgb3ZlcmFsbC4gIFBsZWFzZSBk aXNjdXNzLCANCj4gY2xhcmlmeSwgb3IgZXZlbiBzaW1wbHkgcmVzdGF0ZSB5b3VyIHBvc2l0aW9u Lg0KPiANCj4gTGlzYQ0KPiANCj4gDQo+IA0KDQo= --=_alternative 0043CFCD85256D4E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5UaGUgcmVzb2x1dGlvbnMgb24gdGhlIGZpcnN0IDMgaXNz dWVzIGFyZSBmaW5lIHdpdGgNCm1lLiAmbmJzcDtXUlQgdG88L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PklOVEVST1BfREVMRVRFX0FORF9NVUxUSVNUQVRVUywgbXkgcG9zaXRpb24g d2FzIHRoYXQNCmEgcGFydGlhbCBkZWxldGU8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PmlzIGJldHRlciBjbGFzc2lmaWVkIGFzIGEgJnF1b3Q7ZmFpbHVyZSZxdW90OyAoaS5lLg0K YSBuZXcgNHh4IGNvZGUpLCBzbyB1bmxlc3M8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PndlIGlkZW50aWZpZWQgYSBjbGllbnQgdGhhdCByZWFsbHkgZGVwZW5kZWQgb24gYSAyMDcN CnJlc3BvbnNlIGZyb208L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PkRFTEVURSwg SSdkIGJlIGluIGZhdm9yIG9mIG1ha2luZyB0aGlzIGNoYW5nZSAoaS5lLg0KaW50cm9kdWNpbmcg YTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+NHh4IGNvZGUgdGhhdCBtZWFucyAm cXVvdDtwYXJ0aWFsIGZhaWx1cmUmcXVvdDssIGFuZA0Kd2hvc2UgYm9keSBpcyB0aGUgc2FtZTwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+REFWOm11bHRpc3RhdHVzIGN1cnJlbnRs eSBmb3VuZCBpbiBhIDIwNykuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+ DQpDaGVlcnMsPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5HZW9mZiA8L3R0Pjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pkxpc2Egd3JvdGUgb24gMDYvMjIvMjAw MyAwMzozNToxOCBQTTo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IE1LQ09MX0FORF8zMDI6IFRoaXMgaXNzdWUgY2FuIGJlIG1hcmtlZCAmcXVvdDtpbkJp cyZxdW90OyBpZiBub3QgQ0xPU0VELg0KJm5ic3A7PGJyPg0KJmd0OyBEcmFmdCAtMDMgc2F5cyB0 aGF0IE1LQ09MIGNhbiByZXR1cm4gMzAyIGFuZCB0aGVyZSBoYXZlIGJlZW4gbm8gPGJyPg0KJmd0 OyBvYmplY3Rpb25zIHNvIGZhci48YnI+DQomZ3Q7IDxicj4NCiZndDsgSU1QTElFRF9MV1M6IFRo aXMgaXNzdWUgY2FuIGJlIG1hcmtlZCAmcXVvdDtpbkJpcyZxdW90OyBpZiBub3QgQ0xPU0VELg0K Jm5ic3A7RHJhZnQgPGJyPg0KJmd0OyAtMDMgc2F5cyB0aGF0IHRoZSBIVFRQIHJ1bGVzIGFyZSBp bXBvcnRlZCAmcXVvdDtpbmNsdWRpbmcgdGhlIHJ1bGVzDQphYm91dDxicj4NCiZndDsgaW1wbGll ZCBsaW5lYXIgd2hpdGUtc3BhY2UuJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBVVF9BTkRf SU5URVJNRURJQVRFX0NPTExFQ1RJT05TOiBUaGlzIGlzc3VlIGNhbiBiZSBtYXJrZWQgJnF1b3Q7 aW5CaXMmcXVvdDsNCjxicj4NCiZndDsgaWYgbm90IENMT1NFRC4gJm5ic3A7RHJhZnQgLTAzIHNh eXMgJnF1b3Q7VGhlIHNlcnZlciBNVVNUIE5PVCBjcmVhdGUNCnRob3NlIDxicj4NCiZndDsgaW50 ZXJtZWRpYXRlIGNvbGxlY3Rpb25zIGF1dG9tYXRpY2FsbHku4oCdPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IElOVEVST1BfREVMRVRFX0FORF9NVUxUSVNUQVRVUzogVGhpcyBpcyB0aGUgb2xkIGlzc3Vl IHJlc3BlY3RpbmcgaG93PGJyPg0KJmd0OyBIVFRQIGNsaWVudHMgbWlnaHQgYmUgY29uZnVzZWQg YnkgYSAyMDcgcmVzcG9uc2UgdG8gYSBERUxFVEUgPGJyPg0KJmd0OyBtZXNzYWdlLCBiZWxpZXZp bmcgaXQgdG8gYmUgYSBzdWNjZXNzIG1lc3NhZ2UgJm5ic3A7Jmx0O2h0dHA6Ly9saXN0cy53My48 YnI+DQomZ3Q7IG9yZy9BcmNoaXZlcy9QdWJsaWMvdzNjLWRpc3QtYXV0aC8xOTk5QXBySnVuLzAw NjIuaHRtbCZndDsuICZuYnNwO0hhdmUNCndlIDxicj4NCiZndDsgZ290IGNvbnNlbnN1cyB0byBj b250aW51ZSB1c2luZyAyMDcsIG9uIHRoZSBiYXNpcyB0aGF0IGJ5IG5vdyBpdCA8YnI+DQomZ3Q7 IHdvdWxkIGJyZWFrIGZhciBtb3JlIFdlYkRBViBjbGllbnRzIHRvICpzdG9wKiB1c2luZyAyMDc/ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0gSnVsaWFuIHNheXMgY29udGludWUgdXNpbmcgMjA3IGJ1 dCBoYXMgYWxzbyBwcm9wb3NlZCBzd2l0Y2hpbmcgdG8NCmEgNFhYPGJyPg0KJmd0OyAmbmJzcDsg Jmx0O2h0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3czYy1kaXN0LWF1dGgvMjAw M0phbk1hci8wMDQ5Lmh0bWwmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJmx0O2h0dHA6Ly9saXN0cy53 My5vcmcvQXJjaGl2ZXMvUHVibGljL3czYy1kaXN0LWF1dGgvMjAwM0phbk1hci8wMDY1Lmh0bWwm Z3Q7PGJyPg0KJmd0OyAtIFJveSBhcmd1ZXMgaXQgdmlvbGF0ZXMgUkZDMjYxNiAmbmJzcDs8YnI+ DQomZ3Q7ICZuYnNwOyAmbHQ7aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvdzNj LWRpc3QtYXV0aC8yMDAzSmFuTWFyLzAwNDYuaHRtbCZndDsNCjxicj4NCiZndDsgLSBNeSB2b3Rl IGlzIHRvIGNvbnRpbnVlIHVzaW5nIDIwNzxicj4NCiZndDsgJm5ic3A7ICZsdDtodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA0NC5o dG1sJmd0Ozxicj4NCiZndDsgLSBUaGUgaW50ZXJpbSBtZWV0aW5nIGF0dGVuZGVlcyBpbiBKYW4g MjAwMyB3ZXJlIHVuYW5pbW91cyBpbiA8YnI+DQomZ3Q7IGNvbnRpbnVpbmcgd2l0aCAyMDc8YnI+ DQomZ3Q7ICZuYnNwOyAmbHQ7aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvdzNj LWRpc3QtYXV0aC8yMDAzSmFuTWFyLzAwNDQuaHRtbCZndDs8YnI+DQomZ3Q7IC0gSm9obiBEZVNv aSBwb2ludHMgb3V0IHRoYXQgTmV0c2NhcGUgdXNlcyBERUxFVEUgYW5kIDJYWCBzaG91bGQgbm90 PGJyPg0KJmd0OyBiZSByZWRlZmluZWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbHQ7aHR0cDovL2xpc3Rz LnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvdzNjLWRpc3QtYXV0aC8yMDAzSmFuTWFyLzAwNTcuaHRt bCZndDs8YnI+DQomZ3Q7IC0gQm9iIERlbm55IHNheXMgbGV0J3Mgbm90IHZpb2xhdGUgUkZDMjYx Njxicj4NCiZndDsgJm5ic3A7ICZsdDtodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1Ymxp Yy93M2MtZGlzdC1hdXRoLzIwMDNKYW5NYXIvMDA0OC5odG1sJmd0Ozxicj4NCiZndDsgLSBHZW9m ZiBDbGVtbSBtaWdodCB3YW50IHRvIGNsYXJpZnkgaGlzIHBvc2l0aW9uPGJyPg0KJmd0OyAmbmJz cDsgJmx0O2h0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3czYy1kaXN0LWF1dGgv MjAwM0phbk1hci8wMDY1Lmh0bWwmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3QgdGhp bmsgd2UgaGF2ZSBjb25zZW5zdXMgeWV0IG92ZXJhbGwuICZuYnNwO1BsZWFzZSBkaXNjdXNzLA0K PGJyPg0KJmd0OyBjbGFyaWZ5LCBvciBldmVuIHNpbXBseSByZXN0YXRlIHlvdXIgcG9zaXRpb24u PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExpc2E8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQo8L3R0PjwvZm9udD4NCg== --=_alternative 0043CFCD85256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 09:37: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 JAA20015 for ; Mon, 23 Jun 2003 09:37:05 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4OSn022414; Mon, 23 Jun 2003 09:04:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5ND4Ovr022397; Mon, 23 Jun 2003 09:04:24 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 09:04:24 -0400 (EDT) Resent-Message-Id: <200306231304.h5ND4Ovr022397@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4NSn022313 for ; Mon, 23 Jun 2003 09:04:23 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4MiC006852 for ; Mon, 23 Jun 2003 09:04:22 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5ND4Hxr107694 for ; Mon, 23 Jun 2003 09:04:17 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5ND4Fp7166614 for ; Mon, 23 Jun 2003 09:04:16 -0400 In-Reply-To: MIME-Version: 1.0 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 09:04:04 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 09:04:15, Serialize complete at 06/23/2003 09:04:15 Content-Type: multipart/alternative; boundary="=_alternative 0047C91D85256D4E_=" Subject: RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt) X-Archived-At: http://www.w3.org/mid/OFBFFB8EC7.314A5889-ON85256D4E.00465596-85256D4E.0047C920@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7675 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0047C91D85256D4E_= Content-Type: text/plain; charset="US-ASCII" Actually, for maximizing interoperability, I'll modify my suggestion to state: A server SHOULD adhere to the ordering implied by the DTD, but a client SHOULD accept an arbitrary ordering. This is just what I would do when implementing a client and a server, but I don't have a strong opinion about what the spec should say in this regard. Cheers, Geoff Geoff wrote on 06/23/2003 07:58:16 AM: > I'd suggest that we start with a generic statement that DTD implied > ordering is to be ignored, but that the definition of a particular > element can explicitly declare that ordering matters. > > WRT this particular case, I don't think that the amount of memory/time > required on the client to read in the propstat before knowing what > URL it is for is significant enough to matter (but like Julian, > I don't care strongly either way, so I wouldn't object if the consensus > is to make ordering matter in this particular element). > > Cheers, > Geoff > > w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:22:19 AM: > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton > > > Sent: Sunday, June 22, 2003 1:08 PM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: Reconsidering DTDs and validity (was RE: I-D > > > ACTION:draft-ietf-webdav-rfc2518bis-03.txt) > > > > > > > > > > > > I think it's important to retain some of the ordering constraints given > > > by the DTD fragments in 2518 - specifically it is useful that a client > > > > I really don't care much about the issue. However, we really really need to > > decide this, and then stay consistent. The current situation obviously is > > problematic. > > > > *If* we decide that ordering *is* relevant, we should clarify that both > > servers and clients must reject messages that do not comply. I don't want to > > end up in a situation where some clients work with non-compliant servers, > > while others don't. > > > > However, my feeling is that *currently* almost everybody ignores the > > ordering, and that server behaviour is *not* consistent. Thus from a > > standards progress point of view, it would make sense for RFC2518bis just to > > state that the ordering is irrelevant. > > > > > can assume that in the response element, a propstat MUST be preceded by > > > an href. > > > > > > Since a propstat cannot be interpreted without knowing which URI it > > > applies to, if this constraint is missing, the client is required to be > > > able to batch propstats in memory until the href arrives. With this > > > constaint, propstats can always be processed on the fly. > > > > Stream processing of response bodies is a very interesting problem. However, > > I think even if you can rely on ordering, it is still hard. For instance, > > how do you process: > > > > > > > > http://www.foo.bar/file > > > > > > > > Box type A > > > > > > J.J. Johnson > > > > > > HTTP/1.1 200 OK > > > > > > > > HTTP/1.1 403 Forbidden > > The user does not have access to > > the DingALing property. > > > > > > > > This is malformed: & > > > > > > A compliant client must reject this reponse, because the body is malformed. > > > > BTW: you will need to batch the propstat element until you've reached the > > DAV:status element (confirming it's a "200") anyway. I don't see a big > > difference to waiting for the closing response tag. > > > > > > Julian > > > > > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --=_alternative 0047C91D85256D4E_= Content-Type: text/html; charset="US-ASCII"
Actually, for maximizing interoperability, I'll modify my
suggestion to state:

A server SHOULD adhere to the ordering implied by the DTD, but
a client SHOULD accept an arbitrary ordering.

This is just what I would do when implementing a client and a server,
but I don't have a strong opinion about what the spec should say in
this regard.

Cheers,
Geoff

Geoff wrote on 06/23/2003 07:58:16 AM:

> I'd suggest that we start with a generic statement that DTD implied
> ordering is to be ignored, but that the definition of a particular
> element can explicitly declare that ordering matters.  
>
> WRT this particular case, I don't think that the amount of memory/time
> required on the client to read in the propstat before knowing what
> URL it is for is significant enough to matter (but like Julian,
> I don't care strongly either way, so I wouldn't object if the consensus
> is to make ordering matter in this particular element).
>
> Cheers,
> Geoff
>
> w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:22:19 AM:
>
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton
> > > Sent: Sunday, June 22, 2003 1:08 PM
> > > To: w3c-dist-auth@w3.org
> > > Subject: Re: Reconsidering DTDs and validity (was RE: I-D
> > > ACTION:draft-ietf-webdav-rfc2518bis-03.txt)
> > >
> > >
> > >
> > > I think it's important to retain some of the ordering constraints given
> > > by the DTD fragments in 2518 - specifically it is useful that a client
> >
> > I really don't care much about the issue. However, we really really need to
> > decide this, and then stay consistent. The current situation obviously is
> > problematic.
> >
> > *If* we decide that ordering *is* relevant, we should clarify that both
> > servers and clients must reject messages that do not comply. I don't want to
> > end up in a situation where some clients work with non-compliant servers,
> > while others don't.
> >
> > However, my feeling is that *currently* almost everybody ignores the
> > ordering, and that server behaviour is *not* consistent. Thus from a
> > standards progress point of view, it would make sense for RFC2518bis just to
> > state that the ordering is irrelevant.
> >
> > > can assume that in the response element, a propstat MUST be preceded by
> > > an href.
> > >
> > > Since a propstat cannot be interpreted without knowing which URI it
> > > applies to, if this constraint is missing, the client is required to be
> > > able to batch propstats in memory until the href arrives.  With this
> > > constaint, propstats can always be processed on the fly.
> >
> > Stream processing of response bodies is a very interesting problem. However,
> > I think even if you can rely on ordering, it is still hard. For instance,
> > how do you process:
> >
> >    <D:multistatus xmlns:D="DAV:">
> >      <D:response>
> >           <D:href>http://www.foo.bar/file</D:href>
> >           <D:propstat>
> >                <D:prop xmlns:R="http://www.foo.bar/boxschema/">
> >                     <R:bigbox>
> >                          <R:BoxType>Box type A</R:BoxType>
> >                     </R:bigbox>
> >                     <R:author>
> >                          <R:Name>J.J. Johnson</R:Name>
> >                     </R:author>
> >                </D:prop>
> >                <D:status>HTTP/1.1 200 OK</D:status>
> >           </D:propstat>
> >           <D:propstat>
> >                <D:prop><R:DingALing/><R:Random/></D:prop>
> >                <D:status>HTTP/1.1 403 Forbidden</D:status>
> >                <D:responsedescription> The user does not have access to
> >    the DingALing property.
> >                </D:responsedescription>
> >           </D:propstat>
> >      </D:response>
> >     This is malformed: &
> >    </D:multistatus>
> >
> > A compliant client must reject this reponse, because the body is malformed.
> >
> > BTW: you will need to batch the propstat element until you've reached the
> > DAV:status element (confirming it's a "200") anyway. I don't see a big
> > difference to waiting for the closing response tag.
> >
> >
> > Julian
> >
> >
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > --=_alternative 0047C91D85256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 09:37: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 JAA20022 for ; Mon, 23 Jun 2003 09:37:07 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4JSn022297; Mon, 23 Jun 2003 09:04:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5ND4IiO022279; Mon, 23 Jun 2003 09:04:18 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 09:04:18 -0400 (EDT) Resent-Message-Id: <200306231304.h5ND4IiO022279@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4HSn022243 for ; Mon, 23 Jun 2003 09:04:17 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4EiE006806 for ; Mon, 23 Jun 2003 09:04:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5ND48E2179788; Mon, 23 Jun 2003 09:04:08 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5ND46p7084508; Mon, 23 Jun 2003 09:04:07 -0400 In-Reply-To: To: "Julian Reschke" Cc: "Lisa Dusseault" , "Webdav WG" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 09:03:53 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 09:04:07, Serialize complete at 06/23/2003 09:04:07 Content-Type: multipart/alternative; boundary="=_alternative 0047C51A85256D4E_=" Subject: RE: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/OF93D5F205.716A085A-ON85256D4E.0046FF81-85256D4E.0047C51D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7674 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0047C51A85256D4E_= Content-Type: text/plain; charset="US-ASCII" I agree that server should return null content-type, until the client has explicitly specified what it should be (i.e. it should not default to some spec-specified or server-specified type). Cheers, Geoff Julian wrote on 06/22/2003 09:47:06 AM: > > Lisa, > > > ... > > I hadn't thought that a client ought to know when it may guess > > the content-type. OTOH, there is no content-type to guess, so I'm > > not sure it helps to leave it null. So here's some possible new language: > > > > A locked empty resource: > > "SHOULD default to a null content-type. When the client sends a > > PUT request to overwrite the empty resource with a body the > > client SHOULD provide the correct content-type, and the server > > MUST then set the content-type." > > I think the new wording would be much better. > > > Does this violate HTTP -- IOW, does HTTP require a content-type > > for all resources? Is that requirement a theoretical, or > > practical requirement, or neither? > > From [1]: > > "Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body. If > and only if the media type is not given by a Content-Type field, the > recipient MAY attempt to guess the media type via inspection of its > content and/or the name extension(s) of the URI used to identify the > resource. If the media type remains unknown, the recipient SHOULD > treat it as type "application/octet-stream". " > > This sounds to me like a client MUST NOT ever guess the content type > when it's supplied by the server. Thus the server should not try to > guess the type itself, unless it happen to know it. > > > Should we discuss elsewhere whether a resource may exist with a > > null content-type and a non-zero length body? Should we discuss > > what the client or server do in that case? > > I think that is the same discussion. If we can agree on the fact > that an absent content type is better than a "guessed" content type, > this will automatically apply to those empty resources created by > LOCK as well. > > > Another idea occurred to me that we could define a content-type > > specifically for "unknown" or "empty" body though that would have > > more ramifications. > > No no no. If the server doesn't know the content type, don't guess. > The client may know more than the server. However, if the server > starts guessing, a client MUST NOT try to guess on it's own. See [2]: > > "The following are the key architectural points of this finding: > > 1. MIME headers sent by a server are authoritative. [Design choice] > 2. User agent behavior that misrepresents the user or the server is > harmful. [Principle]" > > > What else needs to be said? > > I'm not sure how interoperability is improved by mandating a > specific content type. An empty resource created by LOCK doesn't > have entity body yet, so the question about the content type is > really moot. Nobody knows until such time that the client actually > PUTs something. > > Julian > > [1] > [2] > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > --=_alternative 0047C51A85256D4E_= Content-Type: text/html; charset="US-ASCII"
I agree that server should return null content-type,
until the client has explicitly specified what it should be
(i.e. it should not default to some spec-specified or
server-specified type).

Cheers,
Geoff

Julian wrote on 06/22/2003 09:47:06 AM:

>
> Lisa,
>
> > ...
> > I hadn't thought that a client ought to know when it may guess
> > the content-type. OTOH, there is no content-type to guess, so I'm
> > not sure it helps to leave it null.  So here's some possible new language:
> >
> > A locked empty resource:
> > "SHOULD default to a null content-type.  When the client sends a
> > PUT request to overwrite the empty resource with a body the
> > client SHOULD provide the correct content-type, and the server
> > MUST then set the content-type."
>
> I think the new wording would be much better.
>
> > Does this violate HTTP -- IOW, does HTTP require a content-type
> > for all resources? Is that requirement a theoretical, or
> > practical requirement, or neither?
>
> From [1]:
>
> "Any HTTP/1.1 message containing an entity-body SHOULD include a
> Content-Type header field defining the media type of that body. If
> and only if the media type is not given by a Content-Type field, the
> recipient MAY attempt to guess the media type via inspection of its
> content and/or the name extension(s) of the URI used to identify the
> resource. If the media type remains unknown, the recipient SHOULD
> treat it as type "application/octet-stream". "
>
> This sounds to me like a client MUST NOT ever guess the content type
> when it's supplied by the server. Thus the server should not try to
> guess the type itself, unless it happen to know it.
>
> > Should we discuss elsewhere whether a resource may exist with a
> > null content-type and a non-zero length body?  Should we discuss
> > what the client or server do in that case?
>
> I think that is the same discussion. If we can agree on the fact
> that an absent content type is better than a "guessed" content type,
> this will automatically apply to those empty resources created by
> LOCK as well.
>
> > Another idea occurred to me that we could define a content-type
> > specifically for "unknown" or "empty" body though that would have
> > more ramifications.
>
> No no no. If the server doesn't know the content type, don't guess.
> The client may know more than the server. However, if the server
> starts guessing, a client MUST NOT try to guess on it's own. See [2]:
>
> "The following are the key architectural points of this finding:
>
> 1. MIME headers sent by a server are authoritative. [Design choice]
> 2. User agent behavior that misrepresents the user or the server is
> harmful. [Principle]"
>
> > What else needs to be said?
>
> I'm not sure how interoperability is improved by mandating a
> specific content type. An empty resource created by LOCK doesn't
> have entity body yet, so the question about the content type is
> really moot. Nobody knows until such time that the client actually
> PUTs something.
>
> Julian
>
> [1] <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1>
> [2] <http://www.w3.org/2001/tag/doc/mime-respect.html>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
>
--=_alternative 0047C51A85256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 09:37: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 JAA20024 for ; Mon, 23 Jun 2003 09:37:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND4ESn022210; Mon, 23 Jun 2003 09:04:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5ND4B78022186; Mon, 23 Jun 2003 09:04:11 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 09:04:11 -0400 (EDT) Resent-Message-Id: <200306231304.h5ND4B78022186@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5ND48Sn022151 for ; Mon, 23 Jun 2003 09:04:08 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5ND44iC006775 for ; Mon, 23 Jun 2003 09:04:04 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5ND3wtd188554 for ; Mon, 23 Jun 2003 09:03:58 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5ND3rp8041680 for ; Mon, 23 Jun 2003 09:03:57 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 23 Jun 2003 09:03:39 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 09:03:56, Serialize complete at 06/23/2003 09:03:57, Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/23/2003 09:03:57 Content-Type: multipart/alternative; boundary="=_alternative 0047BF6285256D4E_=" Subject: RE: Status of PROPFIND allprop/include X-Archived-At: http://www.w3.org/mid/OF502F91C5.FBC2ACC1-ON85256D4E.00478E5A-85256D4E.0047BF65@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7673 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0047BF6285256D4E_= Content-Type: text/plain; charset="US-ASCII" I assume that dead-props should be followed by a "?", not a "+", i.e.: Otherwise, this is fine with me. Cheers, Geoff Julian wrote on 06/22/2003 05:50:42 AM: > > Lisa, > > > I started putting the allprop/include proposal into RFC2518bis. THen I > > Great! > > > realized that in some of our discussions, we've leaned towards deprecating > > 'allprop' entirely in favour of 'propname' to help server performance (and > > client performance, at least in so far as client must still download the > > entire Multistatus response and parse it even when it contains useless > > info). > > Yes, we did. We also discussed this in January during the Interim meeting, > and therefore changed the syntax. Don't you remember? (I think by accident > you've been looking at the original proposal rather the updated one). > > > How often do clients really want all the *values* of all dead > > properties? I > > understand readily how clients want to see a list of the names of all dead > > properties. But if I've added a dead property to my home > > directory which is > > called "sharefromstestuser_x0040_1_x003a_1501" in the namespace > > "http://www.xythos.com/namespaces/StorageServer" (this is how Sharemation > > remembers what your bookmarks are) what client cares what the > > value of that > > dead property is? > > The client sometimes can be a library or a proxy/gateway that simply has no > knowledge about what *it's* client will be interested in. Consider an API > that offers access to dead properties of a remote resource. It will perform > much better if it's able to simply get *all* properties in one request. > > > Next question, what's the harm? Well, it takes time to look up all the > > values of dead properties, escape them or encapsulate them, > > marshal them in > > XML and send them down the wire. > > > > So the risk of making 'allprop' more useful through an 'include' syntax is > > that it makes 'allprop' more likely to be used even though much of the > > information returned may be useless. > > Yes, that's why ww decided to extend "prop" instead. > > > I think it might be even more useful and efficient to combine the > > 'propname' > > syntax with the specific list of all the properties the client > > really wants > > the values for. E.g. > > > > PROPFIND blah > > Host: foo.bar > > Content-Type: text/xml > > > > > > > > > > > > > > > > > > > > > > > > > > Now the client gets the property values that will truely be useful, plus > > find out the list of properties that exist that might or might not be > > useful. > > 1) This breaks RFC2518 servers (prop and propname are not allowed at the > same time) and > > 2) the client still will need to requests where before one was enough. > > > So again, here's what we dicussed in January and agreed upon: > > > --- > > during the WG meeting, we briefly discussed our allprop/include proposal > (see [1] for latest draft). Among the attendees (:-)), there was consensus > that a feature like this is useful and should be incorporated into > RFC2518bis. > > A slight change was applied to the syntax -- instead of using DAV:allprop > with a specific include extension, the logic was reversed, such as: > > > > ... named properties... > > > > > The updated DTD for propfind thus would be: > > > > > (one advantage being that we're not extending DAV:allprop which is already > increasingly misnamed). > > --- > > (see > ). > > BTW: in the meantime I updated my original proposal with an appendix > describing January's agreement: > > t.html#rfc.section.A> > > Regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0047BF6285256D4E_= Content-Type: text/html; charset="US-ASCII"
I assume that dead-props should be followed by a "?", not a "+", i.e.:

 <!ELEMENT propfind (allprop | propname | (prop, dead-props?)) >
<!ELEMENT dead-props EMPTY >

Otherwise, this is fine with me.

Cheers,
Geoff
Julian wrote on 06/22/2003 05:50:42 AM:

>
> Lisa,
>
> > I started putting the allprop/include proposal into RFC2518bis.  THen I
>
> Great!
>
> > realized that in some of our discussions, we've leaned towards deprecating
> > 'allprop' entirely in favour of 'propname' to help server performance (and
> > client performance, at least in so far as client must still download the
> > entire Multistatus response and parse it even when it contains useless
> > info).
>
> Yes, we did. We also discussed this in January during the Interim meeting,
> and therefore changed the syntax. Don't you remember? (I think by accident
> you've been looking at the original proposal rather the updated one).
>
> > How often do clients really want all the *values* of all dead
> > properties?  I
> > understand readily how clients want to see a list of the names of all dead
> > properties.  But if I've added a dead property to my home
> > directory which is
> > called "sharefromstestuser_x0040_1_x003a_1501" in the namespace
> > "http://www.xythos.com/namespaces/StorageServer"  (this is how Sharemation
> > remembers what your bookmarks are) what client cares what the
> > value of that
> > dead property is?
>
> The client sometimes can be a library or a proxy/gateway that simply has no
> knowledge about what *it's* client will be interested in. Consider an API
> that offers access to dead properties of a remote resource. It will perform
> much better if it's able to simply get *all* properties in one request.
>
> > Next question, what's the harm?  Well, it takes time to look up all the
> > values of dead properties, escape them or encapsulate them,
> > marshal them in
> > XML and send them down the wire.
> >
> > So the risk of making 'allprop' more useful through an 'include' syntax is
> > that it makes 'allprop' more likely to be used even though much of the
> > information returned may be useless.
>
> Yes, that's why ww decided to extend "prop" instead.
>
> > I think it might be even more useful and efficient to combine the
> > 'propname'
> > syntax with the specific list of all the properties the client
> > really wants
> > the values for.  E.g.
> >
> > PROPFIND blah
> > Host: foo.bar
> > Content-Type: text/xml
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propfind xmlns:D="DAV:">
> >    <D:propname/>
> >    <D:prop xmlns:R="http://www.example.com/boxschema/">
> >       <R:bigbox/>
> >       <R:author/>
> >       <R:DingALing/>
> >       <R:Random/>
> >    </D:prop>
> > </D:propfind>
> >
> > Now the client gets the property values that will truely be useful, plus
> > find out the list of properties that exist that might or might not be
> > useful.
>
> 1) This breaks RFC2518 servers (prop and propname are not allowed at the
> same time) and
>
> 2) the client still will need to requests where before one was enough.
>
>
> So again, here's what we dicussed in January and agreed upon:
>
>
> ---
>
> during the WG meeting, we briefly discussed our allprop/include proposal
> (see [1] for latest draft). Among the attendees (:-)), there was consensus
> that a feature like this is useful and should be incorporated into
> RFC2518bis.
>
> A slight change was applied to the syntax -- instead of using DAV:allprop
> with a specific include extension, the logic was reversed, such as:
>
> <propfind xmlns="DAV:">
>   <prop>
>      ... named properties...
>   </prop>
>   <dead-props />
> </propfind>
>
> The updated DTD for propfind thus would be:
>
> <!ELEMENT propfind (allprop | propname | (prop, dead-props+)) >
> <!ELEMENT dead-props EMPTY >
>
> (one advantage being that we're not extending DAV:allprop which is already
> increasingly misnamed).
>
> ---
>
> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0073.html>).
>
> BTW: in the meantime I updated my original proposal with an appendix
> describing January's agreement:
>
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-lates
> t.html#rfc.section.A>
>
> Regards, Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0047BF6285256D4E_=-- From w3c-dist-auth-request@w3.org Mon Jun 23 13:55: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 NAA01176 for ; Mon, 23 Jun 2003 13:55:41 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NHtPSn021312; Mon, 23 Jun 2003 13:55:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NHtAlM021253; Mon, 23 Jun 2003 13:55:10 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 13:55:10 -0400 (EDT) Resent-Message-Id: <200306231755.h5NHtAlM021253@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NHt8Sn021208 for ; Mon, 23 Jun 2003 13:55:08 -0400 (EDT) Received: from swordfish ([216.241.35.41]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NHt7iC019325 for ; Mon, 23 Jun 2003 13:55:08 -0400 Received: from matt by swordfish with local (Exim 3.35 #1 (Debian)) id 19UVWq-0001Z7-00 for ; Mon, 23 Jun 2003 11:54:56 -0600 Date: Mon, 23 Jun 2003 11:54:56 -0600 From: Matt Gushee To: w3c-dist-auth@w3.org Message-ID: <20030623175456.GA5267@swordfish> Reply-To: Matt Gushee References: <20030621030440.GB12229@swordfish> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Subject: Re: Prevalence of Digest Auth? X-Archived-At: http://www.w3.org/mid/20030623175456.GA5267@swordfish Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7676 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Jun 23, 2003 at 09:50:42AM -0700, Jim Luther wrote: > .... First of all, thank you very much for the response. Actually, I was just about to send a message expressing frustration at having questions going unanswered on this list (this would have been the third time) and wondering if I should be taking my questions to some other forum? Should I, by the way? I'm not trying to pick a fight with anyone, just to get the information I need to do my work. > Mac OS X's WebDAV file system client supports Digest Access > authentication. > .... This is definitely helpful to know. I'm still trying to get a handle on the big picture. Let me narrow down my question a little bit: :: Does anyone know of any important WebDAV clients that use *only* :: Digest authentication? As I mentioned before, we would like to comply fully with the spec, but as a practical matter, those features that are both required by the spec and essential for interoperability will have the highest priority. Thank you all for your assistance. -- Matt Gushee When a nation follows the Way, Englewood, Colorado, USA Horses bear manure through mgushee@havenrock.com its fields; http://www.havenrock.com/ When a nation ignores the Way, Horses bear soldiers through its streets. --Lao Tzu (Peter Merel, trans.) From w3c-dist-auth-request@w3.org Mon Jun 23 14:19: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 OAA02302 for ; Mon, 23 Jun 2003 14:19:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NIJYSn028579; Mon, 23 Jun 2003 14:19:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NIJS7C028333; Mon, 23 Jun 2003 14:19:29 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:19:29 -0400 (EDT) Resent-Message-Id: <200306231819.h5NIJS7C028333@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NIJKSn027695 for ; Mon, 23 Jun 2003 14:19:20 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NIJIiC025829 for ; Mon, 23 Jun 2003 14:19:19 -0400 Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 23 Jun 2003 19:19:17 +0100 Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id TAA04280 for ; Mon, 23 Jun 2003 19:18:37 +0100 (BST) Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id TAA11077; Mon, 23 Jun 2003 19:18:36 +0100 (BST) Message-ID: <3EF7447C.AD9D8EF8@cs.bris.ac.uk> Date: Mon, 23 Jun 2003 19:18:36 +0100 From: "B. Shadgar" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RFC2518bis issue: Transactions & BATCH method X-Archived-At: http://www.w3.org/mid/3EF7447C.AD9D8EF8@cs.bris.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7677 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, There was already a discussion under : " Interest in standardizing Batch methods?" title. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/thread.html#26 Also another discussion under: " Proposal: WebDAV and transactions" title. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/thread.html#249 And for some reasons such as less priority or lack of consensus, it has been postponed till now. However, I was wondering if you are interested to add this topic in the charter of this meeting in Vienna. I am personally interested to add a BATCH method to handle transactions. There are many scenarios that illustrate the need for this transactional BATCH method, such as : http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0010.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0217.html I also know that many of people in this mailing list who do not agree with Batch method because it causes the transparency problem for intermediaries. However, what about using the pre-defined Batch method for some known functions such as Update a file, which for example can be done by PUT, LOCK, PROPPATCH, UNLOCK, DELETE(s), PUT(s). In this case, since the function is already defined, the content of BATCH method is clear for intermediaries as well. There is another scenario for predefined BATCH methods which handle a transaction. It is about mapping the SQL queries into the WebDAV methods. In this case also we may need more than a WebDAV method to represent a SQL query. However those methods are pre-defined for each type of SQL query such as Create Table, Drop table, Insert, .... and also each bunch of methods must be handled as one transaction. Regards, Bita From w3c-dist-auth-request@w3.org Mon Jun 23 15:59: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 PAA08081 for ; Mon, 23 Jun 2003 15:59:39 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NJxPSn026288; Mon, 23 Jun 2003 15:59:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5NJxMHR026225; Mon, 23 Jun 2003 15:59:22 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 15:59:22 -0400 (EDT) Resent-Message-Id: <200306231959.h5NJxMHR026225@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5NJxKSn026187 for ; Mon, 23 Jun 2003 15:59:20 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5NJxJiC020532 for ; Mon, 23 Jun 2003 15:59:20 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19UXTD-00010Z-00; Mon, 23 Jun 2003 19:59:19 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19UXTC-00010O-00; Mon, 23 Jun 2003 19:59:18 +0000 From: "Lisa Dusseault" To: "'B. Shadgar'" , Date: Mon, 23 Jun 2003 12:59:25 -0700 Message-ID: <010c01c339c1$f2a61d70$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <3EF7447C.AD9D8EF8@cs.bris.ac.uk> Old-X-Envelope-To: shadgar@cs.bris.ac.uk, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5NJxKSn026187 Subject: RE: RFC2518bis issue: Transactions & BATCH method X-Archived-At: http://www.w3.org/mid/010c01c339c1$f2a61d70$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7678 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Is anybody willing to lead a discussion of this at Vienna? Bita unfortunately cannot make it. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of B. Shadgar > Sent: Monday, June 23, 2003 11:19 AM > To: w3c-dist-auth@w3.org > Subject: RFC2518bis issue: Transactions & BATCH method > > > > Hi, > > There was already a discussion under : " Interest in > standardizing Batch methods?" title. > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/thread.html#26 Also another discussion under: " Proposal: WebDAV and transactions" title. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/thread.html#249 And for some reasons such as less priority or lack of consensus, it has been postponed till now. However, I was wondering if you are interested to add this topic in the charter of this meeting in Vienna. I am personally interested to add a BATCH method to handle transactions. There are many scenarios that illustrate the need for this transactional BATCH method, such as : http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0010.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0217.html I also know that many of people in this mailing list who do not agree with Batch method because it causes the transparency problem for intermediaries. However, what about using the pre-defined Batch method for some known functions such as Update a file, which for example can be done by PUT, LOCK, PROPPATCH, UNLOCK, DELETE(s), PUT(s). In this case, since the function is already defined, the content of BATCH method is clear for intermediaries as well. There is another scenario for predefined BATCH methods which handle a transaction. It is about mapping the SQL queries into the WebDAV methods. In this case also we may need more than a WebDAV method to represent a SQL query. However those methods are pre-defined for each type of SQL query such as Create Table, Drop table, Insert, .... and also each bunch of methods must be handled as one transaction. Regards, Bita From w3c-dist-auth-request@w3.org Tue Jun 24 07:07: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 HAA11682 for ; Tue, 24 Jun 2003 07:07:37 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OB7NSn007000; Tue, 24 Jun 2003 07:07:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OB6qc4006866; Tue, 24 Jun 2003 07:06:52 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 07:06:52 -0400 (EDT) Resent-Message-Id: <200306241106.h5OB6qc4006866@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OB6mSn006832 for ; Tue, 24 Jun 2003 07:06:48 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5OB6ciC017438 for ; Tue, 24 Jun 2003 07:06:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11343; Tue, 24 Jun 2003 07:00:58 -0400 (EDT) Message-Id: <200306241100.HAA11343@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, 24 Jun 2003 07:00:58 -0400 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-09.txt X-Archived-At: http://www.w3.org/mid/200306241100.HAA11343@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7679 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : E. Whitehead, J. Reschke Filename : draft-ietf-webdav-ordering-protocol-09.txt Pages : 43 Date : 2003-6-23 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. 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-ordering-protocol-09.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-ordering-protocol-09.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-ordering-protocol-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142611.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jun 24 11:12: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 LAA19750 for ; Tue, 24 Jun 2003 11:12:20 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFBcSn028204; Tue, 24 Jun 2003 11:11:38 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OFBEt2028095; Tue, 24 Jun 2003 11:11:14 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 11:11:14 -0400 (EDT) Resent-Message-Id: <200306241511.h5OFBEt2028095@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFBCSn028059 for ; Tue, 24 Jun 2003 11:11:12 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5OFBBiC019709 for ; Tue, 24 Jun 2003 11:11:11 -0400 Received: (qmail 25297 invoked by uid 65534); 24 Jun 2003 15:11:05 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015) with SMTP; 24 Jun 2003 17:11:05 +0200 From: "Julian Reschke" To: Date: Tue, 24 Jun 2003 17:11: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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Review of draft-ietf-webdav-bind-01.3 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEIHHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7680 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've done another review of the current draft ([1]) and found some minor issues. Maybe we can submit a new draft as last call draft once they are resolved. #1 Section 1, Introduction Maybe the last paragraph should contain references to the new sections about BIND and REBIND (also, the HTML version has an unresolved reference here) #2 Section 1.1, Terminology We may want to add language that explains how the DTD fragments are to be interpreted (similar to [2]). Similarily, we may want to "import" the definitions for pre/postconditions and for error response bodies from RFC3253. #3 Section 1.2 "The authors of this specification anticipate and recommend that future revisions of [RFC2518] will update the definition of the state of a collection to correspond to the definition in this document." -> Is that on the RFC2518 issues list yet. #4 Section 2.1 Artwork: can we remove the "(properties)" line from the collection boxes? It seems to imply that the state of a collection is defined just by properties and bindings (however, a collection may also have content). #5 Section 2.2 Please replace "URI's" by "URIs" (several times) for consistency with RFC2396bis ([3]). #6 Section 2.3 "spechified" #7 Section 2.5, last paragraph "Although [RFC2518] allows a MOVE on a collection to be a non-atomic operation, a MOVE implemented as an UNBIND MUST be atomic." I think this should be "REBIND" rather than "UNBIND". #8 Section 2.6 "sameness of resource" "Two resources might have identical contents and properties, but not be the same resource (e.g. an update to one resource does not affect the other resource)." I think there's also the possibilty of multiple URIs identifying the same resource (as per the above definition), yet the multiple URIs not behaving like the BIND spec requires. For instance, consider an HTTP server that responds to multiple port numbers, yet serves the "same" URL namespaces, such as http://foo/x/y and http://foo:81/x/y where /x/y is a resource that's persisted in the same backend. Both URIs identify the same resource, yet applying DELETE to one of them will affect the other one as well. I think the spec needs to say something about this situation. #9 Section 2.6, paragraph 4 "A COPY, since it creates a new resource at the Destination URI, must assign a new, unique value to its DAV:resource-id property." (only if it's not a copy overwrite=t to an existing destination) #10, Section 3 Shouldn't we adopt the DAV:allprop behaviour from RFC3253? #11, Section 6, Preconditions Isn't DAV:protected-url-modification-allowed also required for UNBIND? #12, Section 13, References draft-rfc-editor-rfc2223bis-06 seems to prefer "Normative References" That's it! Regards, Julian [1] [2] [3] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jun 24 11:14: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 LAA19818 for ; Tue, 24 Jun 2003 11:14:51 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFEoSn029125; Tue, 24 Jun 2003 11:14:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OFEovQ029110; Tue, 24 Jun 2003 11:14:50 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 11:14:50 -0400 (EDT) Resent-Message-Id: <200306241514.h5OFEovQ029110@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFEnSn029076 for ; Tue, 24 Jun 2003 11:14:49 -0400 (EDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5OFEmiC020763 for ; Tue, 24 Jun 2003 11:14:48 -0400 Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h5OFElMm022273 for ; Tue, 24 Jun 2003 08:14:47 -0700 (PDT) Message-ID: <3EF86AE6.8060300@cse.ucsc.edu> Date: Tue, 24 Jun 2003 08:14:46 -0700 From: Elias Sinderson Reply-To: Webdav WG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Webdav WG References: <004401c3384c$a6a44800$fdcb90c6@lisalap> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/3EF86AE6.8060300@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7681 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Comments inlined below... Lisa Dusseault wrote: >Currently rfc2518bis-03 says: >[...] >"WebDAV servers SHOULD support strong ETags for all resources that may be PUT. 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. >[...] >Some history on how we got here: RFC2518 doesn't require ETags, nor does HTTP. But the overwrite problem isn't truly soluble without support for ETags (or some other untested new mechanism). Thus, at the early-2003 interim meeting, the attendees agreed to strengthen requirements for ETags. > >Draft 2518bis-02 required: > >"WebDAV servers MUST support ETags correctly and MUST return the ETag header >in all GET and PUT responses. " > >However this was argued on the list to be too strong, and was weakened to the language already shown in -03. > >So, what now? Does the current language (03) make mod_dav or IIS (or other implementations) uncompliant with 03? > In this respect the -03 language doesn't make them uncompliant, just weakly compliant, IMO. >Is that a problem? Would it be a bad idea to upgrade mod_dav or IIS to become compliant with RFC2518bis if it goes to RFC with these requirements? > I don't see this as a problem and think it would be a good idea all around for mod_dav and IIS to upgrade and support ETags. >I'd point out that there are other changes that already make servers slightly uncompliant with RFC2518bis [...] But being uncompliant with a spec that the server doesn't declare compliance to shouldn't be a problem! > Agreed. >IF the language must be weakened, is there any point to this at all? I'm afraid we've got to make a hard choice. Either we do something real to encourage ETag support, even though it makes existing servers "uncompliant". Or we do nothing, and we leave the problem unmitigated. > I wish there was something stronger than SHOULD and weaker than MUST, something along the lines of 'REALLY, REALLY SHOULD'... :-) Personally, I'm in favor of MUST, even with the difficulties it would create - growing pains are temporary and, as has been pointed out on several occasions, the benefits to both client authors and end users are clear. Side note: Correct me if I'm wrong, but generating strong ETags just doesn't seem all that difficult to me... Cheers, Elias From w3c-dist-auth-request@w3.org Tue Jun 24 11: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 LAA20456 for ; Tue, 24 Jun 2003 11:29:15 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFTGSn003926; Tue, 24 Jun 2003 11:29:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OFT1ZH003690; Tue, 24 Jun 2003 11:29:01 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 11:29:01 -0400 (EDT) Resent-Message-Id: <200306241529.h5OFT1ZH003690@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFT0Sn003642 for ; Tue, 24 Jun 2003 11:29:00 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.9/8.12.9) with SMTP id h5OFSmiC025138 for ; Tue, 24 Jun 2003 11:28:54 -0400 Received: (qmail 11563 invoked by uid 65534); 24 Jun 2003 15:28:32 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp022) with SMTP; 24 Jun 2003 17:28:32 +0200 From: "Julian Reschke" To: "Webdav WG" Date: Tue, 24 Jun 2003 17:28:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: <3EF86AE6.8060300@cse.ucsc.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5OFT0Sn003642 Subject: RE: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEIJHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7682 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson > Sent: Tuesday, June 24, 2003 5:15 PM > To: Webdav WG > Subject: Re: Stronger requirements for ETags > > ... > > > In this respect the -03 language doesn't make them uncompliant, just > weakly compliant, IMO. What is "weak" compliance? > ... > > Side note: Correct me if I'm wrong, but generating strong ETags just > doesn't seem all that difficult to me... Well, if this is the case, why do both mod_dav and IIS fail to do that? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jun 24 11:49: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 LAA21036 for ; Tue, 24 Jun 2003 11:49:22 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFnNSn010511; Tue, 24 Jun 2003 11:49:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OFmNBH010204; Tue, 24 Jun 2003 11:48:23 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 11:48:23 -0400 (EDT) Resent-Message-Id: <200306241548.h5OFmNBH010204@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OFmLSn010171 for ; Tue, 24 Jun 2003 11:48:21 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5OFmKiC032224 for ; Tue, 24 Jun 2003 11:48:20 -0400 Received: from Tycho (dhcp-63-188.cse.ucsc.edu [128.114.63.188]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h5OFlgb19167 for ; Tue, 24 Jun 2003 08:47:42 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 24 Jun 2003 08:49:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: WebDAV Ordering Protocol going for IESG approval X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEOPHPAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7683 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The WebDAV Ordering Protocol, specified in draft-ietf-webdav-ordering-protocol-09, is now being sent to the IESG for approval as a Proposed Standard. Julian Reschke deserves big (PROPFIND Depth infinity sized :-) thanks for picking up this specification and pushing it through to completion. Judy Slein also continues to receive my personal thanks for all of her initial hard work on this specification as well. The WebDAV Ordering Protocol has completed multiple Working Group last call for comments periods, as well as an IETF-wide last call. Our area director, Ted Hardie, has reviewed the specification and given his comments as well. All of these comments have been addressed and resolved. At this point, the specification goes in front of the IESG for review, and hopefully approval. It's possible that they may have additional comments on the specification. They may also approve it as-is. If there are comments, they will be resolved in the working group, and then the document will be re-submitted to the IESG. Typically specifications do not require multiple rounds of review with the IESG. So, bottom line, the WebDAV Ordering Protocol is very near approval as a Proposed Standard. The specification can be retrieved at: http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-09. html http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-09. xml http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-09.t xt - Jim Whitehead IETF WebDAV WG Co-Chair From w3c-dist-auth-request@w3.org Tue Jun 24 12:15: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 MAA22217 for ; Tue, 24 Jun 2003 12:15:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OGFTSn015175; Tue, 24 Jun 2003 12:15:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OGFHrK015094; Tue, 24 Jun 2003 12:15:17 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 12:15:17 -0400 (EDT) Resent-Message-Id: <200306241615.h5OGFHrK015094@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OGFFSn015057 for ; Tue, 24 Jun 2003 12:15:15 -0400 (EDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5OGFEiC006057 for ; Tue, 24 Jun 2003 12:15:15 -0400 Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h5OGFDMm024603 for ; Tue, 24 Jun 2003 09:15:14 -0700 (PDT) Message-ID: <3EF87910.5070506@cse.ucsc.edu> Date: Tue, 24 Jun 2003 09:15:12 -0700 From: Elias Sinderson Reply-To: Webdav WG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Webdav WG References: Content-Type: multipart/alternative; boundary="------------070308050006080700060307" Subject: Re: Stronger requirements for ETags X-Archived-At: http://www.w3.org/mid/3EF87910.5070506@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7684 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------070308050006080700060307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Julian Reschke wrote: >>From: w3c-dist-auth-request@w3.org >>[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson >>Sent: Tuesday, June 24, 2003 5:15 PM >>To: Webdav WG >>Subject: Re: Stronger requirements for ETags >> >>... >> >> >>In this respect the -03 language doesn't make them uncompliant, just >>weakly compliant, IMO. >> >> >What is "weak" compliance? > Obviously not an *official* term! :-) Perhaps another way to put it would be to say that they would be 'barely' compliant? The general idea being that if a server were to satisfy all of the MUST level requirements but not the SHOULD level requirements it could be said to be compliant with the spec, but just barely compliant. >>... >>Side note: Correct me if I'm wrong, but generating strong ETags just >>doesn't seem all that difficult to me... >> >> >Well, if this is the case, why do both mod_dav and IIS fail to do that? > I can't speak for the server implementors, but I imagine the issue is one of performance (as opposed to difficulty). Cheers, Elias --------------070308050006080700060307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Julian Reschke wrote:
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson
Sent: Tuesday, June 24, 2003 5:15 PM
To: Webdav WG
Subject: Re: Stronger requirements for ETags

...
    
In this respect the -03 language doesn't make them uncompliant, just 
weakly compliant, IMO.
    
What is "weak" compliance?
Obviously not an *official* term!  :-)  Perhaps another way to put it would be to say that they would be 'barely' compliant? The general idea being that if a server were to satisfy all of the MUST level requirements but not the SHOULD level requirements it could be said to be compliant with the spec, but just barely compliant.
...
Side note: Correct me if I'm wrong, but generating strong ETags just 
doesn't seem all that difficult to me...
    
Well, if this is the case, why do both mod_dav and IIS fail to do that?
I can't speak for the server implementors, but I imagine the issue is one of performance (as opposed to difficulty).


Cheers,
Elias
--------------070308050006080700060307-- From w3c-dist-auth-request@w3.org Tue Jun 24 14:14: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 OAA29031 for ; Tue, 24 Jun 2003 14:14:17 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OIEHSn008157; Tue, 24 Jun 2003 14:14:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5OIDx4m008105; Tue, 24 Jun 2003 14:13:59 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 14:13:59 -0400 (EDT) Resent-Message-Id: <200306241813.h5OIDx4m008105@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5OIDtSn008071 for ; Tue, 24 Jun 2003 14:13:55 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h5OIDriC003814 for ; Tue, 24 Jun 2003 14:13:55 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA25069 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 24 Jun 2003 11:13:47 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA25053 sender obsfucated@us.ibm.com; Tue, 24 Jun 2003 11:13:45 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5OIDD9X074936; Tue, 24 Jun 2003 14:13:13 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5OIDCfr040254; Tue, 24 Jun 2003 14:13:13 -0400 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Jason Crawford Message-ID: Date: Tue, 24 Jun 2003 14:13:11 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/24/2003 14:13:12, Serialize complete at 06/24/2003 14:13:12 Content-Type: multipart/alternative; boundary="=_alternative 0063B8AF85256D4F_=" Subject: Re: Review of draft-ietf-webdav-bind-01.3, issues list addition X-Archived-At: http://www.w3.org/mid/OF55E98B0E.000427F7-ON85256D4F.00631011@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7685 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063B8AF85256D4F_= Content-Type: text/plain; charset="us-ascii" > #3 Section 1.2 > > "The authors of this specification anticipate and recommend that future > revisions of [RFC2518] will update the definition of the state of a > collection to correspond to the definition in this document." > > -> Is that on the RFC2518 issues list yet. Next time I save it to the server it will be there as issue 125. --=_alternative 0063B8AF85256D4F_= Content-Type: text/html; charset="us-ascii"
> #3 Section 1.2
>
> "The authors of this specification anticipate and recommend that future
> revisions of [RFC2518] will update the definition of the state of a
> collection to correspond to the definition in this document."
>
> -> Is that on the RFC2518 issues list yet.
Next time I save it to the server it will be there as issue 125.

--=_alternative 0063B8AF85256D4F_=-- From w3c-dist-auth-request@w3.org Wed Jun 25 20:40: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 UAA15114 for ; Wed, 25 Jun 2003 20:39:46 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5Q0crSn007476; Wed, 25 Jun 2003 20:38:53 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5Q0cUb5007326; Wed, 25 Jun 2003 20:38:30 -0400 (EDT) Resent-Date: Wed, 25 Jun 2003 20:38:30 -0400 (EDT) Resent-Message-Id: <200306260038.h5Q0cUb5007326@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5Q0cSSn007293 for ; Wed, 25 Jun 2003 20:38:28 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5Q0cRnV010993 for ; Wed, 25 Jun 2003 20:38:27 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19VKmQ-0005Vw-00; Thu, 26 Jun 2003 00:38:26 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19VKmP-0005Vl-00; Thu, 26 Jun 2003 00:38:26 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Jason Crawford'" , "'Webdav WG'" Date: Wed, 25 Jun 2003 17:38:33 -0700 Message-ID: <006701c33b7b$462d5ca0$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Old-X-Envelope-To: ccjason@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5Q0cSSn007293 Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS X-Archived-At: http://www.w3.org/mid/006701c33b7b$462d5ca0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7686 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > This currently says: > > "When the 302 and 303 status codes are returned as the only > status code for a response, HTTP1.1 uses the Location > response 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." > > What's the rationale for allowing servers not to return 3xx > response status in multistatus? And what should they return > *instead*? I think this needs more discussion... > The server *can* return 3xx response status in multi-status, or it can try to avoid that. This paragraph attempts to do two things: - to suggest to the server implementor that 3xx response codes are somewhat problematic in Multi-Status. Since I'm not entirely sure what 3xx response codes in Multi-Status would accomplish or why they would be used, it's hard to say whether it's possible to choose 3xx or some other error code that doesn't take a Location header. We'd have to discuss specific scenarios. - to suggest to the client implementor how a 3xx response code in a Multi-Status can be dealt with in the existing set of functionality. I'm currently happy with this because it ought to improve interoperability without making any new requirements or defining any new syntax -- it explains how it's possible already. But everything is of course up for discussion, which is what we're doing. This was first published back in March, FWIW. I can't find exactly where I got this suggestion, but I think it may have been from you, Julian. This change went into RFC2518bis after our in-person interim meeting at Apple early this year. The notes for that meeting said that you were going to suggest language for this. http://www.sharemation.com/~milele/public/dav/minutes/wg-notes-jan-2003. txt Lisa From w3c-dist-auth-request@w3.org Wed Jun 25 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 UAA15504 for ; Wed, 25 Jun 2003 20:46:31 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5Q0kWSn009433; Wed, 25 Jun 2003 20:46:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5Q0kVtO009423; Wed, 25 Jun 2003 20:46:31 -0400 (EDT) Resent-Date: Wed, 25 Jun 2003 20:46:31 -0400 (EDT) Resent-Message-Id: <200306260046.h5Q0kVtO009423@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5Q0kTSn009390 for ; Wed, 25 Jun 2003 20:46:29 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5Q0kTnV011815 for ; Wed, 25 Jun 2003 20:46:29 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19VKuC-0005cW-00; Thu, 26 Jun 2003 00:46:28 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19VKuC-0005cL-00; Thu, 26 Jun 2003 00:46:28 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Wed, 25 Jun 2003 17:46:35 -0700 Message-ID: <006a01c33b7c$65aa02d0$fdcb90c6@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 In-Reply-To: Importance: Normal Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/006a01c33b7c$65aa02d0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7687 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED. > > Draft -03 says that MKCOL can return 302 and there have been no > > objections so far. > > It doesn't say anything specific about MKCOL and redirects. > Or am I missing something? Well it says "11.2 302 Found Any WebDAV request may be redirected using this status code." > > Speaking of which: section 12.1 talks only about 302 and 303 > in Multistatus. It should talk about all 3xx codes, in particular 301. Let's check 2616 - 201 can use the Location header Although in WebDAV a MOVE or COPY may create new resources, currently the spec says that the server should not return 201 in Multi-Status for these methods. Is that sufficient reason not to mention 201? If you think something should be added here, please tell me what. - 300-303, 305, 307 all use the Location header I'm happy to mention all of these. Lisa From w3c-dist-auth-request@w3.org Thu Jun 26 07:19: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 HAA15515 for ; Thu, 26 Jun 2003 07:19:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QBJYSn028511; Thu, 26 Jun 2003 07:19:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5QBJWM9028478; Thu, 26 Jun 2003 07:19:32 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 07:19:32 -0400 (EDT) Resent-Message-Id: <200306261119.h5QBJWM9028478@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QBJUSn028444 for ; Thu, 26 Jun 2003 07:19:30 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5QBJTnV007985 for ; Thu, 26 Jun 2003 07:19:30 -0400 Received: (qmail 29028 invoked by uid 65534); 26 Jun 2003 11:19:24 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016) with SMTP; 26 Jun 2003 13:19:24 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Jason Crawford'" , "'Webdav WG'" Date: Thu, 26 Jun 2003 13:19:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: <006701c33b7b$462d5ca0$fdcb90c6@lisalap> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5QBJUSn028444 Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIENBHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7689 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, June 26, 2003 2:39 AM > To: 'Julian Reschke'; 'Jason Crawford'; 'Webdav WG' > Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2, > XML_LANG_CLARIFY, COPY_LIVE_PROPS > > > > > > This currently says: > > > > "When the 302 and 303 status codes are returned as the only > > status code for a response, HTTP1.1 uses the Location > > response 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." > > > > What's the rationale for allowing servers not to return 3xx > > response status in multistatus? And what should they return > > *instead*? I think this needs more discussion... > > > > The server *can* return 3xx response status in multi-status, or > it can try to avoid that. This paragraph attempts to do two things: > - to suggest to the server implementor that 3xx response codes > are somewhat problematic in Multi-Status. Since I'm not entirely > sure what 3xx response codes in Multi-Status would accomplish or > why they would be used, it's hard to say whether it's possible to > choose 3xx or some other error code that doesn't take a Location > header. We'd have to discuss specific scenarios. > - to suggest to the client implementor how a 3xx response code > in a Multi-Status can be dealt with in the existing set of functionality. The issue that I see here is that this is a *change* to RFC2518 that will make a subsequent WebDAV redirect ref spec harder than it needs to be. PROPFIND on a collection is specific way to marshall information about it's internal members. Unless explicitly otherwise stated, it should faithfully reproduce what I'd get if I did a HEAD request on the internal member. Thus, return a 2xx status in PROPFIND although a HEAD on the resource will return a 3xx is inconsistent and will make it harder for redirect-aware clients to distinguish between "simple" resources and redirects (when browsing collections via PROPFIND). This paragraph only affects servers that both support redirects *and* make them visible through WebDAV. As far as I know, there's only one implementation doing this (ours), and we certainly would prefer that clients can rely on getting the 3xx status codes (instead of leaving that to the server). > I'm currently happy with this because it ought to improve > interoperability without making any new requirements or defining > any new syntax -- it explains how it's possible already. But > everything is of course up for discussion, which is what we're > doing. This was first published back in March, FWIW. > > I can't find exactly where I got this suggestion, but I think it > may have been from you, Julian. This change went into RFC2518bis > after our in-person interim meeting at Apple early this year. > The notes for that meeting said that you were going to suggest > language for this. > > http://www.sharemation.com/~milele/public/dav/minutes/wg-notes-jan-2003. > txt I honestly don't remember. However it's true thatg I volunteered to propose marshalling for the Location information, and I'll try to do that ASAP. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jun 26 07:47: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 HAA15970 for ; Thu, 26 Jun 2003 07:47:14 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QAuJSn021432; Thu, 26 Jun 2003 06:56:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5QAt4Yc021012; Thu, 26 Jun 2003 06:55:04 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 06:55:04 -0400 (EDT) Resent-Message-Id: <200306261055.h5QAt4Yc021012@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QAt2Sn020975 for ; Thu, 26 Jun 2003 06:55:02 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5QAt1nV006091 for ; Thu, 26 Jun 2003 06:55:01 -0400 Received: (qmail 25726 invoked by uid 65534); 26 Jun 2003 10:54:54 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp027) with SMTP; 26 Jun 2003 12:54:54 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG'" Date: Thu, 26 Jun 2003 12:54:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: <006a01c33b7c$65aa02d0$fdcb90c6@lisalap> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5QAt2Sn020975 Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEENAHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7688 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, June 26, 2003 2:47 AM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS, > PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS > > > > > > > > > MKCOL_AND_302: This issue can be marked "inBis" if not CLOSED. > > > Draft -03 says that MKCOL can return 302 and there have been no > > > objections so far. > > > > It doesn't say anything specific about MKCOL and redirects. > > Or am I missing something? > > Well it says > "11.2 302 Found > Any WebDAV request may be redirected using this status code." Yes, but the issue was: "The specification is ambiguous on the handling of 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302." ...so I was looking for something specific to 302. However I'm happy to resolve this by saying hat 302 considerations apply to *all* methods. This being said: I'm not sure that I understand the original issue. An MKCOL request can possibly return a 3xx if and only if the request URI identifies an existing redirect ref resource -- in which case RFC2518 says that it should be a 405: "405 (Method Not Allowed) - MKCOL can only be executed on a deleted/non-existent resource." > > Speaking of which: section 12.1 talks only about 302 and 303 > > in Multistatus. It should talk about all 3xx codes, in particular 301. > > Let's check 2616 > - 201 can use the Location header > Although in WebDAV a MOVE or COPY may create new resources, currently > the spec says that the server should not return 201 in Multi-Status for > these methods. Is that sufficient reason not to mention 201? If you > think something should be added here, please tell me what. > - 300-303, 305, 307 all use the Location header > I'm happy to mention all of these. I think the difference here is that PROPFIND was developed as a container for multiple HEAD results (at least this is my understanding). HEAD will never return 201, so therefore hardwiring all success codes (2xx) to "200" is defensable. So yes, 12.1 should say that multistatus can use all 3xx codes. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jun 26 19:42: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 TAA27481 for ; Thu, 26 Jun 2003 19:42:27 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QNbqSn000397; Thu, 26 Jun 2003 19:37:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5QNbfkg000335; Thu, 26 Jun 2003 19:37:41 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 19:37:41 -0400 (EDT) Resent-Message-Id: <200306262337.h5QNbfkg000335@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5QNbdSn000296 for ; Thu, 26 Jun 2003 19:37:39 -0400 (EDT) Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5QNbcnV026812 for ; Thu, 26 Jun 2003 19:37:39 -0400 Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108]) by catbox.hotcat.org (8.12.6/8.12.6) with ESMTP id h5QNeUWZ016217 for ; Thu, 26 Jun 2003 16:40:30 -0700 Message-ID: <3EFB8400.2030109@nasa.gov> Date: Thu, 26 Jun 2003 16:38:40 -0700 From: Chris Knight User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: BIND spec and PROPFIND Depth: infinity question(s) X-Archived-At: http://www.w3.org/mid/3EFB8400.2030109@nasa.gov Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7690 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like some clarification (that should probably make it into the BIND spec.) If I have a binding from /a/b to g and from /a/b/c to g and I do an infinite PROPFIND, starting at /a/b, should I get results with both "/a/b/g" and "/a/b/c/g" (two URIs for the same resource)? I'm assuming so (and, hence, the resourceid property would enable me to determine that these are the same resource.) If you haven't guessed, I'm actively trying to develop a server capable of handling the BIND spec. (And, perhaps, the changes I make may end up in Catacomb, as reality permits.) From w3c-dist-auth-request@w3.org Fri Jun 27 02:26: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 CAA18887 for ; Fri, 27 Jun 2003 02:26:47 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5R6MbSn003398; Fri, 27 Jun 2003 02:22:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5R6MDYC003289; Fri, 27 Jun 2003 02:22:13 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 02:22:13 -0400 (EDT) Resent-Message-Id: <200306270622.h5R6MDYC003289@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5R6MBSn003256 for ; Fri, 27 Jun 2003 02:22:11 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5R6MAnV032096 for ; Fri, 27 Jun 2003 02:22:10 -0400 Received: (qmail 21101 invoked by uid 65534); 27 Jun 2003 06:22:09 -0000 Received: from p3EE2473F.dip.t-dialin.net (HELO lisa) (62.226.71.63) by mail.gmx.net (mp021) with SMTP; 27 Jun 2003 08:22:09 +0200 From: "Julian Reschke" To: "Chris Knight" , Date: Fri, 27 Jun 2003 08:22: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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3EFB8400.2030109@nasa.gov> Subject: RE: BIND spec and PROPFIND Depth: infinity question(s) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEPDHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7691 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, yes, both should appear. Can you explain why you think that it needs to be stated more explicitly? 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 Chris Knight > Sent: Friday, June 27, 2003 1:39 AM > To: w3c-dist-auth@w3.org > Subject: BIND spec and PROPFIND Depth: infinity question(s) > > > > I would like some clarification (that should probably make it into the > BIND spec.) > > If I have a binding from /a/b to g and from /a/b/c to g and I do an > infinite PROPFIND, starting at /a/b, should I get results with both > "/a/b/g" and "/a/b/c/g" (two URIs for the same resource)? I'm assuming > so (and, hence, the resourceid property would enable me to determine > that these are the same resource.) > > If you haven't guessed, I'm actively trying to develop a server capable > of handling the BIND spec. (And, perhaps, the changes I make may end up > in Catacomb, as reality permits.) > From w3c-dist-auth-request@w3.org Fri Jun 27 04:40: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 EAA20590 for ; Fri, 27 Jun 2003 04:39:49 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5R7rCSn023610; Fri, 27 Jun 2003 03:53:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5R7r9dv023560; Fri, 27 Jun 2003 03:53:09 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 03:53:09 -0400 (EDT) Resent-Message-Id: <200306270753.h5R7r9dv023560@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5R7r6Sn023522 for ; Fri, 27 Jun 2003 03:53:06 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5R7r5nV007114 for ; Fri, 27 Jun 2003 03:53:05 -0400 Received: (qmail 613 invoked by uid 65534); 27 Jun 2003 07:53:04 -0000 Received: from p3EE24717.dip.t-dialin.net (HELO lisa) (62.226.71.23) by mail.gmx.net (mp010) with SMTP; 27 Jun 2003 09:53:04 +0200 From: "Julian Reschke" To: "Jim Whitehead" , "Julian Reschke" , "Lisa Dusseault" , "'Webdav WG'" Date: Fri, 27 Jun 2003 09:53:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5R7r6Sn023522 Subject: RE: Issues: MKCOL_AND_302, IMPLIED_LWS, PUT_AND_INTERMEDIATE_COLLECTIONS, INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPFHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7692 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jim, > It seems to me that it's possible to configure a WebDAV server > such that it doesn't support redirect reference resources, but > does give out 302s for some URLs. I think that's just a matter of what you mean by "support redirect reference resources". If it can return 302s, it knows about redirects. It may not support to *author* them, but that's a separate issue. > I'm fine with saying MKCOL, like all methods, is redirected by 302. So what does this mean? If a client does a MKCOL on a URI and receive a 302 with Location header, what is it supposed to do? a) consider this a failure, just as a 405 (resource exists) b) redirect the MKCOL to the URI specified in the Location header? IMHO, the answer must be a), thus the request is not really redirected -- it just fails, because the resource identified by the request URI already exists, and MKCOL is defined only to suceed on null resources. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jun 27 08:13: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 IAA24715 for ; Fri, 27 Jun 2003 08:13:15 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RCDFSn000161; Fri, 27 Jun 2003 08:13:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RCDAjv029939; Fri, 27 Jun 2003 08:13:10 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 08:13:10 -0400 (EDT) Resent-Message-Id: <200306271213.h5RCDAjv029939@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RCD7Sn029796 for ; Fri, 27 Jun 2003 08:13:07 -0400 (EDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5RCD6nV002940 for ; Fri, 27 Jun 2003 08:13:06 -0400 Received: (qmail 14236 invoked by uid 65534); 27 Jun 2003 12:13:01 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012) with SMTP; 27 Jun 2003 14:13:01 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , "'Webdav WG'" Date: Fri, 27 Jun 2003 14:13:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Issues: MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEPPHKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7694 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Friday, June 27, 2003 1:37 PM > To: 'Webdav WG' > Subject: RE: Issues: MKCOL_AND_302 > > > > Why do you think the answer is "a"? If the URL to which the > 302 is redirecting the client is not mapped to a resource, > a MKCOL to that URL can succeed (privileges permitting), so > I would conclude that "b" is the correct answer (and therefore, > MKCOL acts like any other method wrt 302 handling). But a user agent never would be able to automatically forward the MKCOL to the target, because MKCOL isn't a safe method, right? Julian From w3c-dist-auth-request@w3.org Fri Jun 27 08:39: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 IAA25886 for ; Fri, 27 Jun 2003 08:39:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RBbDSn029005; Fri, 27 Jun 2003 07:37:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RBakbP028843; Fri, 27 Jun 2003 07:36:46 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 07:36:46 -0400 (EDT) Resent-Message-Id: <200306271136.h5RBakbP028843@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RBajSn028810 for ; Fri, 27 Jun 2003 07:36:45 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5RBajnV028539 for ; Fri, 27 Jun 2003 07:36:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5RBadE2163448 for ; Fri, 27 Jun 2003 07:36:39 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5RBacdj055140 for ; Fri, 27 Jun 2003 07:36:38 -0400 In-Reply-To: To: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 27 Jun 2003 07:36:32 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/27/2003 07:36:38, Serialize complete at 06/27/2003 07:36:38 Content-Type: multipart/alternative; boundary="=_alternative 003FC54485256D52_=" Subject: RE: Issues: MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/OF124C90D9.22B76A49-ON85256D52.003F716D-85256D52.003FC54E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7693 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003FC54485256D52_= Content-Type: text/plain; charset="US-ASCII" Why do you think the answer is "a"? If the URL to which the 302 is redirecting the client is not mapped to a resource, a MKCOL to that URL can succeed (privileges permitting), so I would conclude that "b" is the correct answer (and therefore, MKCOL acts like any other method wrt 302 handling). Cheers, Geoff Julian wrote on 06/27/2003 03:53:01 AM: > > Jim, > > > It seems to me that it's possible to configure a WebDAV server > > such that it doesn't support redirect reference resources, but > > does give out 302s for some URLs. > > I think that's just a matter of what you mean by "support redirect > reference resources". If it can return 302s, it knows about > redirects. It may not support to *author* them, but that's a separate issue. > > > I'm fine with saying MKCOL, like all methods, is redirected by 302. > > So what does this mean? If a client does a MKCOL on a URI and > receive a 302 with Location header, what is it supposed to do? > > a) consider this a failure, just as a 405 (resource exists) > b) redirect the MKCOL to the URI specified in the Location header? > > IMHO, the answer must be a), thus the request is not really > redirected -- it just fails, because the resource identified by the > request URI already exists, and MKCOL is defined only to suceed on > null resources. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > --=_alternative 003FC54485256D52_= Content-Type: text/html; charset="US-ASCII"
Why do you think the answer is "a"?  If the URL to which the
302 is redirecting the client is not mapped to a resource,
a MKCOL to that URL can succeed (privileges permitting), so
I would conclude that "b" is the correct answer (and therefore,
MKCOL acts like any other method wrt 302 handling).

Cheers,
Geoff

Julian wrote on 06/27/2003 03:53:01 AM:

>
> Jim,
>
> > It seems to me that it's possible to configure a WebDAV server
> > such that it doesn't support redirect reference resources, but
> > does give out 302s for some URLs.
>
> I think that's just a matter of what you mean by "support redirect
> reference resources". If it can return 302s, it knows about
> redirects. It may not support to *author* them, but that's a separate issue.
>
> > I'm fine with saying MKCOL, like all methods, is redirected by 302.
>
> So what does this mean? If a client does a MKCOL on a URI and
> receive a 302 with Location header, what is it supposed to do?
>
> a) consider this a failure, just as a 405 (resource exists)
> b) redirect the MKCOL to the URI specified in the Location header?
>
> IMHO, the answer must be a), thus the request is not really
> redirected -- it just fails, because the resource identified by the
> request URI already exists, and MKCOL is defined only to suceed on
> null resources.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
--=_alternative 003FC54485256D52_=-- From w3c-dist-auth-request@w3.org Fri Jun 27 09:40: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 JAA27723 for ; Fri, 27 Jun 2003 09:40:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RCs3Sn013651; Fri, 27 Jun 2003 08:54:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RCrx0I013627; Fri, 27 Jun 2003 08:53:59 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 08:53:59 -0400 (EDT) Resent-Message-Id: <200306271253.h5RCrx0I013627@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RCrvSn013594 for ; Fri, 27 Jun 2003 08:53:57 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5RCrvnV006834 for ; Fri, 27 Jun 2003 08:53:57 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5RCrptd153502 for ; Fri, 27 Jun 2003 08:53:51 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5RCrndj102756 for ; Fri, 27 Jun 2003 08:53:50 -0400 In-Reply-To: To: w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 27 Jun 2003 08:53:44 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/27/2003 08:53:49, Serialize complete at 06/27/2003 08:53:49 Content-Type: multipart/alternative; boundary="=_alternative 0046D69A85256D52_=" Subject: RE: Issues: MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/OF61DB40FB.B5941EE7-ON85256D52.00461EF7-85256D52.0046D69D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7695 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0046D69A85256D52_= Content-Type: text/plain; charset="US-ASCII" Yes, a user agent should ask for user confirmation before doing the forwarding, but that is standard 302 handling for a method that is not safe (i.e. MKCOL is no different from PUT, DELETE, etc. in this regard). So MKCOL should acts as is defined by section 10.3.3 of RFC-2616, so I don't see why it needs to have anything special said about it wrt 302 handling. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/27/2003 08:13:00 AM: > > > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Geoffrey M Clemm > > Sent: Friday, June 27, 2003 1:37 PM > > To: 'Webdav WG' > > Subject: RE: Issues: MKCOL_AND_302 > > > > > > > > Why do you think the answer is "a"? If the URL to which the > > 302 is redirecting the client is not mapped to a resource, > > a MKCOL to that URL can succeed (privileges permitting), so > > I would conclude that "b" is the correct answer (and therefore, > > MKCOL acts like any other method wrt 302 handling). > > But a user agent never would be able to automatically forward the MKCOL to > the target, because MKCOL isn't a safe method, right? > > Julian > --=_alternative 0046D69A85256D52_= Content-Type: text/html; charset="US-ASCII"
Yes, a user agent should ask for user confirmation before doing the
forwarding, but that is standard 302 handling for a method
that is not safe (i.e. MKCOL is no different from PUT, DELETE, etc. in
this regard). So MKCOL should acts as is defined by section 10.3.3
of RFC-2616, so I don't see why it needs to have anything special said
about it wrt 302 handling.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/27/2003 08:13:00 AM:

>
> > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> > Behalf Of Geoffrey M Clemm
> > Sent: Friday, June 27, 2003 1:37 PM
> > To: 'Webdav WG'
> > Subject: RE: Issues: MKCOL_AND_302
> >
> >
> >
> > Why do you think the answer is "a"?  If the URL to which the
> > 302 is redirecting the client is not mapped to a resource,
> > a MKCOL to that URL can succeed (privileges permitting), so
> > I would conclude that "b" is the correct answer (and therefore,
> > MKCOL acts like any other method wrt 302 handling).
>
> But a user agent never would be able to automatically forward the MKCOL to
> the target, because MKCOL isn't a safe method, right?
>
> Julian
>
--=_alternative 0046D69A85256D52_=-- From w3c-dist-auth-request@w3.org Fri Jun 27 13:43: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 NAA08376 for ; Fri, 27 Jun 2003 13:43:00 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RG65Sn023931; Fri, 27 Jun 2003 12:06:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RG5aTH023636; Fri, 27 Jun 2003 12:05:36 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 12:05:36 -0400 (EDT) Resent-Message-Id: <200306271605.h5RG5aTH023636@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RG5XSn023558 for ; Fri, 27 Jun 2003 12:05:33 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5RG5XnV025814 for ; Fri, 27 Jun 2003 12:05:33 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5RG5Rxr154016 for ; Fri, 27 Jun 2003 12:05:27 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5RG5QQV061260 for ; Fri, 27 Jun 2003 12:05:26 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 27 Jun 2003 12:05:30 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/27/2003 12:05:26, Serialize complete at 06/27/2003 12:05:26 Content-Type: text/plain; charset="US-ASCII" Subject: Re: Review of draft-ietf-webdav-bind-01.3 X-Archived-At: http://www.w3.org/mid/OFF0309F87.858C4A2B-ON85256D52.00534041-85256D52.0058653C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7696 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Julian wrote on 06/24/2003 11:11:05 AM: > #1 Section 1, Introduction > > Maybe the last paragraph should contain references to the new sections about > BIND and REBIND Done. > (also, the HTML version has an unresolved reference here) Fixed. > #2 Section 1.1, Terminology > > We may want to add language that explains how the DTD fragments are to be > interpreted (similar to [2]). Similarily, we may want to "import" the > definitions for pre/postconditions and for error response bodies from > RFC3253. Done. > #3 Section 1.2 > > "The authors of this specification anticipate and recommend that future > revisions of [RFC2518] will update the definition of the state of a > collection to correspond to the definition in this document." > > -> Is that on the RFC2518 issues list yet. Jason says yes. > #4 Section 2.1 > > Artwork: can we remove the "(properties)" line from the collection boxes? It > seems to imply that the state of a collection is defined just by properties > and bindings (however, a collection may also have content). Done. > #5 Section 2.2 > > Please replace "URI's" by "URIs" (several times) for consistency with > RFC2396bis ([3]). Done. > #6 Section 2.3 > > "spechified" Fixed. > #7 Section 2.5, last paragraph > > "Although [RFC2518] allows a MOVE on a collection to be a non-atomic > operation, a MOVE implemented as an UNBIND MUST be atomic." > > I think this should be "REBIND" rather than "UNBIND". Fixed (thanks for noticing that!) > #8 Section 2.6 "sameness of resource" > > "Two resources might have identical contents and properties, but not be the > same resource (e.g. an update to one resource does not affect the other > resource)." > > I think there's also the possibilty of multiple URIs identifying the same > resource (as per the above definition), yet the multiple URIs not behaving > like the BIND spec requires. For instance, consider an HTTP server that > responds to multiple port numbers, yet serves the "same" URL namespaces, > such as > > http://foo/x/y and http://foo:81/x/y where /x/y is a resource that's > persisted in the same backend. Both URIs identify the same resource, yet > applying DELETE to one of them will affect the other one as well. I think > the spec needs to say something about this situation. In this case, http://foo/x and http://foo:81/x identify the same collection, so of course a DELETE of a binding in http://foo/x will be reflected in all other URIs that are mapped to that collection (e.g. in http://foo:81/x). So this behavior is as predicted by the semantics of bindings. > #9 Section 2.6, paragraph 4 > > "A COPY, since it creates a new resource at the Destination URI, must assign > a new, unique value to its DAV:resource-id property." > > (only if it's not a copy overwrite=t to an existing destination) Good point! Fixed. > #10, Section 3 > > Shouldn't we adopt the DAV:allprop behaviour from RFC3253? Done. > #11, Section 6, Preconditions > > Isn't DAV:protected-url-modification-allowed also required for UNBIND? Currently, this is specified by DAV:locked-overwrite-allowed, but that is not a good tag name. I'll change this to be: DAV:protected-source-url-deletion-allowed. > #12, Section 13, References > > draft-rfc-editor-rfc2223bis-06 seems to prefer "Normative References" Done. > That's it! Thanks for the careful review! I'll send this off as a new internet draft. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jun 27 16:18: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 QAA18940 for ; Fri, 27 Jun 2003 16:18:53 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RKIcSn009947; Fri, 27 Jun 2003 16:18:38 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RKIKPi009870; Fri, 27 Jun 2003 16:18:20 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 16:18:20 -0400 (EDT) Resent-Message-Id: <200306272018.h5RKIKPi009870@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RKIISn009831 for ; Fri, 27 Jun 2003 16:18:18 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5RKIInV018257 for ; Fri, 27 Jun 2003 16:18:18 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19Vzfk-0002Xu-00; Fri, 27 Jun 2003 20:18:16 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19Vzfk-0002Xj-00; Fri, 27 Jun 2003 20:18:16 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , "'Julian Reschke'" Cc: "'Webdav WG'" , Date: Fri, 27 Jun 2003 13:18:26 -0700 Message-ID: <002d01c33ce9$4422e550$fdcb90c6@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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3c.org, w3c-dist-auth-request@w3.org Subject: RE: RFC2518bis issue: content type for locked empty resource X-Archived-At: http://www.w3.org/mid/002d01c33ce9$4422e550$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7697 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, I've fixed this. Draft -04 will specify that servers MUST not choose a Content-Type for a locked empty resource created through a LOCK command. Also, I added this paragraph in section 7.4: "The client is expected to update the locked empty resource shortly after locking it, using PUT and possibly PROPPATCH. When the client uses PUT to overwrite a locked empty resource the client MUST supply a Content-Type if any is known. If the client supplies a Content-Type value the server MUST set that value (this requirement actually applies to any resource that is overwritten but is particularly necessary for locked empty resources which are initially created with no Content-Type. " Lisa -----Original Message----- From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] Sent: Monday, June 23, 2003 6:04 AM To: Julian Reschke Cc: Lisa Dusseault; Webdav WG; w3c-dist-auth-request@w3.org Subject: RE: RFC2518bis issue: content type for locked empty resource I agree that server should return null content-type, until the client has explicitly specified what it should be (i.e. it should not default to some spec-specified or server-specified type). Cheers, Geoff Julian wrote on 06/22/2003 09:47:06 AM: > > Lisa, > > > ... > > I hadn't thought that a client ought to know when it may guess > > the content-type. OTOH, there is no content-type to guess, so I'm > > not sure it helps to leave it null. So here's some possible new language: > > > > A locked empty resource: > > "SHOULD default to a null content-type. When the client sends a > > PUT request to overwrite the empty resource with a body the > > client SHOULD provide the correct content-type, and the server > > MUST then set the content-type." > > I think the new wording would be much better. > > > Does this violate HTTP -- IOW, does HTTP require a content-type > > for all resources? Is that requirement a theoretical, or > > practical requirement, or neither? > > From [1]: > > "Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body. If > and only if the media type is not given by a Content-Type field, the > recipient MAY attempt to guess the media type via inspection of its > content and/or the name extension(s) of the URI used to identify the > resource. If the media type remains unknown, the recipient SHOULD > treat it as type "application/octet-stream". " > > This sounds to me like a client MUST NOT ever guess the content type > when it's supplied by the server. Thus the server should not try to > guess the type itself, unless it happen to know it. > > > Should we discuss elsewhere whether a resource may exist with a > > null content-type and a non-zero length body? Should we discuss > > what the client or server do in that case? > > I think that is the same discussion. If we can agree on the fact > that an absent content type is better than a "guessed" content type, > this will automatically apply to those empty resources created by > LOCK as well. > > > Another idea occurred to me that we could define a content-type > > specifically for "unknown" or "empty" body though that would have > > more ramifications. > > No no no. If the server doesn't know the content type, don't guess. > The client may know more than the server. However, if the server > starts guessing, a client MUST NOT try to guess on it's own. See [2]: > > "The following are the key architectural points of this finding: > > 1. MIME headers sent by a server are authoritative. [Design choice] > 2. User agent behavior that misrepresents the user or the server is > harmful. [Principle]" > > > What else needs to be said? > > I'm not sure how interoperability is improved by mandating a > specific content type. An empty resource created by LOCK doesn't > have entity body yet, so the question about the content type is > really moot. Nobody knows until such time that the client actually > PUTs something. > > Julian > > [1] > [2] > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > From w3c-dist-auth-request@w3.org Fri Jun 27 17:59: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 RAA21660 for ; Fri, 27 Jun 2003 17:59:31 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RLxISn019763; Fri, 27 Jun 2003 17:59:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5RLxESd019741; Fri, 27 Jun 2003 17:59:14 -0400 (EDT) Resent-Date: Fri, 27 Jun 2003 17:59:14 -0400 (EDT) Resent-Message-Id: <200306272159.h5RLxESd019741@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5RLxCSn019703 for ; Fri, 27 Jun 2003 17:59:12 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5RLxBnV031847 for ; Fri, 27 Jun 2003 17:59:12 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19W1FP-0004RT-00; Fri, 27 Jun 2003 21:59:11 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19W1FP-0004RI-00; Fri, 27 Jun 2003 21:59:11 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Greg Stein'" Cc: "'Peter Gillis'" , , , Date: Fri, 27 Jun 2003 14:59:09 -0700 Message-ID: <005001c33cf7$56fcc2a0$fdcb90c6@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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: dav-dev@lyra.org, gstein@lyra.org, I20568n@mindshare.intraspect.com, julian.reschke@gmx.de, Pgillis@intraspect.com, w3c-dist-auth@w3.org Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters X-Archived-At: http://www.w3.org/mid/005001c33cf7$56fcc2a0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7698 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Does somebody have a specific proposal what language should appear in 2518bis for this issue? I haven't dealt with it even though it's so old because I'm having trouble figuring out what to say! lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Wednesday, February 20, 2002 2:38 AM > To: Greg Stein > Cc: Peter Gillis; dav-dev@lyra.org; w3c-dist-auth@w3.org; > I20568n@mindshare.intraspect.com > Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters > > > Greg, > > what you describe is a scenario where > > - the server preserves whatever octet sequence was used in a URL > - the clients are consistent in what they send/expect > > However, thinks are more complicated. > > - In moddav (correct me if I'm wrong), people may be creating > resources by directly accessing the filesystem. If, for > instance, I create a filename containing "A umlaut", and the > filesystem's filename encoding is ISO-8859-1, I'll have the > octet %c4 in the name. Returning %c4 in the PROPFIND response > in the general case will not work (because the client doesn't > know about URL character encodings, so it must use what the > RFCs say, and that is UTF-8). > > - Broken clients may use request/destination URIs which are > not encoded in UTF-8 (this may apply to older versions of > Microsoft clients). So you basically have the choice of > failing the request if the octet stream doesn't UTF-8-decode, > or you can try to workaround the problem by making > assumptions about what the encoding in the request may have been. > > As this issue is coming up every few weeks and as almost > every server / client I've seen in the last few months has > some bug in this regard, it should certainly clarified in the > RFC2518 revision. > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > > Sent: Wednesday, February 20, 2002 3:53 AM > > To: Julian Reschke > > Cc: Peter Gillis; dav-dev@lyra.org; w3c-dist-auth@w3.org; > > I20568n@mindshare.intraspect.com > > Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters > > > > > > On Wed, Feb 13, 2002 at 09:31:37PM +0100, Julian Reschke wrote: > > >... > > > > From: dav-dev-admin@lyra.org > > [mailto:dav-dev-admin@lyra.org]On Behalf Of > > > > Peter Gillis > > > > Sent: Wednesday, February 13, 2002 8:46 PM > > >... > > > > I am having a problem with Microsoft Web Folders after the > > client installs > > > > Office XP on their machine and file names with accented > characters > > > > are involved. Our server has been working in the past with > > > > earlier implementations of Web Folders without a > problem, however, > > when the client > > > > machine is upgraded to Office XP, a document that was > accessible > > > > previously is now not found. I have tracked the > problem down to > > > > the > > fact that Web > > > > Folders is encoding the URI value a second time before > sending the > > > > request, which then causes it not to be found on our > server. For > > > > example: > > > > > > > > In the folder listing we send back the following property: > > > > > > > > /dav/webdav/%E8%E2temp%C9.xls > > > > > > Isn't this wrong in the first place? My understanding is that you > > > should send URL-encoded UTF-8. > > > > Nope. > > > > The filename is in an "original character set". That is > then encoded > > into octets for the URL. That transformation is not specified > > anywhere. Ideally, it is "original -> UTF-8", but nobody > says it must > > be. In fact, I would say > > it should match whatever encoding was used for the Request-URI > > (but that is > > not specified/defined in the request, so you're out of luck again). > > > > Once you have octets, then you perform the URL-escaping > (using '%xx'). > > > > After that, you need to transform the URL into the character set of > > the response body. That is usually UTF-8, but it is > possible to have > > the XML in a different character set (provided it is > specified on the > > Content-Type response header). > > > > Finally, you must XML-escape the UTF-8 characters of the URL you're > > inserting (e.g. translate '&' to '&') so that you can embed the > > UTF-8 content into the XML response. > > > > > > A long time ago, I captured this as a start of a technical FAQ. See: > > http://www.webdav.org/other/techfaq.html > > > > Specifically, the second section. > > > > Cheers, > > -g > > > > -- > > Greg Stein, http://www.lyra.org/ > > > From w3c-dist-auth-request@w3.org Sat Jun 28 05:53: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 FAA19647 for ; Sat, 28 Jun 2003 05:53:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5S9pwSn028051; Sat, 28 Jun 2003 05:51:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5S9pjdc028043; Sat, 28 Jun 2003 05:51:45 -0400 (EDT) Resent-Date: Sat, 28 Jun 2003 05:51:45 -0400 (EDT) Resent-Message-Id: <200306280951.h5S9pjdc028043@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5S9phSn028010 for ; Sat, 28 Jun 2003 05:51:43 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5S9pgnV029293 for ; Sat, 28 Jun 2003 05:51:42 -0400 Received: (qmail 19706 invoked by uid 65534); 28 Jun 2003 09:51:34 -0000 Received: from p3EE2470A.dip.t-dialin.net (HELO lisa) (62.226.71.10) by mail.gmx.net (mp027) with SMTP; 28 Jun 2003 11:51:34 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Greg Stein'" Cc: "'Peter Gillis'" , , , Date: Sat, 28 Jun 2003 11:51:30 +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: <005001c33cf7$56fcc2a0$fdcb90c6@lisalap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOECIHLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7699 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, I think the only way we'll ever achieve interoperability for non-ASCII characters in resource names is to select one specific character encoding that needs to be used to map the characters to octets (which in turn then will get percent-escaped in the URL). Note that recipients of URLs have no way to find out which encoding was used, so we really need consensus here. The big issue is that the current RFCs do not say anything normative about the issue. Therefore, in practice URLs do exists which -- after percent-de-escaping -- can not be decoded as UTF-8, and these URLs are fully legal URLs according to RFC2396. So my proposal is to add a SHOULD level requirement for generating URL path segments from names that do contain non-ASCII characters, such as filenames in a file system: RFC2396bis currently says [1]: "When a URI scheme defines a component that represents textual data consisting of characters from the Unicode (ISO 10646) character set, we recommend that the data be encoded first as octets according to the UTF-8 [UTF-8] character encoding, and then escaping only those octets that are not in the unreserved character set." So we'd be in sync with the latest URI draft, accept we would make it a SHOULD for WebDAV. [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Friday, June 27, 2003 11:59 PM > To: 'Julian Reschke'; 'Greg Stein' > Cc: 'Peter Gillis'; dav-dev@lyra.org; w3c-dist-auth@w3.org; > I20568n@mindshare.intraspect.com > Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters > > > Does somebody have a specific proposal what language should appear in > 2518bis for this issue? I haven't dealt with it even though it's so old > because I'm having trouble figuring out what to say! > > lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > Sent: Wednesday, February 20, 2002 2:38 AM > > To: Greg Stein > > Cc: Peter Gillis; dav-dev@lyra.org; w3c-dist-auth@w3.org; > > I20568n@mindshare.intraspect.com > > Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters > > > > > > Greg, > > > > what you describe is a scenario where > > > > - the server preserves whatever octet sequence was used in a URL > > - the clients are consistent in what they send/expect > > > > However, thinks are more complicated. > > > > - In moddav (correct me if I'm wrong), people may be creating > > resources by directly accessing the filesystem. If, for > > instance, I create a filename containing "A umlaut", and the > > filesystem's filename encoding is ISO-8859-1, I'll have the > > octet %c4 in the name. Returning %c4 in the PROPFIND response > > in the general case will not work (because the client doesn't > > know about URL character encodings, so it must use what the > > RFCs say, and that is UTF-8). > > > > - Broken clients may use request/destination URIs which are > > not encoded in UTF-8 (this may apply to older versions of > > Microsoft clients). So you basically have the choice of > > failing the request if the octet stream doesn't UTF-8-decode, > > or you can try to workaround the problem by making > > assumptions about what the encoding in the request may have been. > > > > As this issue is coming up every few weeks and as almost > > every server / client I've seen in the last few months has > > some bug in this regard, it should certainly clarified in the > > RFC2518 revision. > > > > Julian > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > > > Sent: Wednesday, February 20, 2002 3:53 AM > > > To: Julian Reschke > > > Cc: Peter Gillis; dav-dev@lyra.org; w3c-dist-auth@w3.org; > > > I20568n@mindshare.intraspect.com > > > Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters > > > > > > > > > On Wed, Feb 13, 2002 at 09:31:37PM +0100, Julian Reschke wrote: > > > >... > > > > > From: dav-dev-admin@lyra.org > > > [mailto:dav-dev-admin@lyra.org]On Behalf Of > > > > > Peter Gillis > > > > > Sent: Wednesday, February 13, 2002 8:46 PM > > > >... > > > > > I am having a problem with Microsoft Web Folders after the > > > client installs > > > > > Office XP on their machine and file names with accented > > characters > > > > > are involved. Our server has been working in the past with > > > > > earlier implementations of Web Folders without a > > problem, however, > > > when the client > > > > > machine is upgraded to Office XP, a document that was > > accessible > > > > > previously is now not found. I have tracked the > > problem down to > > > > > the > > > fact that Web > > > > > Folders is encoding the URI value a second time before > > sending the > > > > > request, which then causes it not to be found on our > > server. For > > > > > example: > > > > > > > > > > In the folder listing we send back the following property: > > > > > > > > > > /dav/webdav/%E8%E2temp%C9.xls > > > > > > > > Isn't this wrong in the first place? My understanding is that you > > > > should send URL-encoded UTF-8. > > > > > > Nope. > > > > > > The filename is in an "original character set". That is > > then encoded > > > into octets for the URL. That transformation is not specified > > > anywhere. Ideally, it is "original -> UTF-8", but nobody > > says it must > > > be. In fact, I would say > > > it should match whatever encoding was used for the Request-URI > > > (but that is > > > not specified/defined in the request, so you're out of luck again). > > > > > > Once you have octets, then you perform the URL-escaping > > (using '%xx'). > > > > > > After that, you need to transform the URL into the character set of > > > the response body. That is usually UTF-8, but it is > > possible to have > > > the XML in a different character set (provided it is > > specified on the > > > Content-Type response header). > > > > > > Finally, you must XML-escape the UTF-8 characters of the URL you're > > > inserting (e.g. translate '&' to '&') so that you can embed the > > > UTF-8 content into the XML response. > > > > > > > > > A long time ago, I captured this as a start of a technical FAQ. See: > > > http://www.webdav.org/other/techfaq.html > > > > > > Specifically, the second section. > > > > > > Cheers, > > > -g > > > > > > -- > > > Greg Stein, http://www.lyra.org/ > > > > > > > From w3c-dist-auth-request@w3.org Sun Jun 29 08:32: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 IAA27300 for ; Sun, 29 Jun 2003 08:32:15 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TCViSn006191; Sun, 29 Jun 2003 08:31:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5TCUQYT005999; Sun, 29 Jun 2003 08:30:26 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 08:30:26 -0400 (EDT) Resent-Message-Id: <200306291230.h5TCUQYT005999@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TCUNSn005966 for ; Sun, 29 Jun 2003 08:30:23 -0400 (EDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5TCUMnV014370 for ; Sun, 29 Jun 2003 08:30:23 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h5TCUMh0008644 for ; Sun, 29 Jun 2003 05:30:22 -0700 (PDT) Received: from [192.168.1.101] (h86.241.40.162.ip.alltel.net [162.40.241.86]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h5TCUJFL023220 for ; Sun, 29 Jun 2003 05:30:20 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: Date: Wed, 31 Dec 1969 20:43:54 -0500 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV vs FTP, not an easy choice X-Archived-At: http://www.w3.org/mid/p052106047c25c6fa4d75@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7700 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg Stein's DAV Frequently Asked Questions (FAQ) contains this interesting (to me) comparison of WebDAV and FTP: >Q. Why should I use DAV instead of FTP? > >A. Since DAV works over HTTP, you get all the benefits of HTTP >that FTP cannot provide. For example: strong >authentication, encryption, proxy support, and caching. It is true >that you can get some of this through SSH, but the HTTP >infrastructure is much more widely deployed than SSH. Further, SSH >does not have the wide complement of tools, development libraries, >and applications that HTTP does. > >DAV transfers (well, HTTP transfers) are also more efficient than >FTP. You can pipeline multiple transfers through a single TCP >connection, whereas FTP requires a new connection for each file >transferred (plus the control connection). Recent events prompting heightened concerns about security and the ever widening distribution of FireWall products certainly support the assertions about plain vanilla FTP being problematic. As well, FTP's SSH-enhanced varieties (SFTP, SCP, etc.) are generally beyond the reach of typical clients although GUI apps currently available are beginning to tear down that barrier (see: http://www.gideonsoftworks.com/sshhelper.html and http://afp548.com/Software/Vapor/index.html). However, the answer does not address those valuable things that FTP can do that WebDAV currently cannot do or cannot do well. Specifically, I refer to the following: 1) WebDAV cannot be programmatically and securely applied to individual web sites. Currently, creating an account on my MacOS X Server (Apache) programmatically creates web space whose address takes the form http://myserver.gcsu.edu/~username and programmatically enables FTP access to that web space using the un/pw assigned to the account. This can be done on a large scale with batch methods. 2) WebDAV does not offer disk space quota enforcement and the means with which to discover one's usage of that disk space and take corrective action. 3) WebDAV does not offer password management (neither does FTP but I mention it here to complete a basic feature list). Of course, I would like to be wrong about this and I believe that I am. Apple seems to have accomplished a good measure of what I describe above with "dotMac" accounts that include WebDAV access via what it calls an "iDisk." However, the techniques behind this are not generally and perhaps not even publicly, available. I would like to extend this kind of functionality to the thousands of students and hundreds of faculty at my university but apparently cannot due to the unavailability of critical information n the techniques employed. Being able to drop support for FTP would certainly make our networking a security folks happy. Being able to supplant FTP with WebDAV would likely be viewed as progress by our clients. Unfortunately, it does not appear to be possible right now. Here, again, I hope to be shown the error of my thinking. -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Sun Jun 29 08:47: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 IAA27409 for ; Sun, 29 Jun 2003 08:47:41 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TClfSn009691; Sun, 29 Jun 2003 08:47:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5TClQBD009610; Sun, 29 Jun 2003 08:47:26 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 08:47:26 -0400 (EDT) Resent-Message-Id: <200306291247.h5TClQBD009610@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TClOSn009576 for ; Sun, 29 Jun 2003 08:47:24 -0400 (EDT) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5TClNnV002069 for ; Sun, 29 Jun 2003 08:47:23 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h5TClNCR010843 for ; Sun, 29 Jun 2003 05:47:23 -0700 (PDT) Received: from [192.168.1.101] (h86.241.40.162.ip.alltel.net [162.40.241.86]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 2.0) with ESMTP id h5TClJNm006739 for ; Sun, 29 Jun 2003 05:47:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: Date: Sun, 29 Jun 2003 08:47:17 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV vs FTP, not an easy choice X-Archived-At: http://www.w3.org/mid/p05210606bb24904dac7b@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7701 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg Stein's DAV Frequently Asked Questions (FAQ) contains this interesting (to me) comparison of WebDAV and FTP: >Q. Why should I use DAV instead of FTP? > >A. Since DAV works over HTTP, you get all the benefits of HTTP >that FTP cannot provide. For example: strong >authentication, encryption, proxy support, and caching. It is true >that you can get some of this through SSH, but the HTTP >infrastructure is much more widely deployed than SSH. Further, SSH >does not have the wide complement of tools, development libraries, >and applications that HTTP does. > >DAV transfers (well, HTTP transfers) are also more efficient than >FTP. You can pipeline multiple transfers through a single TCP >connection, whereas FTP requires a new connection for each file >transferred (plus the control connection). Recent events prompting heightened concerns about security and the ever widening distribution of FireWall products certainly support the assertions about plain vanilla FTP being problematic. As well, FTP's SSH-enhanced varieties (SFTP, SCP, etc.) are generally beyond the reach of typical clients although GUI apps currently available are beginning to tear down that barrier (see: http://www.gideonsoftworks.com/sshhelper.html and http://afp548.com/Software/Vapor/index.html). However, the answer does not address those valuable things that FTP can do that WebDAV currently cannot do or cannot do well. Specifically, I refer to the following: 1) WebDAV cannot be programmatically and securely applied to individual web sites. Currently, creating an account on my MacOS X Server (Apache) programmatically creates web space whose address takes the form http://myserver.gcsu.edu/~username and programmatically enables FTP access to that web space using the un/pw assigned to the account. This can be done on a large scale with batch methods. 2) WebDAV does not offer disk space quota enforcement and the means with which to discover one's usage of that disk space and take corrective action. 3) WebDAV does not offer password management (neither does FTP but I mention it here to complete a basic feature list). Of course, I would like to be wrong about this and I believe that I am. Apple seems to have accomplished a good measure of what I describe above with "dotMac" accounts that include WebDAV access via what it calls an "iDisk." However, the techniques behind this are not generally and perhaps not even publicly, available. I would like to extend this kind of functionality to the thousands of students and hundreds of faculty at my university but apparently cannot due to the unavailability of critical information n the techniques employed. Being able to drop support for FTP would certainly make our networking a security folks happy. Being able to supplant FTP with WebDAV would likely be viewed as progress by our clients. Unfortunately, it does not appear to be possible right now. Here, again, I hope to be shown the error of my thinking. -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Sun Jun 29 11: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 LAA00507 for ; Sun, 29 Jun 2003 11:17:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TFHLSn004459; Sun, 29 Jun 2003 11:17:21 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5TFHHgu004441; Sun, 29 Jun 2003 11:17:17 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 11:17:17 -0400 (EDT) Resent-Message-Id: <200306291517.h5TFHHgu004441@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TFHGSn004404 for ; Sun, 29 Jun 2003 11:17:16 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5TFHFnV024257 for ; Sun, 29 Jun 2003 11:17:15 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19WdvX-0003Dd-00; Sun, 29 Jun 2003 15:17:15 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19WdvW-0003DS-00; Sun, 29 Jun 2003 15:17:14 +0000 From: "Lisa Dusseault" To: "'Frank Lowney'" , Date: Sun, 29 Jun 2003 08:17:12 -0700 Message-ID: <00b801c33e51$862c9e50$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: frank.lowney@mac.com, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5TFHGSn004404 Subject: RE: WebDAV vs FTP, not an easy choice X-Archived-At: http://www.w3.org/mid/00b801c33e51$862c9e50$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7702 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Frank, I'll try to answer your questions about WebDAV vs. FTP: > 1) WebDAV cannot be programmatically and securely applied to > individual web sites. Currently, creating an account on my MacOS X > Server (Apache) programmatically creates web space whose address > takes the form http://myserver.gcsu.edu/~username and > programmatically enables FTP access to that web space using the un/pw > assigned to the account. This can be done on a large scale with > batch methods. I'm not sure what you're asking here. Are you asking from an implementor/administrator point of view, whether a server can be implemented that supports WebDAV and securely supports individual Web sites? If that's the question, then Sharemation is an existence proof that this can be easily done. The site www.sharemation.com hosts individual web sites for many thousands of accounts. Although there's a Web interface to allow users to sign up, after registration users can manage their sites with WebDAV. Many universities are now starting to provide WebDAV-enabled individual sites to students with this technology, but instead of allowing free signup as Sharemation does, these universities use batch methods to create thousands of accounts each semester as new students arrive. There is no FTP access to these accounts because it's no longer needed. Or are you asking whether WebDAV can be used by a client program to manage a Web site remotely and automatically? Sitecopy and GoLive are client programs that do this. > 2) WebDAV does not offer disk space quota enforcement and the means > with which to discover one's usage of that disk space and take > corrective action. A WebDAV server implementation can offer disk space quota enforcement, as Apple iDisk and Xythos WFS do. This must be managed by the administrator of course. It's true that it's difficult to discover one's usage of that disk space however there is a HTTP error commonly used when that quota is reached ("Insufficient Storage"). Furthermore, we're working on an extension to WebDAV to provide quota-related properties so that an individual user may discover their quota and storage usage. Are you sure that FTP offers this functionality anyway? I didn't think that was part of the FTP standard. I would think the user would have to type in Unix queries and understand the answer themselves, rather than be able to use a GUI client that is capable of parsing the quota information and issue warnings. > 3) WebDAV does not offer password management (neither does FTP but I > mention it here to complete a basic feature list). Typically password management is not part of an application protocol -- as you point out, it's not part of FTP (nor is it part of IMAP, etc) Instead, typically password management is an administrative function, which means that it can either be done through an administration UI (not through the application protocol) or through LDAP. WebDAV can work with LDAP: e.g. an administrator can create LDAP accounts and set passwords, then when users try to log into the WebDAV server the WebDAV server queries the LDAP server to see if the login should be allowed. A number of universities are also doing this already. I can provide you with more details if you're interested. Good questions! Lisa Dusseault From w3c-dist-auth-request@w3.org Sun Jun 29 12:24: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 MAA01436 for ; Sun, 29 Jun 2003 12:24:42 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TGNwSn018465; Sun, 29 Jun 2003 12:23:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5TGNdrW018440; Sun, 29 Jun 2003 12:23:39 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 12:23:39 -0400 (EDT) Resent-Message-Id: <200306291623.h5TGNdrW018440@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TGNbSn018387 for ; Sun, 29 Jun 2003 12:23:37 -0400 (EDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5TGNanV009200 for ; Sun, 29 Jun 2003 12:23:37 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h5TGNXad007356 for ; Sun, 29 Jun 2003 09:23:33 -0700 (PDT) Received: from [192.168.1.101] (h49.242.40.162.ip.alltel.net [162.40.242.49]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h5TGNSFL000789 for ; Sun, 29 Jun 2003 09:23:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: In-Reply-To: <00b801c33e51$862c9e50$fdcb90c6@lisalap> References: <00b801c33e51$862c9e50$fdcb90c6@lisalap> Date: Sun, 29 Jun 2003 12:23:27 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: WebDAV vs FTP, not an easy choice X-Archived-At: http://www.w3.org/mid/p0521060abb24ba377f52@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7703 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Lisa Dusseault comments/asks: >Hi Frank, > >I'll try to answer your questions about WebDAV vs. FTP: > > >> 1) WebDAV cannot be programmatically and securely applied to >> individual web sites. Currently, creating an account on my MacOS X >> Server (Apache) programmatically creates web space whose address >> takes the form http://myserver.gcsu.edu/~username and >> programmatically enables FTP access to that web space using the un/pw >> assigned to the account. This can be done on a large scale with >> batch methods. > >I'm not sure what you're asking here. Are you asking from an >implementor/administrator point of view, whether a server can be implemented >that supports WebDAV and securely supports individual Web sites? If that's >the question, then Sharemation is an existence proof that this can be easily >done. The site www.sharemation.com hosts individual web sites for many >thousands of accounts. Although there's a Web interface to allow users to >sign up, after registration users can manage their sites with WebDAV. Many >universities are now starting to provide WebDAV-enabled individual sites to >students with this technology, but instead of allowing free signup as >Sharemation does, these universities use batch methods to create thousands >of accounts each semester as new students arrive. There is no FTP access to >these accounts because it's no longer needed. What I hope to do is provide WebDAV-enabled sites to thousands of students and hundreds of faculty at our university on a very limited budget and without obsoleting investments already made, to wit: o several XServe units running the latest MacOS X Server software (10.2.6) with includes the Apache webserver with mod_dav precompiled. See: http://www.apple.com/macosx/server/ o several MacOS X towers running the latest WebSTAR V Server Suite (5.3.x). NOTE: WebSTAR V supports WebDAV with a very elaborate security model that is great for many people working on a single web site -- the conventional application of WebDAV. See: http://www.webstar.com I would like to be able to provide individual web site accounts programmatically in batched and on-demand formats using a GUI front end not unlike what is available to MacOS X Server and WebSTAR V Server Admins. That this is possible is difficult to deny. I now have several existence proofs as follows: 1) Sharemation (see: http://www.sharemation.com) 2) Apple's iDisk (part of dotMac) (see: http://www.mac.com/) 3) WebCT 3.8 and WebCT Vista (see http://www.webct.com) NOTE: WebCT Vista uses the BEA WebLogic server. WebCT is a Courseware Management System (CMS) widely used in higher education. WebCT Vista has been adopted system-wide in Georgia's University System. Interestingly, I see no mention of this at www.webdav.org in the way of an announcement. >Or are you asking whether WebDAV can be used by a client program to manage a >Web site remotely and automatically? Sitecopy and GoLive are client >programs that do this. > >> 2) WebDAV does not offer disk space quota enforcement and the means >> with which to discover one's usage of that disk space and take >> corrective action. > >A WebDAV server implementation can offer disk space quota enforcement, as >Apple iDisk and Xythos WFS do. This must be managed by the administrator of >course. It's true that it's difficult to discover one's usage of that disk >space however there is a HTTP error commonly used when that quota is reached >("Insufficient Storage"). Furthermore, we're working on an extension to >WebDAV to provide quota-related properties so that an individual user may >discover their quota and storage usage. > >Are you sure that FTP offers this functionality anyway? I didn't think that >was part of the FTP standard. I would think the user would have to type in >Unix queries and understand the answer themselves, rather than be able to >use a GUI client that is capable of parsing the quota information and issue >warnings. FTP Servers offer this functionality. Two examples include Rumpus (http://www.maxum.com) and the FTP client bundled with the WebSTAR V Server Suite (see http://www.webstar.com). Clients will report the soft limit and hard limit warning messages issued by these FTP servers. > > 3) WebDAV does not offer password management (neither does FTP but I >> mention it here to complete a basic feature list). > >Typically password management is not part of an application protocol -- as >you point out, it's not part of FTP (nor is it part of IMAP, etc) From the client perspective, such functionality is needed in a way that **appears** to be integrated with the editing experience is desirable. >Instead, typically password management is an administrative function, which >means that it can either be done through an administration UI (not through >the application protocol) or through LDAP. WebDAV can work with LDAP: e.g. >an administrator can create LDAP accounts and set passwords, then when users >try to log into the WebDAV server the WebDAV server queries the LDAP server >to see if the login should be allowed. A number of universities are also >doing this already. I can provide you with more details if you're >interested. Admins need to be able to set pw criteria (# chars, composition, even checking pw history in a database) and enforce a pw change schedule. On the client side, users need to have the means with which to easily comply with these requirements/policies - a pw changing interface. Again, we seek only the **appearance** of integration from the client's perspective. >Good questions! >Lisa Dusseault -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Sun Jun 29 13:50: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 NAA02940 for ; Sun, 29 Jun 2003 13:50:42 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5THoRSn000953; Sun, 29 Jun 2003 13:50:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5THoBow000835; Sun, 29 Jun 2003 13:50:11 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 13:50:11 -0400 (EDT) Resent-Message-Id: <200306291750.h5THoBow000835@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5THo7Sn000793 for ; Sun, 29 Jun 2003 13:50:07 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5THo7nV015489 for ; Sun, 29 Jun 2003 13:50:07 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19WgJS-0003br-00; Sun, 29 Jun 2003 17:50:06 +0000 Received: from [198.144.203.253] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19WgJS-0003bg-00; Sun, 29 Jun 2003 17:50:06 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Jason Crawford'" Cc: Date: Sun, 29 Jun 2003 10:50:04 -0700 Message-ID: <00c801c33e66$e0d026f0$fdcb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, nn683849@smallcue.com, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h5THo7Sn000793 Subject: RE: comments on RFC2518bis-02, sec 6.3 X-Archived-At: http://www.w3.org/mid/00c801c33e66$e0d026f0$fdcb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7704 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > > 5) Section 6.3, p3 > > > > > > Replace > > > > > > "However resources are free to return any URI scheme so > long as it > > > meets > > the > > > uniqueness requirements." > > > > > > by > > > > > > "However servers are free to use any IETF-registered URI > scheme so > > > long > > as > > > it meets the uniqueness requirements." > > > > ? Is it important to be IETF registered ? > > Yes. A non-registered URI scheme doesn't have *any* > guaranteed uniqueness, so it doesn't serve it's stated purpose... > That's not true. If I create a URI scheme where the scheme name is "http://www.xythos.com/storageServer/locktoken/", without registering this with the IETF, it can still meet the uniqueness guarantee. For that matter, a sufficiently long randomly generated set of characters, as long as it meets the URI formatting requirements, statistically meets the uniqueness guarantee. Lisa From w3c-dist-auth-request@w3.org Sun Jun 29 14:12: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 OAA03217 for ; Sun, 29 Jun 2003 14:12:06 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TIC5Sn006545; Sun, 29 Jun 2003 14:12:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5TIBq8I006486; Sun, 29 Jun 2003 14:11:52 -0400 (EDT) Resent-Date: Sun, 29 Jun 2003 14:11:52 -0400 (EDT) Resent-Message-Id: <200306291811.h5TIBq8I006486@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5TIBoSn006452 for ; Sun, 29 Jun 2003 14:11:50 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h5TIBnnV010399 for ; Sun, 29 Jun 2003 14:11:49 -0400 Received: (qmail 20583 invoked by uid 65534); 29 Jun 2003 18:11:43 -0000 Received: from p3EE24837.dip.t-dialin.net (HELO lisa) (62.226.72.55) by mail.gmx.net (mp027) with SMTP; 29 Jun 2003 20:11:43 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Jason Crawford'" Cc: Date: Sun, 29 Jun 2003 20:11:36 +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: <00c801c33e66$e0d026f0$fdcb90c6@lisalap> Importance: Normal Subject: RE: comments on RFC2518bis-02, sec 6.3 X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEDOHLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7705 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Sunday, June 29, 2003 7:50 PM > To: 'Julian Reschke'; 'Jason Crawford' > Cc: w3c-dist-auth@w3.org > Subject: RE: comments on RFC2518bis-02, sec 6.3 > > > Yes. A non-registered URI scheme doesn't have *any* > > guaranteed uniqueness, so it doesn't serve it's stated purpose... > > > > That's not true. If I create a URI scheme where the scheme name is > "http://www.xythos.com/storageServer/locktoken/", without registering this > with the IETF, it can still meet the uniqueness guarantee. You can't create a URI scheme with that kind of scheme name. The scheme part of a URI is the string before the first colon, so the URI scheme for that URI is just "http" (which indeed *is* a registered URI scheme). And yes, you can use these kinds of URIs for lock tokens. > For that matter, a sufficiently long randomly generated set of characters, > as long as it meets the URI formatting requirements, > statistically meets the > uniqueness guarantee. How do you "statistically" meet a requirement? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jun 30 19:10: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 TAA21353 for ; Mon, 30 Jun 2003 19:10:17 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5UNAGSn025332; Mon, 30 Jun 2003 19:10:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h5UN9qnt025054; Mon, 30 Jun 2003 19:09:52 -0400 (EDT) Resent-Date: Mon, 30 Jun 2003 19:09:52 -0400 (EDT) Resent-Message-Id: <200306302309.h5UN9qnt025054@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h5UN9oSn025017 for ; Mon, 30 Jun 2003 19:09:50 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5UN9nnV027798 for ; Mon, 30 Jun 2003 19:09:50 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19X7mN-0004rV-00; Mon, 30 Jun 2003 23:09:47 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19X7mM-0004rK-00; Mon, 30 Jun 2003 23:09:46 +0000 Date: Mon, 30 Jun 2003 16:10:16 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: w3c-dist-auth@w3.org To: Frank Lowney From: Brian Korver In-Reply-To: Message-Id: <029CC648-AB50-11D7-B03D-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, frank.lowney@mac.com Subject: Re: WebDAV vs FTP, not an easy choice X-Archived-At: http://www.w3.org/mid/029CC648-AB50-11D7-B03D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7706 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Sunday, June 29, 2003, at 05:47 AM, Frank Lowney wrote: [snip] > 1) WebDAV cannot be programmatically and securely applied to > individual web sites. Currently, creating an account on my MacOS X > Server (Apache) programmatically creates web space whose address takes > the form http://myserver.gcsu.edu/~username and programmatically > enables FTP access to that web space using the un/pw assigned to the > account. This can be done on a large scale with batch methods. If your WebDAV server integrates with your directory service (LDAP, ActiveDirectory, NetInfo, YP, etc.), then these accounts would appear as soon as the user's account is created in the directory. I do know of vendors that produce such servers ;). > > 2) WebDAV does not offer disk space quota enforcement and the means > with which to discover one's usage of that disk space and take > corrective action. FYI: http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-01.txt > > 3) WebDAV does not offer password management (neither does FTP but I > mention it here to complete a basic feature list). > > Of course, I would like to be wrong about this and I believe that I > am. Apple seems to have accomplished a good measure of what I > describe above with "dotMac" accounts that include WebDAV access via > what it calls an "iDisk." However, the techniques behind this are not > generally and perhaps not even publicly, available. > > I would like to extend this kind of functionality to the thousands of > students and hundreds of faculty at my university but apparently > cannot due to the unavailability of critical information n the > techniques employed. Being able to drop support for FTP would > certainly make our networking a security folks happy. Being able to > supplant FTP with WebDAV would likely be viewed as progress by our > clients. Unfortunately, it does not appear to be possible right > now. > > Here, again, I hope to be shown the error of my thinking. Again, directory service integration would give you what you want. When the user changes their password using their standard password change mechanism, that password change goes into the directory, which of course the server will pick up immediately. -brian briank@xythos.com