From w3c-dist-auth-request@listhub.w3.org Wed Oct 1 07:48:07 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 D73F028C1B1 for ; Wed, 1 Oct 2008 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.916 X-Spam-Level: X-Spam-Status: No, score=-8.916 tagged_above=-999 required=5 tests=[AWL=1.083, 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 tQTx1ffnwHHG for ; Wed, 1 Oct 2008 07:48:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id DE82028C0FA for ; Wed, 1 Oct 2008 07:47:54 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kl2xk-0007vY-9Y for w3c-dist-auth-dist@listhub.w3.org; Wed, 01 Oct 2008 14:46:00 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kl2xj-0007uu-9R for w3c-dist-auth@listhub.w3.org; Wed, 01 Oct 2008 14:45:59 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Kl2xX-00079k-74 for w3c-dist-auth@w3.org; Wed, 01 Oct 2008 10:45:59 -0400 Received: (qmail invoked by alias); 01 Oct 2008 14:45:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 01 Oct 2008 16:45:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/+VZMvVin+oarSGTozByJTehBSfR+mLnxV+gskJJ nfiMaTCtVREHId Message-ID: <48E38CF7.3040303@gmx.de> Date: Wed, 01 Oct 2008 16:45:11 +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> <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.55 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 1Kl2xX-00079k-74 44afc1097f152610a53fd95ec079cf02 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/13019 X-Loop: w3c-dist-auth@w3.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, 01 Oct 2008 14:46:00 +0000 Ok, I have a new version ready that (hopefully) addresses all points that have been raised so far. See BR, Julian (planning to submit it tomorrow as -01) 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. > >>> 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. > From w3c-dist-auth-request@listhub.w3.org Thu Oct 2 05:16:40 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 AD6A83A6B51 for ; Thu, 2 Oct 2008 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.543 X-Spam-Level: X-Spam-Status: No, score=-9.543 tagged_above=-999 required=5 tests=[AWL=1.056, 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 p7JG5IZu2E7u for ; Thu, 2 Oct 2008 05:16:39 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id CA73A3A6933 for ; Thu, 2 Oct 2008 05:16:39 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KlN4N-0004gg-Gw for w3c-dist-auth-dist@listhub.w3.org; Thu, 02 Oct 2008 12:14:11 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KlN4M-0004g2-Ek for w3c-dist-auth@listhub.w3.org; Thu, 02 Oct 2008 12:14:10 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KlN4D-00021W-KD for w3c-dist-auth@w3.org; Thu, 02 Oct 2008 08:14:10 -0400 Received: (qmail invoked by alias); 02 Oct 2008 12:13:29 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 02 Oct 2008 14:13:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/EOc44nGrE7ccObO1FQrw+EBqzi0XUpRCOa22Dbz 2o5lyf5mM+kawb Message-ID: <48E4BAE6.1040102@gmx.de> Date: Thu, 02 Oct 2008 14:13:26 +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: <20081002100001.CAD2B3A6C22@core3.amsl.com> In-Reply-To: <20081002100001.CAD2B3A6C22@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.57 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-0.7 X-W3C-Hub-Spam-Report: BAYES_20=-0.74, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1KlN4D-00021W-KD e405d5a00979a7f97b21d2e974de0b5c X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-reschke-webdav-post-01.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13020 X-Loop: w3c-dist-auth@w3.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, 02 Oct 2008 12:14:11 +0000 (FYI) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections > Author(s) : J. Reschke > Filename : draft-reschke-webdav-post-01.txt > Pages : 19 > Date : 2008-10-02 > > 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-01.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 Fri Oct 3 09:04:47 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 6793528C223 for ; Fri, 3 Oct 2008 09:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.832 X-Spam-Level: X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=2.767, 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 H7K+gKeNbBKs for ; Fri, 3 Oct 2008 09:04:46 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6ADD63A69AC for ; Fri, 3 Oct 2008 09:04:46 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kllzk-0004aV-6u for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Oct 2008 14:51:04 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kllzj-0004Zr-BI for w3c-dist-auth@listhub.w3.org; Fri, 03 Oct 2008 14:51:03 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Kllza-0000UM-5M for w3c-dist-auth@w3.org; Fri, 03 Oct 2008 10:51:03 -0400 Received: (qmail invoked by alias); 03 Oct 2008 14:50:22 -0000 Received: from p508FBE11.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.190.17] by mail.gmx.net (mp055) with SMTP; 03 Oct 2008 16:50:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Y3TtJZbVYQf7lOAkxs+RdPPuTvUnduCZkGdTxq5 kafv1BelKD/wzj Message-ID: <48E63129.8010708@gmx.de> Date: Fri, 03 Oct 2008 16:50:17 +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 CC: w3c-dist-auth@w3.org References: <20081003141502.01A1E3A683C@core3.amsl.com> In-Reply-To: <20081003141502.01A1E3A683C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Kllza-0000UM-5M 4dc54e7d67f80e7f2e0a3182307c730a X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-ietf-webdav-bind-21.txt Archived-At: To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13021 X-Loop: w3c-dist-auth@w3.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, 03 Oct 2008 14:51:04 +0000 (FYI) This draft contains just the editorial changes made since November 2007. I also added the two issues that I'd like to see resolved before we start a new attempt of publishing: 1) Micromanagement of status codes (, raises last week), and 2) Relation to DeltaV (, raised in August by Werner Donné). BR, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. > > > Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) > Author(s) : G. Clemm, et al. > Filename : draft-ietf-webdav-bind-21.txt > Pages : 46 > Date : 2008-10-03 > > This specification defines bindings, and the BIND method for creating > multiple bindings to the same resource. Creating a new binding to a > resource causes at least one new URI to be mapped to that resource. > Servers are required to insure the integrity of any bindings that > they allow to be created.Editorial Note (To be removed by RFC Editor > before publication) > > Please send comments to the Distributed Authoring and Versioning > (WebDAV) working group at , which may be > joined by sending a message with subject "subscribe" to > . Discussions of the WEBDAV > working group are archived at > . > > lists > all registered issues since draft 02. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-21.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 Sat Oct 4 10:06:07 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 5B50E3A6A03 for ; Sat, 4 Oct 2008 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.227 X-Spam-Level: X-Spam-Status: No, score=-8.227 tagged_above=-999 required=5 tests=[AWL=2.372, 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 FvHezVxZXdYI for ; Sat, 4 Oct 2008 10:06:06 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 45CDC3A6898 for ; Sat, 4 Oct 2008 10:06:06 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KmAXl-0000rT-RB for w3c-dist-auth-dist@listhub.w3.org; Sat, 04 Oct 2008 17:03:49 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KmAXk-0000qk-H2 for w3c-dist-auth@listhub.w3.org; Sat, 04 Oct 2008 17:03:48 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KmAXX-00084k-LA for w3c-dist-auth@w3.org; Sat, 04 Oct 2008 13:03:48 -0400 Received: (qmail invoked by alias); 04 Oct 2008 17:03:01 -0000 Received: from p508FED21.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.237.33] by mail.gmx.net (mp032) with SMTP; 04 Oct 2008 19:03:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/HXosUKDTHyqUdwGVYZB6MhW6Xn2P2LA1HAXfl0r hAmpY0riwq7AF7 Message-ID: <48E7A1B9.6000402@gmx.de> Date: Sat, 04 Oct 2008 19:02:49 +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: Geoffrey M Clemm CC: =?ISO-8859-1?Q?Werner_Donn=E9?= , w3c-dist-auth@w3.org References: <48B6AD77.5060008@gmx.de> In-Reply-To: <48B6AD77.5060008@gmx.de> 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 1KmAXX-00084k-LA fb89cb77c263b6e9f485d6a9b4ec4717 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13022 X-Loop: w3c-dist-auth@w3.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: Sat, 04 Oct 2008 17:03:49 +0000 OK, proposed text (see also ): 10. Relationship to Versioning Extensions to WebDAV Servers that implement Version Controlled Collections as defined in Section 14 of [RFC3253] already need to implement BIND-like behaviour in order to handle UPDATE and UNCHECKOUT semantics. Consider the version-controlled, checked-out collections C1 and C2, named "/CollX" and "/CollY", and a version-controlled resource R, bound to C1 as "/CollX/test": +-------------------------+ | Root Collection | | bindings: | | CollX CollY | +-------------------------+ | | | | | | +---------------+ +---------------+ | Collection C1 | | Collection C2 | | bindings: | | | | test | | | +---------------+ +---------------+ | | | +------------------+ | Resource R | +------------------+ Moving "/CollX/test" into "/CollY", checking in C2, but undoing the checkout on C1 will undo part of the MOVE request, thus restoring the binding from C1 to R, but keeping the new binding from C2 to R: >> Request: MOVE /CollX/test HTTP/1.1 Host: www.example.com Destination: /CollY/test >> Response: HTTP/1.1 204 No Content >> Request: CHECKIN /CollY/ HTTP/1.1 Host: www.example.com >> Response: HTTP/1.1 201 Created Cache-Control: no-cache Location: http://repo.example.com/his/17/ver/42 >> Request: UNCHECKOUT /CollX/ HTTP/1.1 Host: www.example.com >> Response: HTTP/1.1 200 OK Cache-Control: no-cache As a result, both C1 and C2 would have a binding to R: +-------------------------+ | Root Collection | | bindings: | | CollX CollY | +-------------------------+ | | | | | | +---------------+ +---------------+ | Collection C1 | | Collection C2 | | bindings: | | bindings: | | test | | test | +---------------+ +---------------+ | | | | | | +------------------+ | Resource R | +------------------+ The MOVE semantics defined in Section 3.15 of [RFC3253] already require that "/CollX/test" and "/CollY/test" will have the same version history (as exposed in the DAV:version-history property). Furthermore, the UNCHECKOUT semantics (which in this case is similar to UPDATE, see Section 14.11 of [RFC3253]) require: ...If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource... Thus, "/CollX/test" and "/CollY/test" will be bindings to the same resource R, and have identical DAV:resource-id properties. ...feedback appreciated. BR, Julian From w3c-dist-auth-request@listhub.w3.org Sun Oct 5 11:14:37 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 90CB93A6998 for ; Sun, 5 Oct 2008 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.606 X-Spam-Level: X-Spam-Status: No, score=-7.606 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, DNS_FROM_DOB=0.732, RCVD_IN_DNSWL_HI=-8, RCVD_IN_DOB=1.103] 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 pkDJeZj1zb21 for ; Sun, 5 Oct 2008 11:14:36 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 77FE63A6997 for ; Sun, 5 Oct 2008 11:14:36 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KmY61-0005bo-73 for w3c-dist-auth-dist@listhub.w3.org; Sun, 05 Oct 2008 18:12:45 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KmY60-0005aT-8B for w3c-dist-auth@listhub.w3.org; Sun, 05 Oct 2008 18:12:44 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KmY5r-0008Q5-G8 for w3c-dist-auth@w3.org; Sun, 05 Oct 2008 14:12:44 -0400 Received: (qmail invoked by alias); 05 Oct 2008 18:12:03 -0000 Received: from p508FDC40.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.220.64] by mail.gmx.net (mp030) with SMTP; 05 Oct 2008 20:12:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19zHVEDLgxzgcB+J702j3dijC1xtqbMUMJYvB/pl6 MQu2YjpBUSRt6a Message-ID: <48E9036C.6060208@gmx.de> Date: Sun, 05 Oct 2008 20:11:56 +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.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 1KmY5r-0008Q5-G8 824e4b4cc84248fa1de513926dafc474 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and HTTP status codes Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13023 X-Loop: w3c-dist-auth@w3.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: Sun, 05 Oct 2008 18:12:45 +0000 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] Proposed resolution, deliberately kept simple in order not to make bigger changes at this stage: Section 4., paragraph 9: OLD: If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) when an existing binding was replaced. NEW: If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced. Section 5., paragraph 6: OLD: If the request succeeds, the server MUST return 200 (OK) when the binding was successfully deleted. NEW: If the request succeeds, the server MUST return 200 (OK) or 204 (No Content) when the binding was successfully deleted. Section 6., paragraph 7: OLD: If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) when an existing binding was replaced. NEW: If the request succeeds, the server MUST return 201 (Created) when a new binding was created and 200 (OK) or 204 (No Content) when an existing binding was replaced. See also . Note that I also added a Location header to the one example where a 201 status is returned; this may be a good idea as the newly created URI != the request-URL (but I wouldn't want to normatively require it). BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 05:26:50 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 EB6C328C0FD for ; Tue, 7 Oct 2008 05:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.279 X-Spam-Level: X-Spam-Status: No, score=-9.279 tagged_above=-999 required=5 tests=[AWL=1.320, 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 8x0RJfjVdQAt for ; Tue, 7 Oct 2008 05:26:45 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 561423A689A for ; Tue, 7 Oct 2008 05:26:44 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnBcN-00079U-Fr for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 12:24:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnBcL-00078j-Vc for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 12:24:46 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KnBcC-0005eo-TV for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 12:24:45 +0000 Received: (qmail invoked by alias); 07 Oct 2008 12:24:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp041) with SMTP; 07 Oct 2008 14:24:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Qd/FiyFmQ+6sl0Dqfcth9CFyvxHrPQ0YEQglIyn CLtLW9NeljSSRr Message-ID: <48EB54E3.4000509@gmx.de> Date: Tue, 07 Oct 2008 14:24:03 +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: Geoffrey M Clemm CC: =?ISO-8859-1?Q?Werner_Donn=E9?= , w3c-dist-auth@w3.org References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> In-Reply-To: <48E7A1B9.6000402@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 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 1KnBcC-0005eo-TV 61e0daa4fde073aaf2386dd26bd3a147 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13024 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 12:24:47 +0000 Julian Reschke wrote: > > OK, > > proposed text (see also > ): ...in the meantime I realized that this is only true if it happens inside a workspace. New version (changing the intro and the paths): 10. Relationship to Versioning Extensions to WebDAV Servers that implement Workspaces ([RFC3253], Section 6) and Version Controlled Collections ([RFC3253], Section 14) already need to implement BIND-like behaviour in order to handle UPDATE and UNCHECKOUT semantics. Consider a workspace "/ws1/", containing the version-controlled, checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ CollY", and a version-controlled resource R, bound to C1 as "/ws1/ CollX/test": +-------------------------+ | Workspace | | bindings: | | CollX CollY | +-------------------------+ | | | | | | +---------------+ +---------------+ | Collection C1 | | Collection C2 | | bindings: | | | | test | | | +---------------+ +---------------+ | | | +------------------+ | Resource R | +------------------+ Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but undoing the checkout on C1 will undo part of the MOVE request, thus restoring the binding from C1 to R, but keeping the new binding from C2 to R: >> Request: MOVE /ws1/CollX/test HTTP/1.1 Host: www.example.com Destination: /ws1/CollY/test >> Response: HTTP/1.1 204 No Content >> Request: CHECKIN /ws1/CollY/ HTTP/1.1 Host: www.example.com >> Response: HTTP/1.1 201 Created Cache-Control: no-cache Location: http://repo.example.com/his/17/ver/42 >> Request: UNCHECKOUT /ws1/CollX/ HTTP/1.1 Host: www.example.com >> Response: HTTP/1.1 200 OK Cache-Control: no-cache As a result, both C1 and C2 would have a binding to R: +-------------------------+ | Workspace | | bindings: | | CollX CollY | +-------------------------+ | | | | | | +---------------+ +---------------+ | Collection C1 | | Collection C2 | | bindings: | | bindings: | | test | | test | +---------------+ +---------------+ | | | | | | +------------------+ | Resource R | +------------------+ The MOVE semantics defined in Section 3.15 of [RFC3253] already require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the same version history (as exposed in the DAV:version-history property). Furthermore, the UNCHECKOUT semantics (which in this case is similar to UPDATE, see Section 14.11 of [RFC3253]) require: ...If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource... Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to the same resource R, and have identical DAV:resource-id properties. BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 05:35:16 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 116E328C164 for ; Tue, 7 Oct 2008 05:35:16 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 a3ikSHAwBCtI for ; Tue, 7 Oct 2008 05:35:14 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B0DF928C169 for ; Tue, 7 Oct 2008 05:35:14 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnBmb-000612-B7 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 12:35:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnBma-00060O-79 for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 12:35:20 +0000 Received: from winston.telenet-ops.be ([195.130.137.75]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnBmR-0006rE-3v for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 12:35:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by winston.telenet-ops.be (Postfix) with SMTP id 6AC0EA0031; Tue, 7 Oct 2008 14:34:45 +0200 (CEST) Received: from [192.168.0.109] (d54C2DE4F.access.telenet.be [84.194.222.79]) by winston.telenet-ops.be (Postfix) with ESMTP id 956E0A0055; Tue, 7 Oct 2008 14:34:44 +0200 (CEST) From: =?ISO-8859-1?Q?Werner_Donn=E9?= To: Julian Reschke In-Reply-To: <48EB54E3.4000509@gmx.de> References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> Message-Id: <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 14:34:43 +0200 Cc: Geoffrey M Clemm , w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.929.2) Received-SPF: none X-SPF-Guess: neutral 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 1KnBmR-0006rE-3v 99df3bbbee38de5aa115b06c3c013bcb X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13025 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 12:35:21 +0000 Hi Julian, Why is it only valid inside a workspace? Best regards, Werner. On 07 Oct 2008, at 14:24, Julian Reschke wrote: > Julian Reschke wrote: >> OK, >> proposed text (see also = > >): > > ...in the meantime I realized that this is only true if it happens =20 > inside a workspace. New version (changing the intro and the paths): > > 10. Relationship to Versioning Extensions to WebDAV > > Servers that implement Workspaces ([RFC3253], Section 6) and Version > Controlled Collections ([RFC3253], Section 14) already need to > implement BIND-like behaviour in order to handle UPDATE and > UNCHECKOUT semantics. > > Consider a workspace "/ws1/", containing the version-controlled, > checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/ > CollY", and a version-controlled resource R, bound to C1 as "/ws1/ > CollX/test": > > +-------------------------+ > | Workspace | > | bindings: | > | CollX CollY | > +-------------------------+ > | | > | | > | | > +---------------+ +---------------+ > | Collection C1 | | Collection C2 | > | bindings: | | | > | test | | | > +---------------+ +---------------+ > | > | > | > +------------------+ > | Resource R | > +------------------+ > > Moving "/ws1/CollX/test" into "/ws1/CollY", checking in C2, but > undoing the checkout on C1 will undo part of the MOVE request, thus > restoring the binding from C1 to R, but keeping the new binding from > C2 to R: > > >> Request: > > MOVE /ws1/CollX/test HTTP/1.1 > Host: www.example.com > Destination: /ws1/CollY/test > > >> Response: > > HTTP/1.1 204 No Content > > >> Request: > > CHECKIN /ws1/CollY/ HTTP/1.1 > Host: www.example.com > > >> Response: > > HTTP/1.1 201 Created > Cache-Control: no-cache > Location: http://repo.example.com/his/17/ver/42 > > >> Request: > > UNCHECKOUT /ws1/CollX/ HTTP/1.1 > Host: www.example.com > > >> Response: > > HTTP/1.1 200 OK > Cache-Control: no-cache > > As a result, both C1 and C2 would have a binding to R: > > +-------------------------+ > | Workspace | > | bindings: | > | CollX CollY | > +-------------------------+ > | | > | | > | | > +---------------+ +---------------+ > | Collection C1 | | Collection C2 | > | bindings: | | bindings: | > | test | | test | > +---------------+ +---------------+ > | | > | | > | | > +------------------+ > | Resource R | > +------------------+ > > The MOVE semantics defined in Section 3.15 of [RFC3253] already > require that "/ws1/CollX/test" and "/ws1/CollY/test" will have the > same version history (as exposed in the DAV:version-history > property). Furthermore, the UNCHECKOUT semantics (which in this =20 > case > is similar to UPDATE, see Section 14.11 of [RFC3253]) require: > > ...If a new version-controlled member is in a workspace that > already has a version-controlled resource for that version > history, then the new version-controlled member MUST be just a > binding (i.e., another name for) that existing version-controlled > resource... > > Thus, "/ws1/CollX/test" and "/ws1/CollY/test" will be bindings to =20= > the > same resource R, and have identical DAV:resource-id properties. > > BR, Julian -- Werner Donn=E9 -- Re = http://www.pincette.biz Engelbeekstraat 8 = http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 05:46: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 389BD3A6B23 for ; Tue, 7 Oct 2008 05:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.186 X-Spam-Level: X-Spam-Status: No, score=-9.186 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 L5Y2DAtueQPd for ; Tue, 7 Oct 2008 05:46:09 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 332C528C15C for ; Tue, 7 Oct 2008 05:46:09 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnBwz-0003Wg-AC for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 12:46:05 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnBwy-0003W2-Jj for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 12:46:04 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KnBwp-0004Lh-Sv for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 08:46:04 -0400 Received: (qmail invoked by alias); 07 Oct 2008 12:45:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp009) with SMTP; 07 Oct 2008 14:45:23 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Ec6AiXmlEb2fBHwiC8DGZq9fniGW8duZBw9Jvto 3dgjuoifxgrJ+2 Message-ID: <48EB59E0.7000404@gmx.de> Date: Tue, 07 Oct 2008 14:45:20 +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: =?ISO-8859-1?Q?Werner_Donn=E9?= CC: Geoffrey M Clemm , w3c-dist-auth@w3.org References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> In-Reply-To: <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: bart.w3.org 1KnBwp-0004Lh-Sv 58c3c59255b98f2b713a21fe01b64226 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13026 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 12:46:05 +0000 Werner Donné wrote: > > Hi Julian, > > Why is it only valid inside a workspace? > > Best regards, > > Werner. The behavior for UNCHECKOUT on versioned collections isn't described in RFC3253, but the errata list () says: "14_MISSING_ SEMANTICS Editorial Editor The semantics of UNCHECKOUT applied to a version-controlled collection is undefined. Julian Reschke: message Define UNCHECKOUT semantics to be those of doing an UPDATE to the DAV:checked-out version." What's relevant is 14.11 (IMHO), which says: "...If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource. Otherwise, the content and dead properties of the new version-controlled member MUST have been initialized to be those of the version specified for that version history by the request..." So it seems that creating a *different* version controlled resource would be allowed here. BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 06:53:36 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 439EF3A698B for ; Tue, 7 Oct 2008 06:53:36 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 4ypsZTuOa5iA for ; Tue, 7 Oct 2008 06:53:35 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2C0443A6888 for ; Tue, 7 Oct 2008 06:53:35 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnCxY-0003Ye-Gw for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 13:50:44 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnCxX-0003Xy-IW for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 13:50:43 +0000 Received: from monty.telenet-ops.be ([195.130.132.56]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnCxO-00072z-N8 for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 09:50:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by monty.telenet-ops.be (Postfix) with SMTP id D319F54038; Tue, 7 Oct 2008 15:50:07 +0200 (CEST) Received: from [192.168.0.109] (d54C2DE4F.access.telenet.be [84.194.222.79]) by monty.telenet-ops.be (Postfix) with ESMTP id 96D9A5400A; Tue, 7 Oct 2008 15:50:06 +0200 (CEST) From: =?ISO-8859-1?Q?Werner_Donn=E9?= To: Julian Reschke In-Reply-To: <48EB59E0.7000404@gmx.de> References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> <48EB59E0.7000404@gmx.de> Message-Id: <2CD7562A-5959-46C5-BC68-E98D8DF42D6D@re.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 15:50:06 +0200 Cc: Geoffrey M Clemm , w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.929.2) Received-SPF: none X-SPF-Guess: neutral X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1 X-W3C-Scan-Sig: bart.w3.org 1KnCxO-00072z-N8 eb51f149aeebf2284c43e4f117bbba26 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13027 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 13:50:44 +0000 There are indeed no additional semantics for UNCHECKOUT in section 14. Therefore, I think the semantics of section section 4.5 apply, because a version-controlled collection is also a version-controlled resource. Though the introduction of section 14 mentions workspaces, I don't think the merge feature is limited to workspaces. It is allowed to use a version-controlled collection as the request URI and a collection =20 version as the source. If both would be associated with the same version =20 history, for example, it would be strange if in such a case new version-=20 controlled members would be created as described in section 4.11. Werner. On 07 Oct 2008, at 14:45, Julian Reschke wrote: > Werner Donn=E9 wrote: >> Hi Julian, >> Why is it only valid inside a workspace? >> Best regards, >> Werner. > > The behavior for UNCHECKOUT on versioned collections isn't described =20= > in RFC3253, but the errata list = ( >) says: > > "14_MISSING_ SEMANTICS > =09 > Editorial > =09 > Editor > =09 > The semantics of UNCHECKOUT applied to a version-controlled =20 > collection is undefined. > =09 > Julian Reschke: message > =09 > Define UNCHECKOUT semantics to be those of doing an UPDATE to the =20 > DAV:checked-out version." > > > What's relevant is 14.11 (IMHO), which says: > > "...If a new version-controlled member is in a workspace that =20 > already has a version-controlled resource for that version history, =20= > then the new version-controlled member MUST be just a binding (i.e., =20= > another name for) that existing version-controlled resource. =20 > Otherwise, the content and dead properties of the new version-=20 > controlled member MUST have been initialized to be those of the =20 > version specified for that version history by the request..." > > So it seems that creating a *different* version controlled resource =20= > would be allowed here. > > BR, Julian > -- Werner Donn=E9 -- Re = http://www.pincette.biz Engelbeekstraat 8 = http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 07:10: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 C53D53A6873 for ; Tue, 7 Oct 2008 07:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.232 X-Spam-Level: X-Spam-Status: No, score=-9.232 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IzIACi-Yyz-6 for ; Tue, 7 Oct 2008 07:10:37 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 81EE53A6951 for ; Tue, 7 Oct 2008 07:10:37 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnDGQ-0005Wu-5O for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 14:10:14 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnDGP-0005WB-3c for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 14:10:13 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KnDGG-0002EP-Et for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 10:10:13 -0400 Received: (qmail invoked by alias); 07 Oct 2008 14:09:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 07 Oct 2008 16:09:32 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18jT7QkKzcjn8lvLZ2LfSzY5kP7RU3hnxLfWrB+fr yotFyciCpFG7IY Message-ID: <48EB6D99.7090709@gmx.de> Date: Tue, 07 Oct 2008 16:09:29 +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: =?ISO-8859-1?Q?Werner_Donn=E9?= CC: Geoffrey M Clemm , w3c-dist-auth@w3.org References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> <48EB59E0.7000404@gmx.de> <2CD7562A-5959-46C5-BC68-E98D8DF42D6D@re.be> In-Reply-To: <2CD7562A-5959-46C5-BC68-E98D8DF42D6D@re.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 1KnDGG-0002EP-Et 20eeae7dd9662bd4361abd34dfe3c8d3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13028 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 14:10:14 +0000 Werner Donné wrote: > There are indeed no additional semantics for UNCHECKOUT in section 14. Well, we have an erratum for UNCHECKOUT in Section 14, and Geoff has already proposed a resolution; do you disagree with it? > Therefore, I think the semantics of section section 4.5 apply, because > a version-controlled collection is also a version-controlled resource. Yes, those apply; but how exactly do they help clarifying what the server needs to do? > Though the introduction of section 14 mentions workspaces, I don't think > the merge feature is limited to workspaces. It is allowed to use a > version-controlled collection as the request URI and a collection version > as the source. If both would be associated with the same version history, > for example, it would be strange if in such a case new version-controlled > members would be created as described in section 4.11. That's possible (I haven't implemented merge); and maybe that's a separate erratum. Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I think it's sufficient if we describe a case where RFC 3253 *clearly* requires BIND semantics; so is the currently proposed text correct? BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 07:31:30 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 698333A6B83 for ; Tue, 7 Oct 2008 07:31:30 -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 zCXD5j2kV+6Q for ; Tue, 7 Oct 2008 07:31:29 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6F21C3A6B79 for ; Tue, 7 Oct 2008 07:31:29 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnDaT-0007ES-3A for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 14:30:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnDaR-0007Do-Va for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 14:30:56 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnDaJ-000152-8A for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 14:30:55 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m97EUh65023319; Tue, 7 Oct 2008 16:30:43 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m97EUhhp023317; Tue, 7 Oct 2008 16:30:43 +0200 Date: Tue, 7 Oct 2008 16:30:43 +0200 From: Petr Tomasek To: Julian Reschke , WebDAV Message-ID: <20081007143043.GA21699@ebed.etf.cuni.cz> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D7BCFE.40200@gmx.de> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.8.1.34; VDF: 7.0.7.6; host: ebed.etf.cuni.cz) 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 1KnDaJ-000152-8A b962363b7aec1bb0b0c9e249769e3fe5 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/13029 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 14:30:57 +0000 On Mon, Sep 22, 2008 at 05:42:54PM +0200, Julian Reschke wrote: > > FYI -- this is an early draft of what I proposed in July > (). > > Feedback appreciated, > > Julian Hi, I dislike the fact, that a simple task like creating a new resource should constitute complicated metadata creating/parsing. I think a simple method (I would choose another one, not the POST one, but e.g. "CREATE") would be more suitable to the HTTP model. Please, note, not everything on the earth "is WebDAV" and it seems to mee that forcing using XML everywhere, even if it is not necessary is simply an error (it leads to too complicated protocols and too much overhead for implementing them...) Petr Tomasek -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 07:41:24 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 635F63A6AD7 for ; Tue, 7 Oct 2008 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.425 X-Spam-Level: X-Spam-Status: No, score=-9.425 tagged_above=-999 required=5 tests=[AWL=1.174, 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 EK3K1ORFUG0V for ; Tue, 7 Oct 2008 07:41:23 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8E0C13A6B66 for ; Tue, 7 Oct 2008 07:41:23 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnDkX-0002Bi-Lr for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 14:41:21 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnDkW-0002B4-Vq for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 14:41:21 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KnDkN-0007Vz-W7 for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 10:41:20 -0400 Received: (qmail invoked by alias); 07 Oct 2008 14:40:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp057) with SMTP; 07 Oct 2008 16:40:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+gSP5U5y+gNB47iR40TeqqFoRgw12f2nUkyC9RTE yVnZFK5bTre3I+ Message-ID: <48EB74E2.30803@gmx.de> Date: Tue, 07 Oct 2008 16:40: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: Petr Tomasek CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <20081007143043.GA21699@ebed.etf.cuni.cz> In-Reply-To: <20081007143043.GA21699@ebed.etf.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 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 1KnDkN-0007Vz-W7 7f612de2864abf3e14691ef09a3f5d98 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/13030 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 14:41:21 +0000 Petr Tomasek wrote: > On Mon, Sep 22, 2008 at 05:42:54PM +0200, Julian Reschke wrote: >> FYI -- this is an early draft of what I proposed in July >> (). >> >> Feedback appreciated, >> >> Julian > > Hi, > > I dislike the fact, that a simple task like creating a new resource > should constitute complicated metadata creating/parsing. > > I think a simple method (I would choose another one, not the POST > one, but e.g. "CREATE") would be more suitable to the HTTP model. I proposed that one ("ADDMEMBER", see ) over three years ago, and the feedback from the HTTP community I got was: "not needed, just use POST"). The new proposal addresses that feedback -- it makes POST usable for WebDAV collections. > Please, note, not everything on the earth "is WebDAV" and it seems > to mee that forcing using XML everywhere, even if it is not necessary > is simply an error (it leads to too complicated protocols and too > much overhead for implementing them...) This is a proposal specifically for WebDAV. Thus I think it's totally acceptable that the information lives in WebDAV properties. (That being said, I strongly disagree with the assumption that using XML itself is a problem; see for instance AtomPub which uses exactly the same approach) BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 08:18: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 4C91E3A6B6F for ; Tue, 7 Oct 2008 08:18:58 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 EMgI5hozkEig for ; Tue, 7 Oct 2008 08:18:57 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 43EB23A6B2F for ; Tue, 7 Oct 2008 08:18:57 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnEKd-00041D-Q8 for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 15:18:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnEKc-00040P-92 for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 15:18:38 +0000 Received: from nelson.telenet-ops.be ([195.130.133.66]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnEKT-0006OY-Is for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 15:18:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by nelson.telenet-ops.be (Postfix) with SMTP id 1674A50049; Tue, 7 Oct 2008 17:18:04 +0200 (CEST) Received: from [192.168.0.109] (d54C2DE4F.access.telenet.be [84.194.222.79]) by nelson.telenet-ops.be (Postfix) with ESMTP id 754635005F; Tue, 7 Oct 2008 17:18:03 +0200 (CEST) From: =?ISO-8859-1?Q?Werner_Donn=E9?= To: Julian Reschke In-Reply-To: <48EB6D99.7090709@gmx.de> References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> <48EB59E0.7000404@gmx.de> <2CD7562A-5959-46C5-BC68-E98D8DF42D6D@re.be> <48EB6D99.7090709@gmx.de> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 17:18:02 +0200 Cc: Geoffrey M Clemm , w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.929.2) Received-SPF: none X-SPF-Guess: neutral 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 1KnEKT-0006OY-Is 42731a2f458508a181de56bd2e8741b8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13031 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 15:18:39 +0000 On 07 Oct 2008, at 16:09, Julian Reschke wrote: > Werner Donn=E9 wrote: >> There are indeed no additional semantics for UNCHECKOUT in section =20= >> 14. > > Well, we have an erratum for UNCHECKOUT in Section 14, and Geoff has =20= > already proposed a resolution; do you disagree with it? > >> Therefore, I think the semantics of section section 4.5 apply, =20 >> because >> a version-controlled collection is also a version-controlled =20 >> resource. > > Yes, those apply; but how exactly do they help clarifying what the =20 > server needs to do? For me section 4.5 is complete. It says that the pre-CHECKOUT state =20 should be restored. This means that the checked-in version becomes what it was =20 before the CHECKOUT. The version-controlled binding set of that checked-in =20 version must not have changed, because the corresponding property is protected =20= and the DELETE and VERSION-CONTROL methods have the proper pre-conditions to =20 prevent it. In your original message you raise the question about what should =20 happen when a VCR has been deleted since the last check-out. This is not a =20 specific matter for UNCHECKOUT. When a DELETE is performed on a VCR that corresponds =20 to member in a checked out collection, the server is responsible for making sure =20= that the version-controlled binding sets of all versions of that collection =20= are not affected. I don't think section 4.11 can apply to the UNCHECKOUT method, because =20= it says what should happen when the checked-in version of a version-controlled =20= collection is modified. A checked out collection is a checked out resource and =20 those don't have the checked-in version property. The property is reintroduced not =20= modified. > > >> Though the introduction of section 14 mentions workspaces, I don't =20= >> think >> the merge feature is limited to workspaces. It is allowed to use a >> version-controlled collection as the request URI and a collection =20 >> version >> as the source. If both would be associated with the same version =20 >> history, >> for example, it would be strange if in such a case new version-=20 >> controlled >> members would be created as described in section 4.11. > > That's possible (I haven't implemented merge); and maybe that's a =20 > separate erratum. > > Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I =20 > think it's sufficient if we describe a case where RFC 3253 *clearly* =20= > requires BIND semantics; so is the currently proposed text correct? > I agree that from the view point of the BIND spec this is sufficient =20 and the proposed text is correct. > BR, Julian Werner. -- Werner Donn=E9 -- Re = http://www.pincette.biz Engelbeekstraat 8 = http://www.re.be BE-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be From w3c-dist-auth-request@listhub.w3.org Tue Oct 7 08:34:30 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 35CE63A6951 for ; Tue, 7 Oct 2008 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.32 X-Spam-Level: X-Spam-Status: No, score=-9.32 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 s4hKBZafFfTK for ; Tue, 7 Oct 2008 08:34:24 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A559F28C222 for ; Tue, 7 Oct 2008 08:34:24 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KnEZc-0004Rv-Je for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Oct 2008 15:34:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KnEZb-0004RC-7R for w3c-dist-auth@listhub.w3.org; Tue, 07 Oct 2008 15:34:07 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1KnEZS-0007yl-IA for w3c-dist-auth@w3.org; Tue, 07 Oct 2008 15:34:06 +0000 Received: (qmail invoked by alias); 07 Oct 2008 15:33:27 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 07 Oct 2008 17:33:27 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18hmDQZErMhyILtaF6qaG9bjTJbbx1dlt6bUQLcbR V3ZEf4Kil4UHI1 Message-ID: <48EB8144.2010403@gmx.de> Date: Tue, 07 Oct 2008 17:33:24 +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: =?ISO-8859-1?Q?Werner_Donn=E9?= CC: Geoffrey M Clemm , w3c-dist-auth@w3.org References: <48B6AD77.5060008@gmx.de> <48E7A1B9.6000402@gmx.de> <48EB54E3.4000509@gmx.de> <2B894E8E-BFA4-45E0-A74D-CDEC15502150@re.be> <48EB59E0.7000404@gmx.de> <2CD7562A-5959-46C5-BC68-E98D8DF42D6D@re.be> <48EB6D99.7090709@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 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 1KnEZS-0007yl-IA f58bef9e8c5413eebed7e3a0b1721f1f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Relationship between BIND and RFC 3253 Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13032 X-Loop: w3c-dist-auth@w3.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, 07 Oct 2008 15:34:08 +0000 Werner Donné wrote: >> Yes, those apply; but how exactly do they help clarifying what the >> server needs to do? > > For me section 4.5 is complete. It says that the pre-CHECKOUT state > should be > restored. This means that the checked-in version becomes what it was before > the CHECKOUT. The version-controlled binding set of that checked-in version > must not have changed, because the corresponding property is protected > and the > DELETE and VERSION-CONTROL methods have the proper pre-conditions to > prevent it. But we're talking about the pre-CHECKOUT state of the *collection*, not its member. > In your original message you raise the question about what should happen > when > a VCR has been deleted since the last check-out. This is not a specific > matter Did I? I don't think so, but maybe I'm confused. Can we stick to the example that I proposed? Is there something wrong with it? > for UNCHECKOUT. When a DELETE is performed on a VCR that corresponds to > member > in a checked out collection, the server is responsible for making sure that > the version-controlled binding sets of all versions of that collection > are not > affected. Yes. > I don't think section 4.11 can apply to the UNCHECKOUT method, because > it says > what should happen when the checked-in version of a version-controlled > collection > is modified. A checked out collection is a checked out resource and > those don't > have the checked-in version property. The property is reintroduced not > modified. UNCHECKOUT changes the state of the collection to be checked in, so yes, I would claim that operation affects the DAV:checked-in property. > ... >> Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I >> think it's sufficient if we describe a case where RFC 3253 *clearly* >> requires BIND semantics; so is the currently proposed text correct? >> > > I agree that from the view point of the BIND spec this is sufficient and > the > proposed text is correct. > ... Great! I didn't mean to prevent other discussions, I just want to get things done step by step... BR, Julian From w3c-dist-auth-request@listhub.w3.org Sat Oct 18 01:00:01 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 CB9EE3A6858 for ; Sat, 18 Oct 2008 01:00:01 -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 jTUZZR4AksHO for ; Sat, 18 Oct 2008 01:00:00 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A7D483A67A4 for ; Sat, 18 Oct 2008 01:00:00 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kr6ie-00074n-Hy for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Oct 2008 07:59:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kr6id-000749-68 for w3c-dist-auth@listhub.w3.org; Sat, 18 Oct 2008 07:59:27 +0000 Received: from ebed.etf.cuni.cz ([195.113.5.3]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kr6iR-0007X5-3k for w3c-dist-auth@w3.org; Sat, 18 Oct 2008 07:59:26 +0000 Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id m9I7w7Vq018869 for ; Sat, 18 Oct 2008 09:58:07 +0200 Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id m9I7w4Ro018862 for w3c-dist-auth@w3.org; Sat, 18 Oct 2008 09:58:04 +0200 Date: Sat, 18 Oct 2008 09:58:04 +0200 From: Petr Tomasek To: WebDAV Message-ID: <20081018075804.GA17341@ebed.etf.cuni.cz> References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <20081007143043.GA21699@ebed.etf.cuni.cz> <48EB74E2.30803@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EB74E2.30803@gmx.de> User-Agent: Mutt/1.4.1i X-Homepage: http://www.etf.cuni.cz/~tomasek/ X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.9.0.5; VDF: 7.0.7.58; host: ebed.etf.cuni.cz) 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 1Kr6iR-0007X5-3k 6e4aeff610acf6d67991542d0bb35e94 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/13033 X-Loop: w3c-dist-auth@w3.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: Sat, 18 Oct 2008 07:59:28 +0000 > >Hi, > > > >I dislike the fact, that a simple task like creating a new resource > >should constitute complicated metadata creating/parsing. > > > >I think a simple method (I would choose another one, not the POST > >one, but e.g. "CREATE") would be more suitable to the HTTP model. > > I proposed that one ("ADDMEMBER", see > ) over three > years ago, and the feedback from the HTTP community I got was: "not > needed, just use POST"). Yes I know, but the "HTTP community" is simply wrong. There are fundamental differences of how POST and the supposed ADDMEMBER would work: - most important, POST generetas response body, while ADDMEMBER would never. I.e. POST is a mixture of PUT and GET, while ADDMEMBER would be a special case of PUT. - with POST the data structure is not defined and is completely up to the application. > The new proposal addresses that feedback -- it makes POST usable for > WebDAV collections. > > >Please, note, not everything on the earth "is WebDAV" and it seems > >to mee that forcing using XML everywhere, even if it is not necessary > >is simply an error (it leads to too complicated protocols and too > >much overhead for implementing them...) > > This is a proposal specifically for WebDAV. Thus I think it's totally Yes, and that's wrong, because this sort of action is genereal enough to be used outside of the scope of WebDAV.... > acceptable that the information lives in WebDAV properties. > > (That being said, I strongly disagree with the assumption that using XML > itself is a problem; see for instance AtomPub which uses exactly the > same approach) It may be problem e.g. for embedded devices with very low resources (have ever tried to implement something for 8bit MCU like Atmel AVR's? But there are working implementations of TCP/HTTP stack for such small devices; adding XML would perhaps double the code for such an implementation!) > > BR, Julian -- Petr Tomasek Jabber: butrus@jabbim.cz SIP: butrus@ekiga.net From w3c-dist-auth-request@listhub.w3.org Sat Oct 18 01:12:20 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 D5BC63A67D2 for ; Sat, 18 Oct 2008 01:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.604 X-Spam-Level: X-Spam-Status: No, score=-8.604 tagged_above=-999 required=5 tests=[AWL=1.995, 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 aGrb8+rfJ+d3 for ; Sat, 18 Oct 2008 01:12:20 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id F15763A68E0 for ; Sat, 18 Oct 2008 01:12:19 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Kr6vh-0003Ez-6W for w3c-dist-auth-dist@listhub.w3.org; Sat, 18 Oct 2008 08:12:57 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kr6vg-0003EG-Gm for w3c-dist-auth@listhub.w3.org; Sat, 18 Oct 2008 08:12:56 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Kr6vX-0007Sa-Ls for w3c-dist-auth@w3.org; Sat, 18 Oct 2008 04:12:56 -0400 Received: (qmail invoked by alias); 18 Oct 2008 08:12:15 -0000 Received: from p508FC42A.dip.t-dialin.net (EHLO [192.168.178.22]) [80.143.196.42] by mail.gmx.net (mp042) with SMTP; 18 Oct 2008 10:12:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18/3Zw8ChE/bRNSPDdRNyqMKkTZrDkf6wNyHmf4mh Q8BZOn2S6xCwUF Message-ID: <48F99A5B.5090500@gmx.de> Date: Sat, 18 Oct 2008 10:12:11 +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: Petr Tomasek CC: WebDAV References: <20080922153001.BC5663A69E7@core3.amsl.com> <48D7BCFE.40200@gmx.de> <20081007143043.GA21699@ebed.etf.cuni.cz> <48EB74E2.30803@gmx.de> <20081018075804.GA17341@ebed.etf.cuni.cz> In-Reply-To: <20081018075804.GA17341@ebed.etf.cuni.cz> 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: bart.w3.org 1Kr6vX-0007Sa-Ls ed62f4f0b6eda97cfbcfaff100637613 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/13034 X-Loop: w3c-dist-auth@w3.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: Sat, 18 Oct 2008 08:12:57 +0000 Petr Tomasek wrote: >> I proposed that one ("ADDMEMBER", see >> ) over three >> years ago, and the feedback from the HTTP community I got was: "not >> needed, just use POST"). > > Yes I know, but the "HTTP community" is simply wrong. There are fundamental > differences of how POST and the supposed ADDMEMBER would work: > - most important, POST generetas response body, while ADDMEMBER would never. > I.e. POST is a mixture of PUT and GET, while ADDMEMBER would be a special case > of PUT. How is that a problem? > - with POST the data structure is not defined and is completely up to > the application. Please elaborate. Which data structure? >> The new proposal addresses that feedback -- it makes POST usable for >> WebDAV collections. >> >>> Please, note, not everything on the earth "is WebDAV" and it seems >>> to mee that forcing using XML everywhere, even if it is not necessary >>> is simply an error (it leads to too complicated protocols and too >>> much overhead for implementing them...) >> This is a proposal specifically for WebDAV. Thus I think it's totally > > Yes, and that's wrong, because this sort of action is genereal enough > to be used outside of the scope of WebDAV.... And the answer to this that I got was: use POST. I have given up fighting that battle. How about trying yourself? >> acceptable that the information lives in WebDAV properties. >> >> (That being said, I strongly disagree with the assumption that using XML >> itself is a problem; see for instance AtomPub which uses exactly the >> same approach) > > It may be problem e.g. for embedded devices with very low resources > (have ever tried to implement something for 8bit MCU like Atmel AVR's? > But there are working implementations of TCP/HTTP stack for such small > devices; adding XML would perhaps double the code for such an implementation!) Out of the mobile devices which are sold *today*, which does have an HTTP stack that allows non-RFC2616 methods but does not have an XML parser? BR, Julian From w3c-dist-auth-request@listhub.w3.org Tue Oct 28 09:01:36 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 CD62E3A6C70 for ; Tue, 28 Oct 2008 09:01:36 -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 h6+zskgPU2rZ for ; Tue, 28 Oct 2008 09:01:31 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 027383A6A0B for ; Tue, 28 Oct 2008 09:00:46 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KuqyL-0002Sw-9A for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Oct 2008 15:59:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KuqyI-0002Rq-OW for w3c-dist-auth@listhub.w3.org; Tue, 28 Oct 2008 15:59:07 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Kuqy7-0006XK-4u for w3c-dist-auth@w3.org; Tue, 28 Oct 2008 15:59:06 +0000 Received: (qmail invoked by alias); 28 Oct 2008 15:58:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 28 Oct 2008 16:58:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dLAULSordwJGCb1RCopZPqg7ZcD0RdyeKyyf2zN tYnMXrn6UmP4md Message-ID: <4907369E.1070202@gmx.de> Date: Tue, 28 Oct 2008 16:58:22 +0100 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: <20081028150001.CFE733A6C60@core3.amsl.com> In-Reply-To: <20081028150001.CFE733A6C60@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.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: maggie.w3.org 1Kuqy7-0006XK-4u b879812771cbe4a1e39680cfa3a15232 X-Original-To: w3c-dist-auth@w3.org Subject: Re: I-D Action:draft-ietf-webdav-bind-22.txt Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13035 X-Loop: w3c-dist-auth@w3.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, 28 Oct 2008 15:59:09 +0000 Hi, this draft contains the changes discussed a few weeks ago: - a new chapter describing the relationship to DeltaV - relaxed requirements on status codes (allow 204 where previously 200 was required) Hopefully we can get this draft into the approval process... BR, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. > > > Title : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) > Author(s) : G. Clemm, et al. > Filename : draft-ietf-webdav-bind-22.txt > Pages : 49 > Date : 2008-10-28 > > This specification defines bindings, and the BIND method for creating > multiple bindings to the same resource. Creating a new binding to a > resource causes at least one new URI to be mapped to that resource. > Servers are required to insure the integrity of any bindings that > they allow to be created.Editorial Note (To be removed by RFC Editor > before publication) > > Please send comments to the Distributed Authoring and Versioning > (WebDAV) working group at , which may be > joined by sending a message with subject "subscribe" to > . Discussions of the WEBDAV > working group are archived at > . > > lists > all registered issues since draft 02. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-22.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