From w3c-dist-auth-request@listhub.w3.org Wed Sep 3 16:52:58 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B643A6C41 for ; Wed, 3 Sep 2008 16:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWQTzLtFwGgc for ; Wed, 3 Sep 2008 16:52:57 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 54CC93A6916 for ; Wed, 3 Sep 2008 16:52:56 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kb28I-0006sl-EZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 03 Sep 2008 23:51:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kb28H-0006s7-2A for w3c-dist-auth@listhub.w3.org; Wed, 03 Sep 2008 23:51:29 +0000 Received: from mail.manyfish.co.uk ([81.187.127.133]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kb288-0004Fa-8M for w3c-dist-auth@w3.org; Wed, 03 Sep 2008 23:51:28 +0000 Received: from joe by mail.manyfish.co.uk with local (Exim 4.69) (envelope-from ) id 1Kb27c-0003OV-0h; Thu, 04 Sep 2008 00:50:48 +0100 Date: Thu, 4 Sep 2008 00:50:48 +0100 From: Joe Orton To: Julian Reschke Cc: Evert | Rooftop , w3c-dist-auth@w3.org Message-ID: <20080903235047.GA13045@manyfish.co.uk> Mail-Followup-To: Julian Reschke , Evert | Rooftop , w3c-dist-auth@w3.org References: <658488E7-B691-4A48-9043-8B6D0D902F88@rooftopsolutions.nl> <48B65921.2000202@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <48B65921.2000202@gmx.de> User-Agent: Mutt/1.5.18 (2008-05-17) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1Kb288-0004Fa-8M d6a855a79bffb667e3fb4640c8e5bcfa X-Original-To: w3c-dist-auth@w3.org Subject: Re: Litmus test questions Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 03 Sep 2008 23:51:30 +0000 On Thu, Aug 28, 2008 at 09:52:01AM +0200, Julian Reschke wrote: >> ... >> > xmlns='DAV:'>> xmlns:t='http://webdav.org/neon/litmus/'>> xmlns='bar'/> >> >> The 'bar' namespace is an invalid one, and expat is quickly to respond >> with: xmlns: URI bar is not absolute, so I respond with a 400 Bad >> Request.. Hi folks. I don't think there's a reason why 'bar' is used in that test in favour of a real URI. I'll update the test to use a real URI there instead. Regards, Joe From w3c-dist-auth-request@listhub.w3.org Wed Sep 3 18:42:13 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C2D3A6D0B for ; Wed, 3 Sep 2008 18:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj+9Mz8L3nLB for ; Wed, 3 Sep 2008 18:42:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 873D43A6CE1 for ; Wed, 3 Sep 2008 18:42:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kb3qc-0006NJ-2E for w3c-dist-auth-dist@listhub.w3.org; Thu, 04 Sep 2008 01:41:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kb3qa-0006Ma-MH for w3c-dist-auth@listhub.w3.org; Thu, 04 Sep 2008 01:41:20 +0000 Received: from yx-out-1718.google.com ([74.125.44.153]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kb3qR-0007Zl-I6 for w3c-dist-auth@w3.org; Thu, 04 Sep 2008 01:41:20 +0000 Received: by yx-out-1718.google.com with SMTP id 36so1448650yxh.26 for ; Wed, 03 Sep 2008 18:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=5tEuHge5MJ7O8uynEmz3nMnZSjfgbIwr9Sg/3fyJAEM=; b=Y71XuI4oZJu5nLod5L8MBpQmwliOiUcuWqO6UokwzlnvNwFyTeCWUWzPdhkb62Xw0t 6pTp9jMVsSdfgYXHiIoEA1VS6EJkazAFFGVQrf4mDQUQ5YP7TpwoD7iH1+Zq+gY3E5Wc 288G18uCqQHtVqVAdBlvyU+aZ1tkkB+7p1Zvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=nw9FgLHareYJ85VDMwRETBlEjcQYiz7rYhErDa0WeqHlMYokmPedGFv4PEQjjNYu9O IpKs/5AKF97jBUrlakj94YxILDHBhUblkYjPUXRbd3G/+JFy/ogfmq4f+0tHr9D42JxF NwyLeA9a0xn5DCuY4+csaSAqqkWI+nY/1yLJU= Received: by 10.150.202.9 with SMTP id z9mr8347025ybf.54.1220492444653; Wed, 03 Sep 2008 18:40:44 -0700 (PDT) Received: from ?192.168.0.108? ( [99.254.59.165]) by mx.google.com with ESMTPS id p31sm14753824qbp.18.2008.09.03.18.40.43 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Sep 2008 18:40:43 -0700 (PDT) Cc: Julian Reschke , w3c-dist-auth@w3.org Message-Id: <74473D76-88B1-470F-A543-73F9D815B774@rooftopsolutions.nl> From: Evert | Rooftop To: Joe Orton In-Reply-To: <20080903235047.GA13045@manyfish.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 3 Sep 2008 21:40:41 -0400 References: <658488E7-B691-4A48-9043-8B6D0D902F88@rooftopsolutions.nl> <48B65921.2000202@gmx.de> <20080903235047.GA13045@manyfish.co.uk> X-Mailer: Apple Mail (2.928.1) Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1Kb3qR-0007Zl-I6 4bed52b603a1d0d04b7d90120093b7c2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Litmus test questions Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 04 Sep 2008 01:41:22 +0000 I actually handled it here by catching and ignoring that single expact error, thinking it was the right thing to do =) I'm somewhat happy to hear this is going to be fixed, because it felt wrong (even though I'd trust litmus before not-fatal expat errors). I just thought some clients 'might' send this over, which is why this test was written as such. Hearing this is not the case, I'll get rid of the workaround right now :) Evert On 3-Sep-08, at 7:50 PM, Joe Orton wrote: > > On Thu, Aug 28, 2008 at 09:52:01AM +0200, Julian Reschke wrote: >>> ... >>> >> xmlns='DAV:'>>> xmlns:t='http://webdav.org/neon/litmus/'>>> xmlns='bar'/> >>> >>> The 'bar' namespace is an invalid one, and expat is quickly to >>> respond >>> with: xmlns: URI bar is not absolute, so I respond with a 400 Bad >>> Request.. > > Hi folks. I don't think there's a reason why 'bar' is used in that > test > in favour of a real URI. I'll update the test to use a real URI there > instead. > > Regards, Joe > From w3c-dist-auth-request@listhub.w3.org Wed Sep 3 23:55:12 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22293A6809 for ; Wed, 3 Sep 2008 23:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.907 X-Spam-Level: X-Spam-Status: No, score=-8.907 tagged_above=-999 required=5 tests=[AWL=1.692, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23skPRkhDy+d for ; Wed, 3 Sep 2008 23:55:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 14ECA3A6D51 for ; Wed, 3 Sep 2008 23:55:11 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kb8ik-00061U-32 for w3c-dist-auth-dist@listhub.w3.org; Thu, 04 Sep 2008 06:53:34 +0000 Received: from [128.30.52.63] (helo=bart.w3.org) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kb8ih-00060q-OM for w3c-dist-auth@listhub.w3.org; Thu, 04 Sep 2008 06:53:31 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Kb8iZ-0003Yf-2r for w3c-dist-auth@w3.org; Thu, 04 Sep 2008 02:53:31 -0400 Received: (qmail invoked by alias); 04 Sep 2008 06:52:51 -0000 Received: from p508FFF4F.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.255.79] by mail.gmx.net (mp019) with SMTP; 04 Sep 2008 08:52:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/fHPFBvu7fjGf2i6WAKtJO74nH0zPtLZAvGm8AaQ YMu3XrgWuWTsKY Message-ID: <48BF85BF.3060800@gmx.de> Date: Thu, 04 Sep 2008 08:52:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Evert | Rooftop CC: Joe Orton , w3c-dist-auth@w3.org References: <658488E7-B691-4A48-9043-8B6D0D902F88@rooftopsolutions.nl> <48B65921.2000202@gmx.de> <20080903235047.GA13045@manyfish.co.uk> <74473D76-88B1-470F-A543-73F9D815B774@rooftopsolutions.nl> In-Reply-To: <74473D76-88B1-470F-A543-73F9D815B774@rooftopsolutions.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Kb8iZ-0003Yf-2r b06f31477eb80b8f8f09a1ca752a0ddb X-Original-To: w3c-dist-auth@w3.org Subject: Re: Litmus test questions Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13005 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 04 Sep 2008 06:53:34 +0000 Evert | Rooftop wrote: > I actually handled it here by catching and ignoring that single expact > error, thinking it was the right thing to do =) I think there's a also a compile-time option for expat not to validate namespace names. > I'm somewhat happy to hear this is going to be fixed, because it felt > wrong (even though I'd trust litmus before not-fatal expat errors). > > I just thought some clients 'might' send this over, which is why this > test was written as such. Hearing this is not the case, I'll get rid of > the workaround right now :) I wouldn't count on clients not doing this. Assigning namespace names is something many people sadly get wrong, and so far, I haven't seen a system that checks for that (part of the blame for that goes to the XMLNS spec). BR, Julian From w3c-dist-auth-request@listhub.w3.org Mon Sep 22 08:45:35 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F046A3A686A for ; Mon, 22 Sep 2008 08:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj+CjUsrJVXY for ; Mon, 22 Sep 2008 08:45:30 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 4525D3A69A7 for ; Mon, 22 Sep 2008 08:45:30 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KhnZg-000724-M9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Sep 2008 15:43:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhnZf-00071Q-6v for w3c-dist-auth@listhub.w3.org; Mon, 22 Sep 2008 15:43:43 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KhnZS-0002GK-4C for w3c-dist-auth@w3.org; Mon, 22 Sep 2008 15:43:42 +0000 Received: (qmail invoked by alias); 22 Sep 2008 15:42:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 22 Sep 2008 17:42:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19UPO0PSUJU4Bu6Kv0VlX54AGY2N7cdwB7U+Hixze iCWC0DgiIDFNUA Message-ID: <48D7BCFE.40200@gmx.de> Date: Mon, 22 Sep 2008 17:42:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> In-Reply-To: <20080922153001.BC5663A69E7@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1KhnZS-0002GK-4C 3436866578255d402b3156c3e914e776 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Sep 2008 15:43:44 +0000 FYI -- this is an early draft of what I proposed in July (). Feedback appreciated, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using POST to add to Web Distributed Authoring and Versioning (WebDAV) Collections > Author(s) : J. Reschke > Filename : draft-reschke-webdav-post-00.txt > Pages : 11 > Date : 2008-09-22 > > The Hypertext Transfer Protocol (HTTP) Extensions for the Web > Distributed Authoring and Versioning (WebDAV) do not define the > behavior for the "POST" method when applied to collections, as the > base specification (HTTP) leaves implementers lots of freedom for the > semantics of "POST". > > This has lead to a situation where many WebDAV servers do not > implement POST for collections at all, although it is well suited to > be used for the purpose of adding new members to a collection, where > the server remains in control of the newly assigned URL. As a matter > of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for > that purpose. On the other hand, WebDAV-based protocols such as the > Calendar Extensions to WebDAV (CalDAV) frequently require clients to > pick a unique URL, although the server could easily perform that > task. > > This specification defines a discovery mechanism through which > servers can advertise support for POST requests with the > aforementioned "add collection member" semantics. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-webdav-post-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From w3c-dist-auth-request@listhub.w3.org Mon Sep 22 09:28:28 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667D13A6B04 for ; Mon, 22 Sep 2008 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwQ3uB5TaA+g for ; Mon, 22 Sep 2008 09:28:27 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6C6643A6A2B for ; Mon, 22 Sep 2008 09:28:27 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KhoFe-0005sr-5T for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Sep 2008 16:27:06 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhoFc-0005sD-T2 for w3c-dist-auth@listhub.w3.org; Mon, 22 Sep 2008 16:27:04 +0000 Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhoFU-0000fB-9Z for w3c-dist-auth@w3.org; Mon, 22 Sep 2008 12:27:04 -0400 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2F168D05150; Mon, 22 Sep 2008 12:26:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naSnkyx7bG2O; Mon, 22 Sep 2008 12:26:25 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id C9194D05149; Mon, 22 Sep 2008 12:26:24 -0400 (EDT) Date: Mon, 22 Sep 2008 12:26:22 -0400 From: Cyrus Daboo To: Julian Reschke , WebDAV Message-ID: <471672D975269B091322772E@caldav.corp.apple.com> In-Reply-To: <48D7BCFE.40200@gmx.de> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Hub-Spam-Report: BAYES_05=-1.11 X-W3C-Scan-Sig: bart.w3.org 1KhoFU-0000fB-9Z dc4c6e7a07ecfa6ed6b3b864198e50d4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Sep 2008 16:27:06 +0000 Hi Julian, --On September 22, 2008 5:42:54 PM +0200 Julian Reschke wrote: > FYI -- this is an early draft of what I proposed in July > ( > ). > > F Looks good overall. Some comments: 1) When I first read the title I somehow thought this was talking about using POST to "create" collections. Perhaps change it to: Using POST to add members to Web Distributed Authoring and Versioning (WebDAV) Collections 2) I think this is a sufficiently worthy addition to WebDAV that using DAV: for the namespace is OK (just as we did with the current-user-principal property). 3) What about COPY/MOVE behavior? Is it OK to use the add-member property value as the Destination for COPY or MOVE when creating a new member in the destination? Or does a client instead have to user POST to create an empty resource first, then target that with the COPY/MOVE? 4) Something needs to be stated about error handling: e.g., "If there are pre-conditions related to creating a resource in the collection using a PUT request, then those same pre-conditions apply to the new POST request behavior, and the same DAV:error response body returned on failure". This would be a "catch-all" to allow protocols such as CalDAV, which restrict certain aspects of the data stored in collections, to simply return the same pre-condition failure information for POST as for PUT. 5) Is the server allowed to re-use new member URIs? i.e. /a/b.txt exists at some point, then is deleted. Is the server then allowed to use b.txt as a new member of /a/, or does the new member path segment have to be unique for the entire existence of that collection? If the member path segment is expected to be unique there should be some guidance to servers on how they might implement that (uuid's for instance). 6) It is also worth adding a note to client implementors stating that the server-generated member path segment is likely to not be suitable for direct presentation to end users, and instead clients should rely on the DAV:displayname property for presentation purposes. 7) Security consideration: "Servers MUST NOT derive the member path segment from the data being stored in the resource". This is important because you don't want server's leaking information in the URI that would not otherwise be visible (e.g. a user can PROPFIND the members but cannot read the content of the members - leaking content in the URI would be bad). Note this impacts how the server generates the member path segment. e.g. an md5 hash of the data only may not be appropriate. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Mon Sep 22 10:21:45 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCC33A6C00 for ; Mon, 22 Sep 2008 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGstrfw7mDqG for ; Mon, 22 Sep 2008 10:21:44 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D63013A6BD6 for ; Mon, 22 Sep 2008 10:21:43 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Khp5E-0003MV-MH for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Sep 2008 17:20:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Khp5D-0003Lm-7X for w3c-dist-auth@listhub.w3.org; Mon, 22 Sep 2008 17:20:23 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Khp54-0007DR-0o for w3c-dist-auth@w3.org; Mon, 22 Sep 2008 17:20:22 +0000 Received: (qmail invoked by alias); 22 Sep 2008 17:19:41 -0000 Received: from p508FF2B8.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.242.184] by mail.gmx.net (mp064) with SMTP; 22 Sep 2008 19:19:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+IxiwzMN2IgnybaEdJGRT/dVvgHmzvKiUMaaZmBP mfIXISHuONIFvC Message-ID: <48D7D3A2.7010009@gmx.de> Date: Mon, 22 Sep 2008 19:19:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> In-Reply-To: <471672D975269B091322772E@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1Khp54-0007DR-0o 88d84a5883f7693e2a8be51c88215320 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Sep 2008 17:20:24 +0000 Hi Cyrus, that may have been the world record for the fastest feedback after an Internet Draft being published! Cyrus Daboo wrote: > > Hi Julian, > > --On September 22, 2008 5:42:54 PM +0200 Julian Reschke > wrote: > >> FYI -- this is an early draft of what I proposed in July >> ( >> ). >> >> F > > Looks good overall. Some comments: > > 1) When I first read the title I somehow thought this was talking about > using POST to "create" collections. Perhaps change it to: > > Using POST to add members to Web Distributed Authoring and Versioning > (WebDAV) > Collections Actually, it was supposed to say that. Thanks for pointing this out (as usually, current edits are at ). > 2) I think this is a sufficiently worthy addition to WebDAV that using > DAV: for the namespace is OK (just as we did with the > current-user-principal property). Thanks. > 3) What about COPY/MOVE behavior? Is it OK to use the add-member > property value as the Destination for COPY or MOVE when creating a new > member in the destination? Or does a client instead have to user POST to > create an empty resource first, then target that with the COPY/MOVE? The former would only work when the server actually has minted a separate URI (which I think will be the less frequent case). That being said, that COPY/MOVE functionality could of course be exposed using *another* URI. > 4) Something needs to be stated about error handling: e.g., "If there > are pre-conditions related to creating a resource in the collection > using a PUT request, then those same pre-conditions apply to the new > POST request behavior, and the same DAV:error response body returned on > failure". This would be a "catch-all" to allow protocols such as CalDAV, > which restrict certain aspects of the data stored in collections, to > simply return the same pre-condition failure information for POST as for > PUT. Sounds good. > 5) Is the server allowed to re-use new member URIs? i.e. /a/b.txt exists > at some point, then is deleted. Is the server then allowed to use b.txt > as a new member of /a/, or does the new member path segment have to be > unique for the entire existence of that collection? If the member path > segment is expected to be unique there should be some guidance to > servers on how they might implement that (uuid's for instance). I don't expect it to be unique. Of course a collection *could* have that property, but that would need to be exposed differently (DAV:resourcetype?). > 6) It is also worth adding a note to client implementors stating that > the server-generated member path segment is likely to not be suitable > for direct presentation to end users, and instead clients should rely on > the DAV:displayname property for presentation purposes. That depends. For instance, if the client specified a Slug, and the server used that, the resulting URI actually is expected to work ok for display purposes. > 7) Security consideration: "Servers MUST NOT derive the member path > segment from the data being stored in the resource". This is important > because you don't want server's leaking information in the URI that > would not otherwise be visible (e.g. a user can PROPFIND the members but > cannot read the content of the members - leaking content in the URI > would be bad). Note this impacts how the server generates the member Good catch. > path segment. e.g. an md5 hash of the data only may not be appropriate. ...how could that one leak information? BR, Julian From w3c-dist-auth-request@listhub.w3.org Mon Sep 22 11:55:39 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDDE3A69F7 for ; Mon, 22 Sep 2008 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ue+sks1avGU for ; Mon, 22 Sep 2008 11:55:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 40CA13A67D0 for ; Mon, 22 Sep 2008 11:55:38 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KhqXo-0000K4-0Q for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Sep 2008 18:54:00 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhqXm-0000JQ-LY for w3c-dist-auth@listhub.w3.org; Mon, 22 Sep 2008 18:53:58 +0000 Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhqXd-0000US-SL for w3c-dist-auth@w3.org; Mon, 22 Sep 2008 14:53:58 -0400 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 378A6D0628D; Mon, 22 Sep 2008 14:53:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdUnEGR00+bh; Mon, 22 Sep 2008 14:53:23 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id A43A3D06286; Mon, 22 Sep 2008 14:53:22 -0400 (EDT) Date: Mon, 22 Sep 2008 14:53:20 -0400 From: Cyrus Daboo To: Julian Reschke cc: WebDAV Message-ID: <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> In-Reply-To: <48D7D3A2.7010009@gmx.de> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1KhqXd-0000US-SL 9281c84d9855994710851f4780bab7cb X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Sep 2008 18:54:00 +0000 Hi Julian, --On September 22, 2008 7:19:30 PM +0200 Julian Reschke wrote: >> 3) What about COPY/MOVE behavior? Is it OK to use the add-member >> property value as the Destination for COPY or MOVE when creating a new >> member in the destination? Or does a client instead have to user POST to >> create an empty resource first, then target that with the COPY/MOVE? > > The former would only work when the server actually has minted a separate > URI (which I think will be the less frequent case). > > That being said, that COPY/MOVE functionality could of course be exposed > using *another* URI. So p:copy-member and p:move-member properties? One thing this reminds me of: another reason why this POST may be needed is if the server enforces a particular naming scheme on members. e.g., a CalDAV server may require that all member path segments match the UID in the calendar data, or match a record-id in its data store etc. In this case the add-member behavior is required. So its not just the case of "the client doesn't care to name members itself", but also this other one. Probably worth adding a comment on this. >> 5) Is the server allowed to re-use new member URIs? i.e. /a/b.txt exists >> at some point, then is deleted. Is the server then allowed to use b.txt >> as a new member of /a/, or does the new member path segment have to be >> unique for the entire existence of that collection? If the member path >> segment is expected to be unique there should be some guidance to >> servers on how they might implement that (uuid's for instance). > > I don't expect it to be unique. Of course a collection *could* have that > property, but that would need to be exposed differently > (DAV:resourcetype?). If they are not guaranteed to be unique then we could run into client synchronizations issues if a resource is deleted and then a new one added, but created using the same name as the old one. That new resource is really meant to be totally different from the old, but any clients that had cached the old one and attempt to re-synchronize will end up doing so with the new resource. That could cause all kinds of nastiness when two ways sync'ing might be expected (e.g, disconnected CalDAV clients). So, it might be worth pointing out that there are some use cases (two way sync) where it is best for a server to generate unique member names (or rather not re-use old, now deleted, member names). >> 7) Security consideration: "Servers MUST NOT derive the member path >> segment from the data being stored in the resource". This is important >> because you don't want server's leaking information in the URI that >> would not otherwise be visible (e.g. a user can PROPFIND the members but >> cannot read the content of the members - leaking content in the URI >> would be bad). Note this impacts how the server generates the member > > Good catch. > >> path segment. e.g. an md5 hash of the data only may not be appropriate. > > ...how could that one leak information? Well, knowing that users X, Y and Z all had the same member name in their different collections would imply that they all had received copies of the same resource. In calendaring that could mean they were all invited to the same event. Being able to infer that might not be ideal. But then again giving someone the ability to PROPFIND a collection but not read the contents of the members is arguably leaking too much anyway (though I have had several arguments about this with colleagues who disagree). -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Mon Sep 22 12:11:06 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFFD3A682F for ; Mon, 22 Sep 2008 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLlcMswlAzmb for ; Mon, 22 Sep 2008 12:11:06 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BBE9D28C0F3 for ; Mon, 22 Sep 2008 12:10:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KhqnH-0005pc-Ns for w3c-dist-auth-dist@listhub.w3.org; Mon, 22 Sep 2008 19:09:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KhqnG-0005oy-QS for w3c-dist-auth@listhub.w3.org; Mon, 22 Sep 2008 19:09:59 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Khqn4-0004z6-2W for w3c-dist-auth@w3.org; Mon, 22 Sep 2008 19:09:58 +0000 Received: (qmail invoked by alias); 22 Sep 2008 19:09:14 -0000 Received: from p508FF2B8.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.242.184] by mail.gmx.net (mp062) with SMTP; 22 Sep 2008 21:09:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/votA9gRDvnkcVfoowE97kGnGJQX0M15PYaeNPG9 gd1zIX45HAM52r Message-ID: <48D7ED55.3050307@gmx.de> Date: Mon, 22 Sep 2008 21:09:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> In-Reply-To: <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1Khqn4-0004z6-2W aa17a7bd96b5903f0f2c4c74753aa05a X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 22 Sep 2008 19:09:59 +0000 Cyrus Daboo wrote: >>> 3) What about COPY/MOVE behavior? Is it OK to use the add-member >>> property value as the Destination for COPY or MOVE when creating a new >>> member in the destination? Or does a client instead have to user POST to >>> create an empty resource first, then target that with the COPY/MOVE? >> >> The former would only work when the server actually has minted a separate >> URI (which I think will be the less frequent case). >> >> That being said, that COPY/MOVE functionality could of course be exposed >> using *another* URI. > > So p:copy-member and p:move-member properties? Potentially. My primary concern was to allow WebDAV collections to do something sensible with POST which is compatible with AtomPub, and which also addresses a real need that we've seen for instance with CalDAV. This turned out to be trivial. I'm concerned to add something that's not as easy to achieve, and where I'm not sure about what the use case is. Note that Microsoft does define an extension header for things like that, essentially allowing the server to "rename" the Destination URI. Maybe it's worthwhile looking at that for COPY/MOVE. > One thing this reminds me of: another reason why this POST may be needed > is if the server enforces a particular naming scheme on members. e.g., a > CalDAV server may require that all member path segments match the UID in > the calendar data, or match a record-id in its data store etc. In this > case the add-member behavior is required. So its not just the case of > "the client doesn't care to name members itself", but also this other > one. Probably worth adding a comment on this. Of course, that's a major reason to do that. I'll add that to the Introduction. >> I don't expect it to be unique. Of course a collection *could* have that >> property, but that would need to be exposed differently >> (DAV:resourcetype?). > > If they are not guaranteed to be unique then we could run into client > synchronizations issues if a resource is deleted and then a new one > added, but created using the same name as the old one. That new resource > is really meant to be totally different from the old, but any clients > that had cached the old one and attempt to re-synchronize will end up > doing so with the new resource. That could cause all kinds of nastiness > when two ways sync'ing might be expected (e.g, disconnected CalDAV > clients). You could use DAV:resource-id to distinguish them. > So, it might be worth pointing out that there are some use cases (two > way sync) where it is best for a server to generate unique member names > (or rather not re-use old, now deleted, member names). Agreed, but doesn't that consideration belong into the specification that defines that specific collection's behavior? (such as vcarddav?) > ... >>> path segment. e.g. an md5 hash of the data only may not be appropriate. >> >> ...how could that one leak information? > > Well, knowing that users X, Y and Z all had the same member name in > their different collections would imply that they all had received > copies of the same resource. In calendaring that could mean they were > all invited to the same event. Being able to infer that might not be > ideal. But then again giving someone the ability to PROPFIND a > collection but not read the contents of the members is arguably leaking > too much anyway (though I have had several arguments about this with > colleagues who disagree). Thanks for the example. And yes, whether non-accessible members of a collection should show up upon PROPFIND is an interesting question, and we're not going to solve that here. (I personally believe that if the presence of a collection member's name already leaks out information, you really should restrict the read access to the parent collection...) BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Sep 23 08:11:59 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0EF33A688F for ; Tue, 23 Sep 2008 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-eziTPJLCV4 for ; Tue, 23 Sep 2008 08:11:58 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B00303A6B2C for ; Tue, 23 Sep 2008 08:11:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Ki9X8-0001HS-9D for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Sep 2008 15:10:34 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Ki9X6-0001Go-UY for w3c-dist-auth@listhub.w3.org; Tue, 23 Sep 2008 15:10:32 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Ki9Wy-0005Ui-2E for w3c-dist-auth@w3.org; Tue, 23 Sep 2008 11:10:32 -0400 Received: (qmail invoked by alias); 23 Sep 2008 15:09:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 23 Sep 2008 17:09:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18qvWFPn+0q1WsmMf76dhpN4LMRa1icfu4YKbJmyg cz9SiEKsNY9TMX Message-ID: <48D906BC.1050003@gmx.de> Date: Tue, 23 Sep 2008 17:09:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> In-Reply-To: <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Ki9Wy-0005Ui-2E 6eb74bad44d67848da107134dceb8bd4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 23 Sep 2008 15:10:34 +0000 Cyrus Daboo wrote: > ... > One thing this reminds me of: another reason why this POST may be needed > is if the server enforces a particular naming scheme on members. e.g., a > CalDAV server may require that all member path segments match the UID in > the calendar data, or match a record-id in its data store etc. In this > case the add-member behavior is required. So its not just the case of > "the client doesn't care to name members itself", but also this other > one. Probably worth adding a comment on this. > ... Well, if the server enforces a particular naming scheme, and does not support POST, then the client will need out-of-band information about the naming scheme, right? How would that work in practice? I think what's more common is that the server would *like* to enforce a naming scheme, but can't, as clients assume PUT will just work. Isn't that the situation for many CalDAV servers? What I've added is (): "As a matter of fact, letting the server choose the member URI not only is a simplification for certain types of clients, but can also reduce the complexity of the server (in that it doesn't need to persist an additional client-supplied identifier where the it already has an internal one like a UUID or a primary key)." That said, I think I'm ready to submit a new draft soon; comments on appreciated. BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Sep 23 08:31:32 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7A63A6819 for ; Tue, 23 Sep 2008 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnin0RyDvMIp for ; Tue, 23 Sep 2008 08:31:25 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 661D03A6A47 for ; Tue, 23 Sep 2008 08:31:25 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Ki9qn-0002F3-2I for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Sep 2008 15:30:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Ki9qk-0002DO-GL for w3c-dist-auth@listhub.w3.org; Tue, 23 Sep 2008 15:30:50 +0000 Received: from daboo.name ([151.201.22.177]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Ki9qX-0002xo-Sa for w3c-dist-auth@w3.org; Tue, 23 Sep 2008 15:30:49 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 68578D137C4; Tue, 23 Sep 2008 11:30:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsQStBnO2n8L; Tue, 23 Sep 2008 11:30:01 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 7E333D137B4; Tue, 23 Sep 2008 11:30:00 -0400 (EDT) Date: Tue, 23 Sep 2008 11:29:57 -0400 From: Cyrus Daboo To: Julian Reschke cc: WebDAV Message-ID: In-Reply-To: <48D906BC.1050003@gmx.de> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> <48D906BC.1050003@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1Ki9qX-0002xo-Sa d2e01bc18a0fb117885915159c0e0e70 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 23 Sep 2008 15:30:53 +0000 Hi Julian, --On September 23, 2008 5:09:48 PM +0200 Julian Reschke wrote: >> One thing this reminds me of: another reason why this POST may be needed >> is if the server enforces a particular naming scheme on members. e.g., a >> CalDAV server may require that all member path segments match the UID in >> the calendar data, or match a record-id in its data store etc. In this >> case the add-member behavior is required. So its not just the case of >> "the client doesn't care to name members itself", but also this other >> one. Probably worth adding a comment on this. >> ... > > Well, if the server enforces a particular naming scheme, and does not > support POST, then the client will need out-of-band information about the > naming scheme, right? How would that work in practice? > > I think what's more common is that the server would *like* to enforce a > naming scheme, but can't, as clients assume PUT will just work. Isn't > that the situation for many CalDAV servers? Yes. > What I've added is > ( issue.member-uri-content>): > > "As a matter of fact, letting the server choose the member URI not only > is a simplification for certain types of clients, but can also reduce the > complexity of the server (in that it doesn't need to persist an > additional client-supplied identifier where the it already has an ^^^ remove "the" > internal one like a UUID or a primary key)." > > That said, I think I'm ready to submit a new draft soon; comments on > > appreciated. So one option for the server to enforce its naming scheme would be to require POST by the client to create new resources rather than allowing PUT/COPY/MOVE to do so. However there is no way fort a client to discover that such a restriction might be in place other than getting a 403. How about a new pre-condition code for that so that the server can indicate "DAV:only-post-allowed-to-create-new-members" to the client? With perhaps a more compact name! This brings up another question: presumably the DAV:bind privilege is required on the collection for the new POST ;add-member behavior to be allowed (just as it would be required for PUT creating a new member). I think we therefore need a statement in Security Considerations: "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is required to be granted on the collection resource in which the new member resource is being created. If this privilege is denied or not present, the POST request MUST fail." Another question: there is no restriction on what p:add-member URI can be? e.g. if I have the collection "/a/b/" can the p:add-member be another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is possible it should be called out, as the behavior might be somewhat unexpected for clients. It might even be the case that the p:add-member URI is on a different server (e.g. new member items in a collection need "approval" from some other service). The interaction with WebDAV ACL in this case would need to be clear - i.e. what privileges are required on the p:add-member URI? -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Tue Sep 23 08:47:52 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179F83A6A12 for ; Tue, 23 Sep 2008 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Fa-WN1uk6S for ; Tue, 23 Sep 2008 08:47:51 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id E16183A67D7 for ; Tue, 23 Sep 2008 08:47:50 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KiA6V-0001IL-Fs for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Sep 2008 15:47:07 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiA6U-0001Hh-8h for w3c-dist-auth@listhub.w3.org; Tue, 23 Sep 2008 15:47:06 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KiA6L-0001Qr-Jg for w3c-dist-auth@w3.org; Tue, 23 Sep 2008 11:47:06 -0400 Received: (qmail invoked by alias); 23 Sep 2008 15:46:25 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 23 Sep 2008 17:46:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Ics0LJHhIiipyive5eGz9WcLECOoQWuFfgcCHgk kZbOxXiqt2EFtf Message-ID: <48D90F44.8030303@gmx.de> Date: Tue, 23 Sep 2008 17:46:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> <48D906BC.1050003@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1KiA6L-0001Qr-Jg a2f5360e9033299002a4548d8b03536c X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 23 Sep 2008 15:47:07 +0000 Cyrus Daboo wrote: > ... >> "As a matter of fact, letting the server choose the member URI not only >> is a simplification for certain types of clients, but can also reduce the >> complexity of the server (in that it doesn't need to persist an >> additional client-supplied identifier where the it already has an > > ^^^ remove "the" Fixed (thanks!). >> internal one like a UUID or a primary key)." >> >> That said, I think I'm ready to submit a new draft soon; comments on >> >> appreciated. > > So one option for the server to enforce its naming scheme would be to > require POST by the client to create new resources rather than allowing > PUT/COPY/MOVE to do so. However there is no way fort a client to > discover that such a restriction might be in place other than getting a > 403. How about a new pre-condition code for that so that the server can > indicate "DAV:only-post-allowed-to-create-new-members" to the client? > With perhaps a more compact name! Actually, it would be discoverable through OPTIONS. When /collection does not allow PUT to add new members, an OPTIONS request on /collection/a should not return "PUT" in the Allow header. That being said, stating that these kinds of collections could exist, and defining a precondition name certainly is a good idea. > This brings up another question: presumably the DAV:bind privilege is > required on the collection for the new POST ;add-member behavior to be > allowed (just as it would be required for PUT creating a new member). I > think we therefore need a statement in Security Considerations: > > "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is > required to be granted on the collection resource in which the new > member resource is being created. If this privilege is denied or not > present, the POST request MUST fail." Yes, although I'd move that into a "Relation to WebDAV ACL" section. > Another question: there is no restriction on what p:add-member URI can > be? e.g. if I have the collection "/a/b/" can the p:add-member be > another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is I thought that was already clear; maybe I should have chosen a different URI :-) > possible it should be called out, as the behavior might be somewhat > unexpected for clients. It might even be the case that the p:add-member > URI is on a different server (e.g. new member items in a collection need > "approval" from some other service). The interaction with WebDAV ACL in It seems that that kind of redirection would need a different mechanism. Let's not make things more complicated than they need to be. > this case would need to be clear - i.e. what privileges are required on > the p:add-member URI? I think it would be sufficient to state the ACL requirements in terms of DAV:bind on the "real" collection. The add-member URI in general could me a non-WebDAV resource, so talking about WebDAV ACLs really doesn't make sense here. BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Sep 23 09:06:05 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372273A6A2D for ; Tue, 23 Sep 2008 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7MrnHRqXv-P for ; Tue, 23 Sep 2008 09:06:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 058FE3A6A12 for ; Tue, 23 Sep 2008 09:06:03 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KiAOI-0007mx-39 for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Sep 2008 16:05:30 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiAOH-0007mE-CR for w3c-dist-auth@listhub.w3.org; Tue, 23 Sep 2008 16:05:29 +0000 Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiAO7-0003Lo-Hl for w3c-dist-auth@w3.org; Tue, 23 Sep 2008 12:05:29 -0400 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7ED4ED13B01; Tue, 23 Sep 2008 12:04:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnLm7JMP-X5d; Tue, 23 Sep 2008 12:04:53 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 40853D13AFA; Tue, 23 Sep 2008 12:04:50 -0400 (EDT) Date: Tue, 23 Sep 2008 12:04:47 -0400 From: Cyrus Daboo To: Julian Reschke cc: WebDAV Message-ID: <2B6F8082F373FB7970C74E05@caldav.corp.apple.com> In-Reply-To: <48D90F44.8030303@gmx.de> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> <48D906BC.1050003@gmx.de> <48D90F44.8030303@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1KiAO7-0003Lo-Hl 1c501bc08d018fe15623c4d407b7e212 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 23 Sep 2008 16:05:30 +0000 Hi Julian, --On September 23, 2008 5:46:12 PM +0200 Julian Reschke wrote: >> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is >> required to be granted on the collection resource in which the new >> member resource is being created. If this privilege is denied or not >> present, the POST request MUST fail." > > Yes, although I'd move that into a "Relation to WebDAV ACL" section. > >> Another question: there is no restriction on what p:add-member URI can >> be? e.g. if I have the collection "/a/b/" can the p:add-member be >> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is > > I thought that was already clear; maybe I should have chosen a different > URI :-) A couple of different examples would help make it clear. >> possible it should be called out, as the behavior might be somewhat >> unexpected for clients. It might even be the case that the p:add-member >> URI is on a different server (e.g. new member items in a collection need >> "approval" from some other service). The interaction with WebDAV ACL in > > It seems that that kind of redirection would need a different mechanism. > Let's not make things more complicated than they need to be. OK, then let's explicitly state that the add-member URI must not be on a different server. >> this case would need to be clear - i.e. what privileges are required on >> the p:add-member URI? > > I think it would be sufficient to state the ACL requirements in terms of > DAV:bind on the "real" collection. The add-member URI in general could me > a non-WebDAV resource, so talking about WebDAV ACLs really doesn't make > sense here. OK, makes sense. -- Cyrus Daboo From w3c-dist-auth-request@listhub.w3.org Wed Sep 24 07:54:39 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254CC3A6D3A for ; Wed, 24 Sep 2008 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBXFz56w4Vrv for ; Wed, 24 Sep 2008 07:54:34 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 4822228C359 for ; Wed, 24 Sep 2008 07:53:33 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KiVj3-0005XS-KM for w3c-dist-auth-dist@listhub.w3.org; Wed, 24 Sep 2008 14:52:21 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiVj2-0005Vw-3k for w3c-dist-auth@listhub.w3.org; Wed, 24 Sep 2008 14:52:20 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KiVit-0002Dn-3a for w3c-dist-auth@w3.org; Wed, 24 Sep 2008 10:52:20 -0400 Received: (qmail invoked by alias); 24 Sep 2008 14:51:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 24 Sep 2008 16:51:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18fgIB+oR8fgJeIQ7WGB+D+WD6MDAbZwwPVLE+swU 6WV+uDYzxKVHy7 Message-ID: <48DA53F6.5020808@gmx.de> Date: Wed, 24 Sep 2008 16:51:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: WebDAV , "'www-webdav-dasl@w3.org'" References: <20080924141844.283BD28C285@core3.amsl.com> In-Reply-To: <20080924141844.283BD28C285@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1KiVit-0002Dn-3a 8fbd85048cfbc6f9ec88cd0432fe9e4e X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV SEARCH approved as Proposed Standard, was: Protocol Action: 'Web Distributed Authoring and Versioning (WebDAV) SEARCH' to Proposed Standard Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Wed, 24 Sep 2008 14:52:21 +0000 (FYI) The IESG wrote: > The IESG has approved the following document: > > - 'Web Distributed Authoring and Versioning (WebDAV) SEARCH ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Chris Newman. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-18.txt > > Technical Summary > > This document specifies a set of methods, headers and properties > composing WebDAV SEARCH, an application of the HTTP/1.1 protocol > to efficiently search for DAV resources based upon a set of > client-supplied criteria. > > Working Group Summary > > This was the product of an individual submittor. However, it is > based on a draft developed by the concluded DASL WG and technical > discussions have occured on the DASL mailing list. Some issues that > were discussed as candidates for the base specification are covered > in Appendix B and are believed suitable for future protocol > extensions. There was some discussion of whether query schema > discovery should be mandatory or optional, there is believed to be > community rough consensus to keep it an optional feature. > > Document Quality > > The framework defined in SEARCH (method, grammar discover via > OPTIONS, response format) is supported at least in six > implementations of which four support the DAV:basicsearch grammar and > the other two expose only custom grammars. There has been at least > one proposal for an additional documented query language > (draft-godoy-webdav-xmlsearch). > > Personnel > > The responsible area director is Chris Newman who reviewed this > specification in detail. The specification was also reviewed by > multiple participants of the www-webdav-dasl@w3.org mailing list > (formerly used by the DASL WG) as well as the w3c-dist-auth@w3.org > (formerly WebDAV WG). During IETF last call, support was > expressed by Tobias Schlauch and Javier Godoy on the IETF list. > Additional review comments were provided by John Barone and Cyrus > Daboo on the webdav lists during last call. Gonzalo Camarillo > was the GEN-ART reviewer, Radia Perlman was the sec-dir reviewer. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From w3c-dist-auth-request@listhub.w3.org Fri Sep 26 05:47:25 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350013A67D1 for ; Fri, 26 Sep 2008 05:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.062 X-Spam-Level: X-Spam-Status: No, score=-9.062 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZJX9bpIW6cM for ; Fri, 26 Sep 2008 05:47:19 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6E8E83A690A for ; Fri, 26 Sep 2008 05:47:18 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KjChK-0000It-Ka for w3c-dist-auth-dist@listhub.w3.org; Fri, 26 Sep 2008 12:45:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KjChH-00007e-BF for w3c-dist-auth@listhub.w3.org; Fri, 26 Sep 2008 12:45:23 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KjCh8-0001wX-L4 for w3c-dist-auth@w3.org; Fri, 26 Sep 2008 12:45:22 +0000 Received: (qmail invoked by alias); 26 Sep 2008 12:44:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 26 Sep 2008 14:44:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+A0KltlhKA7Hz4Ns/8lokmUvxq7Efqym/d21bDTc z/ydDfNNqW0zzX Message-ID: <48DCD937.8070109@gmx.de> Date: Fri, 26 Sep 2008 14:44:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1KjCh8-0001wX-L4 7fb2ff2521925c4dd4c9791643941136 X-Original-To: w3c-dist-auth@w3.org Subject: BIND and HTTP status codes Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 26 Sep 2008 12:45:26 +0000 Hi, while implementing WebDAV BIND in Jackrabbit [1] (the Apache Java Content Repository Reference Implementation), my colleague Manfred Baedke noticed that the spec currently micro-manages HTTP status codes: for instance, for a successful BIND it requires status codes of 200 or 201, while - from an HTTP point of view - a 204 should be acceptable as well. Proposal: rephrase the text so that other success codes are acceptable as well, or remove the normative language completely, point to RFC2616, and rely on examples. BR, Julian [1] From w3c-dist-auth-request@listhub.w3.org Mon Sep 29 06:49:38 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6663A687B for ; Mon, 29 Sep 2008 06:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.969 X-Spam-Level: X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[AWL=1.630, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk2TNBDEZU3T for ; Mon, 29 Sep 2008 06:49:37 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id ACDEC3A67EA for ; Mon, 29 Sep 2008 06:49:37 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KkJ5s-0006w2-8p for w3c-dist-auth-dist@listhub.w3.org; Mon, 29 Sep 2008 13:47:20 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KkJ5q-0006ul-Nr for w3c-dist-auth@listhub.w3.org; Mon, 29 Sep 2008 13:47:18 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KkJ5g-0004b1-Hd for w3c-dist-auth@w3.org; Mon, 29 Sep 2008 09:47:18 -0400 Received: (qmail invoked by alias); 29 Sep 2008 13:46:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp055) with SMTP; 29 Sep 2008 15:46:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18HKQpUS+4H2aRDfgQUZSa4SIN+1//xTktDQFsTsY RuNnIUxiiCGFJj Message-ID: <48E0DC3B.7080508@gmx.de> Date: Mon, 29 Sep 2008 15:46:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: WebDAV References: <48DCD937.8070109@gmx.de> In-Reply-To: <48DCD937.8070109@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1KkJ5g-0004b1-Hd 6bdfbf582f5d54adda1cbc7853ab7b6c X-Original-To: w3c-dist-auth@w3.org Subject: WebDAV BIND support in Apache Jackrabbit, was: BIND and HTTP status codes Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 29 Sep 2008 13:47:20 +0000 Hi, the BIND extensions to Apache Jackrabbit () that I mentioned earlier are now available in the svn trunk (). Implementation restrictions: - Jackrabbit does not allow bind cycles, so none of the functionality around status code 208 is implemented, - In some cases, status 204 is returned instead of 200 (see discussion below) - Jackrabbit does not allow two bindings to the same node within the same parent (will have to figure out why that is) (thanks to Manfred Baedke for the implementation!) BR, Julian Julian Reschke wrote: > > Hi, > > while implementing WebDAV BIND in Jackrabbit [1] (the Apache Java > Content Repository Reference Implementation), my colleague Manfred > Baedke noticed that the spec currently micro-manages HTTP status codes: > for instance, for a successful BIND it requires status codes of 200 or > 201, while - from an HTTP point of view - a 204 should be acceptable as > well. > > Proposal: rephrase the text so that other success codes are acceptable > as well, or remove the normative language completely, point to RFC2616, > and rely on examples. > > BR, Julian > > [1] From w3c-dist-auth-request@listhub.w3.org Tue Sep 30 09:59:49 2008 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01D83A6A17 for ; Tue, 30 Sep 2008 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.817 X-Spam-Level: X-Spam-Status: No, score=-8.817 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfmcCPrLywV0 for ; Tue, 30 Sep 2008 09:59:46 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id DDCDE3A69F2 for ; Tue, 30 Sep 2008 09:59:45 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KkiYP-0003Qc-Rz for w3c-dist-auth-dist@listhub.w3.org; Tue, 30 Sep 2008 16:58:29 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KkiYO-0003PN-Bq for w3c-dist-auth@listhub.w3.org; Tue, 30 Sep 2008 16:58:28 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KkiYF-0005ZW-IS for w3c-dist-auth@w3.org; Tue, 30 Sep 2008 12:58:28 -0400 Received: (qmail invoked by alias); 30 Sep 2008 16:57:47 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp050) with SMTP; 30 Sep 2008 18:57:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19rg5QnJkBrH3Tz9v1Alq1vhkekkf9gr63kyp5B8r LYYMKITe5qKpQQ Message-ID: <48E25A89.9070803@gmx.de> Date: Tue, 30 Sep 2008 18:57:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <471672D975269B091322772E@caldav.corp.apple.com> <48D7D3A2.7010009@gmx.de> <4E4C3FE927A3FC9425AABAB9@caldav.corp.apple.com> <48D906BC.1050003@gmx.de> <48D90F44.8030303@gmx.de> <2B6F8082F373FB7970C74E05@caldav.corp.apple.com> In-Reply-To: <2B6F8082F373FB7970C74E05@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1KkiYF-0005ZW-IS 40b6175f476b8d6d6bd3961178631e74 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 30 Sep 2008 16:58:29 +0000 Cyrus Daboo wrote: > > Hi Julian, > > --On September 23, 2008 5:46:12 PM +0200 Julian Reschke > wrote: > >>> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is >>> required to be granted on the collection resource in which the new >>> member resource is being created. If this privilege is denied or not >>> present, the POST request MUST fail." >> >> Yes, although I'd move that into a "Relation to WebDAV ACL" section. >> >>> Another question: there is no restriction on what p:add-member URI can >>> be? e.g. if I have the collection "/a/b/" can the p:add-member be >>> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is >> >> I thought that was already clear; maybe I should have chosen a different >> URI :-) > > A couple of different examples would help make it clear. : Note: the "Add-Member" URI can be the identical to the collection's URI (in which case the server just advertises the fact that POST to the WebDAV collection's URI is supported as defined within this specification). But it can also be different from it, in which case it doesn't need to have any relation to the collection's URI. Given a collection URI of /docs/collection/ all of the following URIs might occur as "Add-Member" URIs: /docs/collection/ /docs/collection/;post /docs/collection;post/ /docs/collection/&post /post-service?path=/collection/ The remainder of the document uses the same format just for reasons of consistency; any other HTTP URI would do as well. > ... >> It seems that that kind of redirection would need a different mechanism. >> Let's not make things more complicated than they need to be. > > OK, then let's explicitly state that the add-member URI must not be on a > different server. Speaking of which, it could also be considered a security problem (the ability of server A to cause clients to post to server B != A). > ... BR, Julian