From w3c-dist-auth-request@frink.w3.org Thu Dec 01 11:25:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrF5-0002da-4y for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 11:25:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12407 for ; Thu, 1 Dec 2005 11:24:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhrDB-0007Sa-UB for w3c-dist-auth-dist@listhub.w3.org; Thu, 01 Dec 2005 16:23:09 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhrD4-0007Rx-Fk for w3c-dist-auth@listhub.w3.org; Thu, 01 Dec 2005 16:23:02 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EhrCj-0006DU-0D for w3c-dist-auth@w3.org; Thu, 01 Dec 2005 16:23:00 +0000 Received: (qmail invoked by alias); 01 Dec 2005 16:15:56 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp015) with SMTP; 01 Dec 2005 17:15:56 +0100 X-Authenticated: #1915285 Message-ID: <438F2171.40708@gmx.de> Date: Thu, 01 Dec 2005 17:14:41 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200511302210.jAUMAEY5016849@ietf.cse.ucsc.edu> In-Reply-To: <200511302210.jAUMAEY5016849@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhrCj-0006DU-0D 7f6b8df2a6249aef4aebf368da8755d8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/438F2171.40708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10764 X-Loop: w3c-dist-auth@w3.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, 01 Dec 2005 16:23:09 +0000 Content-Transfer-Encoding: 7bit Proposed fixes: follow the links from . Summary: In Section 9.4: Remove stuff about comma notation in "If" header; also restore original grammar (which was partly changed). Update examples. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 01 12:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsFT-0007fZ-0w for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 12:29:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21733 for ; Thu, 1 Dec 2005 12:28:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhsEL-0003mj-Rs for w3c-dist-auth-dist@listhub.w3.org; Thu, 01 Dec 2005 17:28:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EhsDO-0003hv-Kp for w3c-dist-auth@listhub.w3.org; Thu, 01 Dec 2005 17:27:26 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EhsDC-0004xT-SO for w3c-dist-auth@w3.org; Thu, 01 Dec 2005 17:27:26 +0000 Received: (qmail invoked by alias); 01 Dec 2005 17:27:03 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 01 Dec 2005 18:27:03 +0100 X-Authenticated: #1915285 Message-ID: <438F3216.8020206@gmx.de> Date: Thu, 01 Dec 2005 18:25:42 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Lisa Dusseault References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> In-Reply-To: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EhsDC-0004xT-SO e22379abe709cb4086dd68184e0bc540 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/438F3216.8020206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10765 X-Loop: w3c-dist-auth@w3.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, 01 Dec 2005 17:28:25 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de > Status|ASSIGNED |NEW > > > > ------- Additional Comments From lisa@osafoundation.org 2005-11-30 14:42 ------- > I didn't understand the part about removing the section on 503 -- what's wrong > with it? > > The part about XML entities I've fixed. We discussed this during the conference call: 5xx is a server error, in particular 503 means "not now but maybe later". If a server detects a DOS attack, that's the last thing it would want to tell the client. Servers are free to do whatever they want should they detect a DOS attack. If they want to be friendly, a 4xx with explanation would be right. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 01 14:00:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehtf0-0003ev-6b for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 14:00:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02288 for ; Thu, 1 Dec 2005 13:59:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EhtdW-0008RG-NH for w3c-dist-auth-dist@listhub.w3.org; Thu, 01 Dec 2005 18:58:30 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EhtdJ-0008KU-LG for w3c-dist-auth@listhub.w3.org; Thu, 01 Dec 2005 18:58:18 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EhtdE-0001dy-56 for w3c-dist-auth@w3.org; Thu, 01 Dec 2005 18:58:16 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BDAB91422B3; Thu, 1 Dec 2005 10:58:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01176-07; Thu, 1 Dec 2005 10:58:10 -0800 (PST) Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C3215142297; Thu, 1 Dec 2005 10:58:09 -0800 (PST) In-Reply-To: <438F3216.8020206@gmx.de> References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> <438F3216.8020206@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Thu, 1 Dec 2005 10:58:04 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EhtdE-0001dy-56 a09070a5b76afce732558727e0b0d5f2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/be45c019ace1809cc42df65b5a096944@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10766 X-Loop: w3c-dist-auth@w3.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, 01 Dec 2005 18:58:30 +0000 Content-Transfer-Encoding: 7bit Sorry about that -- I'll blame both a brain fart and I lost access to bugzilla immediately after I entered this so I couldn't change it. I do see how a 4xx error is better because the same request won't succeed later. Which 4xx response though? Lisa On Dec 1, 2005, at 9:25 AM, Julian Reschke wrote: > bugzilla@soe.ucsc.edu wrote: >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 >> lisa@osafoundation.org changed: >> What |Removed |Added >> ---------------------------------------------------------------------- >> ------ >> AssignedTo|lisa@osafoundation.org >> |julian.reschke@greenbytes.de >> Status|ASSIGNED |NEW >> ------- Additional Comments From lisa@osafoundation.org 2005-11-30 >> 14:42 ------- >> I didn't understand the part about removing the section on 503 -- >> what's wrong >> with it? The part about XML entities I've fixed. > > We discussed this during the conference call: 5xx is a server error, > in particular 503 means "not now but maybe later". If a server detects > a DOS attack, that's the last thing it would want to tell the client. > > Servers are free to do whatever they want should they detect a DOS > attack. If they want to be friendly, a 4xx with explanation would be > right. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 01 14:31:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehu95-0006cA-RH for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 14:31:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05841 for ; Thu, 1 Dec 2005 14:30:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ehu87-0003ED-In for w3c-dist-auth-dist@listhub.w3.org; Thu, 01 Dec 2005 19:30:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ehu72-0002Aq-97 for w3c-dist-auth@listhub.w3.org; Thu, 01 Dec 2005 19:29:00 +0000 Received: from mail.gmx.net ([213.165.64.20]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ehu6Y-0006SP-Hv for w3c-dist-auth@w3.org; Thu, 01 Dec 2005 19:28:58 +0000 Received: (qmail invoked by alias); 01 Dec 2005 19:28:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 01 Dec 2005 20:28:26 +0100 X-Authenticated: #1915285 Message-ID: <438F4E81.1070007@gmx.de> Date: Thu, 01 Dec 2005 20:26:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> <438F3216.8020206@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ehu6Y-0006SP-Hv a53f6d4c3446c2adb03f7c020bba1584 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/438F4E81.1070007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10767 X-Loop: w3c-dist-auth@w3.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, 01 Dec 2005 19:30:07 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Sorry about that -- I'll blame both a brain fart and I lost access to > bugzilla immediately after I entered this so I couldn't change it. I do > see how a 4xx error is better because the same request won't succeed > later. Which 4xx response though? > > Lisa I think 400 is just fine. See . Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:44:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0uu-0004Vh-0g for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:44:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27195 for ; Thu, 1 Dec 2005 21:44:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei0tm-0000PE-BM for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:43:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei0tg-0000OF-Tu for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:43:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei0td-0004j1-KL for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:43:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22hYxE002427; Thu, 1 Dec 2005 18:43:34 -0800 Date: Thu, 1 Dec 2005 18:43:34 -0800 Message-Id: <200512020243.jB22hYxE002427@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei0td-0004j1-KL 8cab2e533c0fccc666f49f0dfedde935 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200512020243.jB22hYxE002427@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10769 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:43:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:44:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0uu-0004Vi-57 for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:44:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27196 for ; Thu, 1 Dec 2005 21:44:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei0u7-0000Uk-Lu for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:44:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei0u6-0000S2-0F for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:44:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei0u3-0004sJ-K6 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:44:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22i2M5002439; Thu, 1 Dec 2005 18:44:02 -0800 Date: Thu, 1 Dec 2005 18:44:02 -0800 Message-Id: <200512020244.jB22i2M5002439@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei0u3-0004sJ-K6 cf297032eaa0b08770226455d5f56ade X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200512020244.jB22i2M5002439@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10770 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:44:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:44:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0uu-0004W5-Au for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:44:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27197 for ; Thu, 1 Dec 2005 21:44:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei0tQ-0000K6-B4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:43:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei0tH-0000Hc-Aq for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:43:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ei0tD-0008SB-VA for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:43:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22h98t002415; Thu, 1 Dec 2005 18:43:09 -0800 Date: Thu, 1 Dec 2005 18:43:09 -0800 Message-Id: <200512020243.jB22h98t002415@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ei0tD-0008SB-VA f7903f0b01434406b91200bf4c2ae9b6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200512020243.jB22h98t002415@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10768 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:43:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:46:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0wA-0004tC-Eh for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:46:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27451 for ; Thu, 1 Dec 2005 21:45:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei0va-0002F4-G7 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:45:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei0vY-0002B5-86 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:45:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ei0vV-0000es-36 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:45:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22jWLp002451; Thu, 1 Dec 2005 18:45:32 -0800 Date: Thu, 1 Dec 2005 18:45:32 -0800 Message-Id: <200512020245.jB22jWLp002451@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ei0vV-0000es-36 820d339304af8ca5a3a8244b394a8a24 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200512020245.jB22jWLp002451@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10771 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:45:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:48:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0y4-0005gR-HN for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:48:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27587 for ; Thu, 1 Dec 2005 21:47:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei0xW-0003K5-8A for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:47:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei0xU-0003JJ-IR for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:47:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ei0xS-00016b-6P for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:47:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22lXa8002474; Thu, 1 Dec 2005 18:47:33 -0800 Date: Thu, 1 Dec 2005 18:47:33 -0800 Message-Id: <200512020247.jB22lXa8002474@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ei0xS-00016b-6P 3685e43846c96890e239eeb72bdd224c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200512020247.jB22lXa8002474@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10772 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:47:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei112-0007JL-Og for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:51:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27888 for ; Thu, 1 Dec 2005 21:50:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei10O-0004Hl-LB for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:50:36 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ei10M-0004GK-Fd for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:50:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ei10F-0002nx-0F for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:50:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22oOGk002513; Thu, 1 Dec 2005 18:50:24 -0800 Date: Thu, 1 Dec 2005 18:50:24 -0800 Message-Id: <200512020250.jB22oOGk002513@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ei10F-0002nx-0F edf01a0aeabd8f10969c2514f3385782 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 35] RFC2606 compliance X-Archived-At: http://www.w3.org/mid/200512020250.jB22oOGk002513@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10773 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:50:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=35 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From elias@cse.ucsc.edu 2005-12-01 18:50 ------- consensus reached to revisit this as a last call issue ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:53:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei138-0000Og-2i for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:53:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28000 for ; Thu, 1 Dec 2005 21:52:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei12Y-0004eP-UU for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:52:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ei12U-0004co-G7 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:52:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ei12K-0003K9-8t for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:52:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22qaeP002540; Thu, 1 Dec 2005 18:52:36 -0800 Date: Thu, 1 Dec 2005 18:52:36 -0800 Message-Id: <200512020252.jB22qaeP002540@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ei12K-0003K9-8t 56e60ecb1d8ab22b3d6b3efe5f9ba49c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512020252.jB22qaeP002540@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10774 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:52:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 21:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei13A-0000R4-2Q for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 21:53:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28005 for ; Thu, 1 Dec 2005 21:52:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei12c-0004hS-SA for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 02:52:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ei12a-0004eX-4Y for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 02:52:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ei12W-0003Md-L2 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 02:52:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB22qmsO002558; Thu, 1 Dec 2005 18:52:48 -0800 Date: Thu, 1 Dec 2005 18:52:48 -0800 Message-Id: <200512020252.jB22qmsO002558@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ei12W-0003Md-L2 f39bbe2890524abcb59d9fe80d227608 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512020252.jB22qmsO002558@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10775 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 02:52:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:15:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1O8-000546-6T for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:15:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29916 for ; Thu, 1 Dec 2005 22:14:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1NN-0001xT-IC for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:14:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1NK-0001w6-FK for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:14:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ei1NF-0007jD-Lo for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:14:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23ECis002618; Thu, 1 Dec 2005 19:14:12 -0800 Date: Thu, 1 Dec 2005 19:14:12 -0800 Message-Id: <200512020314.jB23ECis002618@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ei1NF-0007jD-Lo 1d2e2bfc92a3bc95e671671278c8827a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 72] Review references section X-Archived-At: http://www.w3.org/mid/200512020314.jB23ECis002618@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10776 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:14:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=72 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From elias@cse.ucsc.edu 2005-12-01 19:14 ------- let's come back to this issue when reviewing the penultimate last call draft. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:16:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1PN-0007eo-IQ for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:16:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00042 for ; Thu, 1 Dec 2005 22:15:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1On-0003po-Dw for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:15:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1Ol-0003p3-Th for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:15:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei1Oi-0003lC-MQ for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:15:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23FiEt002648; Thu, 1 Dec 2005 19:15:44 -0800 Date: Thu, 1 Dec 2005 19:15:44 -0800 Message-Id: <200512020315.jB23FiEt002648@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei1Oi-0003lC-MQ 07104c3ede63d82dc947c85d235a5bba X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 16] Trailing slash required in collection names? X-Archived-At: http://www.w3.org/mid/200512020315.jB23FiEt002648@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10777 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:15:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:16:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1PV-0007vY-Rk for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:16:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00044 for ; Thu, 1 Dec 2005 22:15:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1Oy-0003vv-M0 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:16:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1Ox-0003v4-75 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:15:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei1Ou-0003pc-Em for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:15:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23FtCk002666; Thu, 1 Dec 2005 19:15:55 -0800 Date: Thu, 1 Dec 2005 19:15:55 -0800 Message-Id: <200512020315.jB23FtCk002666@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei1Ou-0003pc-Em 7287ed213b7e3b45c39a13681537d234 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 16] Trailing slash required in collection names? X-Archived-At: http://www.w3.org/mid/200512020315.jB23FtCk002666@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10778 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:16:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:49:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1v6-00085s-7j for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:49:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02404 for ; Thu, 1 Dec 2005 22:48:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1ty-0007Zv-A5 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:48:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1tt-0007Yg-Ni for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:47:58 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ei1ti-0000gi-P6 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:47:56 +0000 Received: from [10.1.4.123] (20.commerce.net [157.22.247.20] (may be forged)) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB23lfFQ000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Dec 2005 19:47:41 -0800 (PST) Message-ID: <438FC3DD.9050701@cse.ucsc.edu> Date: Thu, 01 Dec 2005 19:47:41 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ei1ti-0000gi-P6 4e0bdaf53cb1c14c5664067b9bb2b0d0 X-Original-To: w3c-dist-auth@w3.org Subject: agenda for 12/2 telecon X-Archived-At: http://www.w3.org/mid/438FC3DD.9050701@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10779 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:48:02 +0000 Content-Transfer-Encoding: 7bit Hello WG, Enclosed please find the agenda for the 12/2 telecon -- apologies for getting it out late; most of you are aware of the hard reboot that was necessary to get the ietf machine (which hosts bugzilla) back online earlier today. Whereas I have included a couple more issues than we've been able to get through in recent telecons, better than a handful of them are minor editorial issues that will be easy to address. Also, if you have any favorite issues that you *really* want to address in the 12/7 telecon, either send me an brief email or (preferrably) raise the severity / priority in bugzilla. Following tomorrows telecon, almost all of the remaining issues will be /normal/ and /P2/, which makes selecting issues for the agenda somewhat arbitrary. Cheers, Elias ___________________ (1) A couple of issues still on the table despite previous review / discussion / proposals 10 - Round-tripping namespace decls in properties (prior agreement to read Julians proposal...) 174 - Terminology in 4.4: "namespace name in scope" (addressed by resolution to issue 10?) (2) Some easy (?) editorial issues; simply to get them off the list 90 - broken RFC2277 reference (editorial issue) 103 - Start of introduction for DELETE confusing (Editorial issue; move sentence...) 128 - LEVEL_OR_CLASS (let's pick one and move on) 175 - Section 8.1.3 unneeded 178 - Multistatus for DELETE (minor editorial issue) 189 - "RFC2518bis" in spec text (another minor editorial issue) (3) The main course . . . 52 - "mandatory" properties 55 - Multistatus format (empty) 56 - 423 Locked in Multistatus for PROPPATCH? 59 - failed LOCK response body 79 - PUT for collections rationale 80 - Specify idempotence and safeness for all new methods 99 - Risks Connected with Lock Tokens (Review proposed text) 104 - Confusing new sentence in intro of COPY 105 - COPY for Collection Resources vs infinite loops 106 - COPY and the Overwrite Header vs merge behaviour desc added 107 - Status 102 present; but status-uri response header removed From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:49:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1vD-000879-VM for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:49:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02406 for ; Thu, 1 Dec 2005 22:48:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1ug-0007kb-7v for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:48:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1ue-0007jn-IG for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:48:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei1uW-0003ka-Dm for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:48:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23mawe002751; Thu, 1 Dec 2005 19:48:36 -0800 Date: Thu, 1 Dec 2005 19:48:36 -0800 Message-Id: <200512020348.jB23mawe002751@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei1uW-0003ka-Dm d4555e6af6a5a7a1880ed830ab3a1a32 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 149] NEW_MULTIPUT_METHOD X-Archived-At: http://www.w3.org/mid/200512020348.jB23mawe002751@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10780 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:48:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=149 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-01 19:48 ------- I agree with Julians comment -- let's close this out. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:50:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1wX-0000uN-Tq for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:50:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02562 for ; Thu, 1 Dec 2005 22:49:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1vy-0000Ft-De for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:50:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1vw-0000Ek-L0 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:50:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ei1vt-0001Ix-So for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:50:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23o0KW002769; Thu, 1 Dec 2005 19:50:00 -0800 Date: Thu, 1 Dec 2005 19:50:00 -0800 Message-Id: <200512020350.jB23o0KW002769@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ei1vt-0001Ix-So f058c35b311a99ca1372715dcd1d066d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 156] HOW_ARE_TRAILING_SLASHES_USED X-Archived-At: http://www.w3.org/mid/200512020350.jB23o0KW002769@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10781 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:50:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=156 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |16 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 01 22:50:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1wb-0000zE-Dr for webdav-archive@megatron.ietf.org; Thu, 01 Dec 2005 22:50:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02570 for ; Thu, 1 Dec 2005 22:49:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ei1w3-0000Kq-Rs for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 03:50:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ei1w2-0000Ie-5U for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 03:50:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ei1vu-00047J-6w for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 03:50:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB23o1AF002783; Thu, 1 Dec 2005 19:50:01 -0800 Date: Thu, 1 Dec 2005 19:50:01 -0800 Message-Id: <200512020350.jB23o1AF002783@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ei1vu-00047J-6w 9b7d812d9fd380b3077b2a6f49e4f5bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 16] Trailing slash required in collection names? X-Archived-At: http://www.w3.org/mid/200512020350.jB23o1AF002783@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10782 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 03:50:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |156 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 11:46:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiE3M-0003o8-EB for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 11:46:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15540 for ; Fri, 2 Dec 2005 11:45:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiE1V-0005o5-2R for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 16:44:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiE1K-0005mb-Kd for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 16:44:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiE1C-00049t-KT for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 16:44:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2GiGBN003560; Fri, 2 Dec 2005 08:44:16 -0800 Date: Fri, 2 Dec 2005 08:44:16 -0800 Message-Id: <200512021644.jB2GiGBN003560@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiE1C-00049t-KT f9363a390bdf8702064c85f759663de9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200512021644.jB2GiGBN003560@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10783 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 16:44:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-02 08:44 ------- Didn't have time to test IIS yet. I *do* recall now the DeltaV behaviour. It's not "merge", but COPY with a collection target updates the individual target resources (like COPY to a plain resource), and also removes those resources from the target collection that did not exist in the source namespace. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:35:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEp1-0007Ag-DB for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:35:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22341 for ; Fri, 2 Dec 2005 12:34:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEoH-0002XT-Rc for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:35:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiEoG-0002WW-0B for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:35:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiEo1-0004Fv-GZ for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:34:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HYh5n003660; Fri, 2 Dec 2005 09:34:43 -0800 Date: Fri, 2 Dec 2005 09:34:43 -0800 Message-Id: <200512021734.jB2HYh5n003660@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiEo1-0004Fv-GZ 48c78aeba02780c13cab7db2b2e60c09 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 174] Terminology in 4.4: "namespace name in scope" X-Archived-At: http://www.w3.org/mid/200512021734.jB2HYh5n003660@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10785 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:35:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=174 Bug 174 depends on bug 10, which changed state. Bug 10 Summary: Round-tripping namespace decls in properties http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:35:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEp1-0007Ai-HB for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:35:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22339 for ; Fri, 2 Dec 2005 12:34:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEoC-0002WL-AM for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:34:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEo4-0002VB-A1 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:34:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiEo0-00086M-87 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:34:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HYffR003632; Fri, 2 Dec 2005 09:34:41 -0800 Date: Fri, 2 Dec 2005 09:34:41 -0800 Message-Id: <200512021734.jB2HYffR003632@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiEo0-00086M-87 7b70e0dfbf5b02220dacc2c99a82d0ec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512021734.jB2HYffR003632@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10784 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:34:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:34 ------- Rough consensu reached on the 12/2 telecon wrt Julians proposed text, modulo some minor tweaks to the language ('clients will...') and remaining nit about handling of comments. Elias to raise issue regarding the handling of comments on the list. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:35:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEp1-0007B4-Lw for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:35:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22340 for ; Fri, 2 Dec 2005 12:34:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEoJ-0002vj-VO for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:35:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEo9-0002Vr-RA for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:34:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiEo6-0003g2-3D for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:34:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HYgjG003646; Fri, 2 Dec 2005 09:34:42 -0800 Date: Fri, 2 Dec 2005 09:34:42 -0800 Message-Id: <200512021734.jB2HYgjG003646@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiEo6-0003g2-3D 2e61cef263b1db2e8b1881f3b5e1621e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200512021734.jB2HYgjG003646@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10786 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:35:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 Bug 22 depends on bug 10, which changed state. Bug 10 Summary: Round-tripping namespace decls in properties http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:36:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEpJ-0007W1-NQ for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:36:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22418 for ; Fri, 2 Dec 2005 12:35:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEok-00038j-3H for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:35:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEoi-000389-90 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:35:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiEoa-0003pj-Jo for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:35:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HZ85o003680; Fri, 2 Dec 2005 09:35:08 -0800 Date: Fri, 2 Dec 2005 09:35:08 -0800 Message-Id: <200512021735.jB2HZ85o003680@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiEoa-0003pj-Jo 6edde61e66a3668ac465eaa31dd3717a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 90] broken RFC2277 reference X-Archived-At: http://www.w3.org/mid/200512021735.jB2HZ85o003680@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10787 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:35:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=90 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:36:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEpe-00081d-BQ for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:36:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22470 for ; Fri, 2 Dec 2005 12:35:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEp4-0003Fu-51 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:35:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEp2-0003Ep-Ku for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:35:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiEox-00008r-Q4 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:35:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HZhtg003696; Fri, 2 Dec 2005 09:35:43 -0800 Date: Fri, 2 Dec 2005 09:35:43 -0800 Message-Id: <200512021735.jB2HZhtg003696@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiEox-00008r-Q4 b5b8ce680f3d3f700193b813fe1c34a3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 174] Terminology in 4.4: "namespace name in scope" X-Archived-At: http://www.w3.org/mid/200512021735.jB2HZhtg003696@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10788 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:35:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=174 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:35 ------- resolved via issue 10. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:39:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEsh-0002Z9-LN for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:39:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22809 for ; Fri, 2 Dec 2005 12:38:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEs7-0004XR-WD for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:39:00 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiEs6-0004Wr-32 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:38:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiEs2-0005Z6-JM for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:38:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HcsUu003725; Fri, 2 Dec 2005 09:38:54 -0800 Date: Fri, 2 Dec 2005 09:38:54 -0800 Message-Id: <200512021738.jB2HcsUu003725@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiEs2-0005Z6-JM 001168101bc5bf16e41fd22f2427cf6b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 103] Start of introduction for DELETE confusing X-Archived-At: http://www.w3.org/mid/200512021738.jB2HcsUu003725@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10789 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:38:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:38 ------- Lisa to work it out with Jim during 12/9 editing session, perhaps move to a new section on DELETE and locks? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:42:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEvR-0003Y9-JZ for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:42:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23143 for ; Fri, 2 Dec 2005 12:41:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEup-0005Au-JE for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:41:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEuo-0005AH-1u for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:41:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiEul-0003Bd-BK for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:41:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HfhX3003744; Fri, 2 Dec 2005 09:41:43 -0800 Date: Fri, 2 Dec 2005 09:41:43 -0800 Message-Id: <200512021741.jB2HfhX3003744@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiEul-0003Bd-BK 0eef184d953062476188b92035cedde8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 128] LEVEL_OR_CLASS X-Archived-At: http://www.w3.org/mid/200512021741.jB2HfhX3003744@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10790 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:41:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=128 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:41 ------- Lisa to fix. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:45:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEyo-00064W-Ei for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:45:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23361 for ; Fri, 2 Dec 2005 12:45:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiExv-0005S9-SY for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:44:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiExu-0005RZ-6Q for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:44:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiExm-0007Yx-4R for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:44:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HinVT003788; Fri, 2 Dec 2005 09:44:49 -0800 Date: Fri, 2 Dec 2005 09:44:49 -0800 Message-Id: <200512021744.jB2HinVT003788@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiExm-0007Yx-4R 8a7a6ff49912a4c1e02952bd276e66fb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 91] chapter name for lock token uri schemes X-Archived-At: http://www.w3.org/mid/200512021744.jB2HinVT003788@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10791 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:44:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=91 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:47:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF02-0006ph-06 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:47:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23552 for ; Fri, 2 Dec 2005 12:46:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEzF-00078w-5q for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:46:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEzD-00078I-MD for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:46:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiEz2-0004tK-LH for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:46:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2Hk7Cn003809; Fri, 2 Dec 2005 09:46:07 -0800 Date: Fri, 2 Dec 2005 09:46:07 -0800 Message-Id: <200512021746.jB2Hk7Cn003809@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiEz2-0004tK-LH 4ae7a77a4391b465c7fe9081ceec1d67 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 103] Start of introduction for DELETE confusing X-Archived-At: http://www.w3.org/mid/200512021746.jB2Hk7Cn003809@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10792 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:46:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 09:46 ------- Will be fixed in next draft with an introductory sentence. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:47:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF0K-00074J-W9 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:47:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23579 for ; Fri, 2 Dec 2005 12:46:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiEzi-0007FH-I1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:46:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiEzg-0007Eh-OT for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:46:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiEv5-00062U-EB for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:46:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2Hg245003764; Fri, 2 Dec 2005 09:42:02 -0800 Date: Fri, 2 Dec 2005 09:42:02 -0800 Message-Id: <200512021742.jB2Hg245003764@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiEv5-00062U-EB fbba95f8151149b96a3e1191bfb94e5b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 128] LEVEL_OR_CLASS X-Archived-At: http://www.w3.org/mid/200512021742.jB2Hg245003764@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10793 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:46:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=128 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 09:42 ------- I think that the use of the 'compliance-code' token in bnf was the only remaining case of this and I've fixed it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:49:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF2f-0001OU-JO for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:49:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23801 for ; Fri, 2 Dec 2005 12:49:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF25-0007iR-6R for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:49:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiF23-0007hn-Lh for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:49:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiF21-0005tP-Je for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:49:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HnDsI003833; Fri, 2 Dec 2005 09:49:13 -0800 Date: Fri, 2 Dec 2005 09:49:13 -0800 Message-Id: <200512021749.jB2HnDsI003833@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiF21-0005tP-Je d39cf15e17e6e6b2a0a579d45410334b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 178] Multistatus for DELETE X-Archived-At: http://www.w3.org/mid/200512021749.jB2HnDsI003833@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10794 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:49:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=178 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:50:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF3O-0001bn-63 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:50:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23821 for ; Fri, 2 Dec 2005 12:49:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF2p-0008H4-LZ for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:50:03 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiF2n-0007tq-V6 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:50:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiF2k-0008Gw-OW for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:50:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HnwMK003853; Fri, 2 Dec 2005 09:49:58 -0800 Date: Fri, 2 Dec 2005 09:49:58 -0800 Message-Id: <200512021749.jB2HnwMK003853@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiF2k-0008Gw-OW 9d4147c8cf75b5f0b9d7efd561e74ba1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 175] Sectiion 8.1.3 unneeded X-Archived-At: http://www.w3.org/mid/200512021749.jB2HnwMK003853@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10795 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:50:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=175 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:49 ------- The text doesn't seem to do any harm, and there has been some related questions about appropriateness of headers in various situations. Request to update the HTTP reference so that it is specific to the section on the date header. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:51:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF43-0001jf-Sp for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:51:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23887 for ; Fri, 2 Dec 2005 12:50:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF3S-0008Tr-E3 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:50:42 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiF3Q-0008Rg-2w for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:50:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiF3K-0000uE-3s for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:50:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HoXbx003880; Fri, 2 Dec 2005 09:50:33 -0800 Date: Fri, 2 Dec 2005 09:50:33 -0800 Message-Id: <200512021750.jB2HoXbx003880@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiF3K-0000uE-3s e2468eb36570e108f3b6c608df36edef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 175] Sectiion 8.1.3 unneeded X-Archived-At: http://www.w3.org/mid/200512021750.jB2HoXbx003880@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10796 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:50:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=175 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 09:50 ------- Added section reference. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:52:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF5d-00024W-C5 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:52:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24172 for ; Fri, 2 Dec 2005 12:52:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF4w-0000L8-GG for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:52:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiF4u-0000KY-SQ for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:52:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiF4r-0000Vt-Uf for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:52:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2Hq9IP003901; Fri, 2 Dec 2005 09:52:09 -0800 Date: Fri, 2 Dec 2005 09:52:09 -0800 Message-Id: <200512021752.jB2Hq9IP003901@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiF4r-0000Vt-Uf e27d35ac2c8c179799ec880a2b750f97 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 189] "RFC2518bis" in spec text X-Archived-At: http://www.w3.org/mid/200512021752.jB2Hq9IP003901@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10797 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:52:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=189 ------- Additional Comments From lisa@osafoundation.org 2005-12-02 09:52 ------- FYI, I've fixed the references to "RFC2518bis" as "this specification". ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:53:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF6X-0002Ar-M2 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:53:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24226 for ; Fri, 2 Dec 2005 12:53:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF5y-0000bI-NP for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:53:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiF5x-0000af-3o for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:53:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiF5t-0000oU-Bo for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:53:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2HrCwX003925; Fri, 2 Dec 2005 09:53:12 -0800 Date: Fri, 2 Dec 2005 09:53:12 -0800 Message-Id: <200512021753.jB2HrCwX003925@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiF5t-0000oU-Bo 616876d80f57f3162abc462dd7a38a6c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 189] "RFC2518bis" in spec text X-Archived-At: http://www.w3.org/mid/200512021753.jB2HrCwX003925@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10798 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:53:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=189 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:53 ------- Informational references are okay, normative references are not... to be checked later. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 12:54:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF7E-0002QX-2A for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 12:54:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24380 for ; Fri, 2 Dec 2005 12:53:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiF6g-0000pK-AD for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 17:54:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiF6e-0000oQ-Hv for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 17:54:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiF6b-0001xK-Ce for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 17:53:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2Hrv80003943; Fri, 2 Dec 2005 09:53:57 -0800 Date: Fri, 2 Dec 2005 09:53:57 -0800 Message-Id: <200512021753.jB2Hrv80003943@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiF6b-0001xK-Ce 13968e0f15ac4a13fb5518f8d8a4b78a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 189] "RFC2518bis" in spec text X-Archived-At: http://www.w3.org/mid/200512021753.jB2Hrv80003943@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10799 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 17:54:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=189 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:53 ------- Julian volunteered to do a thorough check in next draft (-09). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:20:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFWH-0005B6-MQ for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:20:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27327 for ; Fri, 2 Dec 2005 13:19:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFVZ-0000vW-JH for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:19:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFVV-0000us-FE for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:19:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiFVS-0001OZ-6w for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:19:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2IJNIj003989; Fri, 2 Dec 2005 10:19:23 -0800 Date: Fri, 2 Dec 2005 10:19:23 -0800 Message-Id: <200512021819.jB2IJNIj003989@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiFVS-0001OZ-6w fb69a7f0d4897904bcf609c2edab00c1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] "mandatory" properties X-Archived-At: http://www.w3.org/mid/200512021819.jB2IJNIj003989@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10800 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:19:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 10:19 ------- Need to ping client implementors. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:21:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFX1-0006IA-NN for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:21:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27468 for ; Fri, 2 Dec 2005 13:20:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFWT-0001WR-Rx for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:20:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFWR-0001VZ-EV for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:20:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiFWN-0001jw-I1 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:20:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2IKIw2004013; Fri, 2 Dec 2005 10:20:18 -0800 Date: Fri, 2 Dec 2005 10:20:18 -0800 Message-Id: <200512021820.jB2IKIw2004013@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiFWN-0001jw-I1 6221853cb485fd070a16442c3aa2d107 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 55] Multistatus format (empty) X-Archived-At: http://www.w3.org/mid/200512021820.jB2IKIw2004013@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10801 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:20:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=55 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:29:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFeY-0002Rf-Kl for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:29:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28337 for ; Fri, 2 Dec 2005 13:28:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFdv-0002e4-R0 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:28:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFdt-0002dR-OA for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:28:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiFdm-000292-6Y for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:28:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2ISDxg004037; Fri, 2 Dec 2005 10:28:13 -0800 Date: Fri, 2 Dec 2005 10:28:13 -0800 Message-Id: <200512021828.jB2ISDxg004037@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EiFdm-000292-6Y f7d7680a5ecb5a8fd2cc400306a99c22 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 56] 423 Locked in Multistatus for PROPPATCH? X-Archived-At: http://www.w3.org/mid/200512021828.jB2ISDxg004037@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10802 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:28:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=56 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 10:28 ------- This can be removed altogether because it's dead obvious. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:32:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFhq-0003qJ-3G for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:32:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28627 for ; Fri, 2 Dec 2005 13:31:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFhF-0004O3-H5 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:31:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFhD-0004NV-UV for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:31:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiFh9-0006Uf-IU for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:31:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2IVNAF004064; Fri, 2 Dec 2005 10:31:23 -0800 Date: Fri, 2 Dec 2005 10:31:23 -0800 Message-Id: <200512021831.jB2IVNAF004064@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiFh9-0006Uf-IU 8e2557a376e478a6f9b8d9cc73e2e548 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 59] failed LOCK response body X-Archived-At: http://www.w3.org/mid/200512021831.jB2IVNAF004064@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10803 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:31:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=59 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 10:31 ------- second sentence removed ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:41:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFqG-0002YM-Rh for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:41:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29855 for ; Fri, 2 Dec 2005 13:40:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFpV-0005vH-Nn for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:40:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFpR-0005ua-39 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:40:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiFpJ-0001VB-9d for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:40:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2Ie8QT004093; Fri, 2 Dec 2005 10:40:08 -0800 Date: Fri, 2 Dec 2005 10:40:08 -0800 Message-Id: <200512021840.jB2Ie8QT004093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiFpJ-0001VB-9d b9d9503882f959754ddab41939e52eec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 79] PUT for collections rationale X-Archived-At: http://www.w3.org/mid/200512021840.jB2Ie8QT004093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10804 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:40:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=79 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 10:40 ------- Suggested new text This specification does not define the behavior of the PUT method for existing collections. A PUT request to an existing collection MAY be treated as an error (405 Method Not Allowed). The MKCOL method is defined to create collections. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:45:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFu2-0006NB-02 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:45:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00331 for ; Fri, 2 Dec 2005 13:44:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFtR-0006Y3-SY for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:44:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EiFtQ-0006XV-7p for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:44:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EiFtM-0002rw-OO for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:44:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2IiHcr004120; Fri, 2 Dec 2005 10:44:17 -0800 Date: Fri, 2 Dec 2005 10:44:17 -0800 Message-Id: <200512021844.jB2IiHcr004120@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EiFtM-0002rw-OO fca3477932b222a14f18b947fafba7e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200512021844.jB2IiHcr004120@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10805 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:44:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 10:44 ------- Julian to propose ... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 13:50:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFyw-0000PO-IY for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 13:50:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00843 for ; Fri, 2 Dec 2005 13:49:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiFxt-0000S4-TU for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 18:49:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiFxq-0000R1-LJ for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 18:48:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiFxm-0002Qu-Aj for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 18:48:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2ImoOt004141; Fri, 2 Dec 2005 10:48:50 -0800 Date: Fri, 2 Dec 2005 10:48:50 -0800 Message-Id: <200512021848.jB2ImoOt004141@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiFxm-0002Qu-Aj 80af106aa882c8a45b09046551368a52 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 99] Risks Connected with Lock Tokens X-Archived-At: http://www.w3.org/mid/200512021848.jB2ImoOt004141@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10806 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 18:49:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-02 10:48 ------- I integrated what Julian said were the important changes, especially the last paragraph. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 14:14:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGMR-0000ma-C0 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 14:14:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03645 for ; Fri, 2 Dec 2005 14:13:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiGLi-0007dw-BS for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 19:13:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiGLe-0007d0-1g for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 19:13:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiGLa-00081r-21 for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 19:13:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2JDTsc004184; Fri, 2 Dec 2005 11:13:29 -0800 Date: Fri, 2 Dec 2005 11:13:29 -0800 Message-Id: <200512021913.jB2JDTsc004184@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EiGLa-00081r-21 f0ab1afd9d72af8e72562993d8a22ec4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200512021913.jB2JDTsc004184@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10807 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 19:13:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 11:13 ------- Julian to propose text to WG regarding dangers of recursive operations after reviewing the next draft (-09). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 14:34:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiGg7-0006Bj-VH for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 14:34:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05456 for ; Fri, 2 Dec 2005 14:33:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiGfT-0006Ti-F9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 19:34:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiGfK-0006Rf-RF for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 19:33:55 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiGfE-0008WA-2Y for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 19:33:53 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EFF081422C0; Fri, 2 Dec 2005 11:33:44 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11220-02; Fri, 2 Dec 2005 11:33:44 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4B7CC1422A2; Fri, 2 Dec 2005 11:33:44 -0800 (PST) In-Reply-To: <438F4E81.1070007@gmx.de> References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> <438F3216.8020206@gmx.de> <438F4E81.1070007@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Fri, 2 Dec 2005 11:33:41 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiGfE-0008WA-2Y 3f68fbd09c7d61d1a1f42f8763539381 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/c500881704e674c22ea70cd9f55e8469@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10808 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 19:34:03 +0000 Content-Transfer-Encoding: 7bit How about adding to the DOS section? WebDAV servers need to be aware of the possibility of a denial of service attack at all levels. The proper response to such an attack MAY be to simply drop the connection, or if the server is able to make a response, the server MAY use a 400-level status request such as 400 (Bad Request) and indicate why the request was refused (a 500-level status response would indicate that the problem is with the server, whereas unintentional DOS attacks are something the client is capable of remedying). On Dec 1, 2005, at 11:26 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Sorry about that -- I'll blame both a brain fart and I lost access to >> bugzilla immediately after I entered this so I couldn't change it. I >> do see how a 4xx error is better because the same request won't >> succeed later. Which 4xx response though? >> Lisa > > I think 400 is just fine. > > See > latest.html#rfc.change.bz011.1>. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 02 17:01:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiIxo-00018u-Pv for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 17:01:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05414 for ; Fri, 2 Dec 2005 17:00:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiIwM-0006qI-Tw for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 21:59:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiIw7-0006pF-F2 for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 21:59:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiIw3-0005p5-7X for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 21:59:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2LxE3e004316; Fri, 2 Dec 2005 13:59:14 -0800 Date: Fri, 2 Dec 2005 13:59:14 -0800 Message-Id: <200512022159.jB2LxE3e004316@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiIw3-0005p5-7X 3744ae5cd8c16b67e51c8907ef41a0c4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 23] lock discovery vs shared locks X-Archived-At: http://www.w3.org/mid/200512022159.jB2LxE3e004316@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10809 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 21:59:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23 ------- Additional Comments From lisa@osafoundation.org 2005-12-02 13:59 ------- BTW another part of this bug (which should have been resolved FIXED if we had split the bug out into two) was resolving Geoff's suggestion about what to have in the lockdiscovery response to a LOCK request. Geoff said: > From a lock privacy perspective, putting all information about the > newly created lock in the lockdiscovery response to a LOCK > request is (of course) no problem, so requiring that is fine with me. > Perhaps the new text could require that full information about a LOCK > be returned in the lockdiscovery response to a LOCK, while information > about other locks is optional in the lockdiscovery response to a LOCK. This was in response to Jim Luther's explanation that his shipped client looked for the lock token of the newly created lock in the LOCK response. There were lots of +1's to this so I am amending the text for the next version. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 17:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiJ77-0000mQ-GT for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 17:10:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06244 for ; Fri, 2 Dec 2005 17:09:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiJ6Q-0001Z8-Br for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 22:10:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiJ6I-0001KO-4O for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 22:09:54 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiJ6E-0001CC-Si for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 22:09:54 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9411D1422AF for ; Fri, 2 Dec 2005 14:09:48 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31623-05 for ; Fri, 2 Dec 2005 14:09:48 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E4FF61422A6 for ; Fri, 2 Dec 2005 14:09:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> References: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7aee415fa04b4b5f318636ddc6674935@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Fri, 2 Dec 2005 14:09:44 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EiJ6E-0001CC-Si 87d6ff5005886ab6842bb79c74bd9b4e X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/7aee415fa04b4b5f318636ddc6674935@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10810 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 22:10:02 +0000 Content-Transfer-Encoding: 7bit I finally paged in enough context to be able to consider this set of changes. In particular, the justification, from bug text: "The difference here is that with the originally proposed extension, the client can tell whether the server evaluated the extension, while with the definition in RCF2518bis, it can't (it has no way knowing whether the server just ignored the extension, or happens to have no dead properties)." That's not quite true, the server MUST support dead-props if it advertises support for 'bis'. Besides, a smaller fix could be for the server to return an extra element saying "no-dead-props". That said, has anybody at all implemented this? If not, then I guess the change is harmless even if the justification isn't quite true. Lisa From w3c-dist-auth-request@frink.w3.org Fri Dec 02 17:14:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiJAK-0003DJ-IJ for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 17:14:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06778 for ; Fri, 2 Dec 2005 17:13:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiJ9i-0002Hq-EN for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 22:13:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiJ9g-0002HG-Nw for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 22:13:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiJ9c-0000td-Qh for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 22:13:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2MDKU7004351; Fri, 2 Dec 2005 14:13:20 -0800 Date: Fri, 2 Dec 2005 14:13:20 -0800 Message-Id: <200512022213.jB2MDKU7004351@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiJ9c-0000td-Qh de84d65f0362bcdf86421c8170dd5168 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/200512022213.jB2MDKU7004351@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10811 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 22:13:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From lisa@osafoundation.org 2005-12-02 14:13 ------- I don't see how the grammar allows this. Can you give more of an explanation? Perhaps what the grammer ought to be? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 18:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKDs-0007RO-22 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 18:21:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12312 for ; Fri, 2 Dec 2005 18:21:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiKCt-0001Zt-SG for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 23:20:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiKCT-0001YQ-Ly for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 23:20:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiKCQ-00027L-UU for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 23:20:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2NKIYs004434; Fri, 2 Dec 2005 15:20:18 -0800 Date: Fri, 2 Dec 2005 15:20:18 -0800 Message-Id: <200512022320.jB2NKIYs004434@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EiKCQ-00027L-UU d25c29f6aa48182248af3eb899b31a94 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 174] Terminology in 4.4: "namespace name in scope" X-Archived-At: http://www.w3.org/mid/200512022320.jB2NKIYs004434@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10813 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 23:20:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=174 Bug 174 depends on bug 10, which changed state. Bug 10 Summary: Round-tripping namespace decls in properties http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 18:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKDr-0007RM-T3 for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 18:21:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12310 for ; Fri, 2 Dec 2005 18:21:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiKD4-0001aL-2f for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 23:20:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiKCT-0001YS-Qy for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 23:20:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiKCQ-000276-Pu for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 23:20:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2NKHq9004420; Fri, 2 Dec 2005 15:20:17 -0800 Date: Fri, 2 Dec 2005 15:20:17 -0800 Message-Id: <200512022320.jB2NKHq9004420@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EiKCQ-000276-Pu 83f85787853fe9c5200cdf2d2927e187 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 22] attributes on properties X-Archived-At: http://www.w3.org/mid/200512022320.jB2NKHq9004420@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10814 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 23:20:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=22 Bug 22 depends on bug 10, which changed state. Bug 10 Summary: Round-tripping namespace decls in properties http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 02 18:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKDs-0007RN-1E for webdav-archive@megatron.ietf.org; Fri, 02 Dec 2005 18:21:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12309 for ; Fri, 2 Dec 2005 18:21:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiKCm-0001ZQ-3T for w3c-dist-auth-dist@listhub.w3.org; Fri, 02 Dec 2005 23:20:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiKCR-0001Xw-Du for w3c-dist-auth@listhub.w3.org; Fri, 02 Dec 2005 23:20:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiKCL-0000iH-NW for w3c-dist-auth@w3.org; Fri, 02 Dec 2005 23:20:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB2NKAl4004406; Fri, 2 Dec 2005 15:20:10 -0800 Date: Fri, 2 Dec 2005 15:20:10 -0800 Message-Id: <200512022320.jB2NKAl4004406@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiKCL-0000iH-NW fd4657c8e741397b988eaa3f83d2d2f7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512022320.jB2NKAl4004406@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10812 X-Loop: w3c-dist-auth@w3.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, 02 Dec 2005 23:20:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From lisa@osafoundation.org 2005-12-02 15:20 ------- A couple things may be missing. 1. I thought that for the attributes on the property name element, xml lang needed to be preserved, not xml:space? 2. I'm not clear if the information on children requires that only children attributes should be kept, or also namespace, name, value. I think the formatting makes that unclear. I'll take another stab on the wording, to be posted shortly, to iterate on this, just a next step. I also tried extending the example in a few ways to illustrate another couple things I thought were legal alterations, which if I'm wrong probably means we need to update the normative text. Reopening because this was never resolved, and leaving open because I suspect this will need further iteration. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From jwe@gkn.com Sat Dec 03 04:34:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiTmR-0000Av-HZ for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 04:34:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10085 for ; Sat, 3 Dec 2005 04:33:18 -0500 (EST) Received: from [84.237.176.196] (helo=1489208416) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EiU7F-00024g-Hz for webdav-archive@ietf.org; Sat, 03 Dec 2005 04:55:41 -0500 Received: from gkn.com (1489566640 [1461376864]) by gjimenez.com (Qmailv1) with ESMTP id 0279584E3A for ; Sat, 03 Dec 2005 05:40:37 -0500 Date: Sat, 03 Dec 2005 05:40:37 -0500 From: "Plunked B. Perjury" X-Mailer: The Bat! (v2.00.8) Personal X-Priority: 3 Message-ID: <9541796551.20051203054037@gkn.com> To: Webdav Subject: Software MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit All best software! Software taking a bite out of your budget? Try 0EM! New software on our site: Windows 2000 Professional - $59.95 Windows XP Professional - $69.95 Borland Delphi 7 Enterprise Edition (2CD) - $69.95 Plus! XP - $59.95 Borland Delphi 7 Enterprise Edition (2CD) - $69.95 Norton System Works 2003 - $59.95 Office 97 SR2 - $49.95 After Effects 6 - $69.95 Project 2003 Professional - $69.95 PhotoRetouch Pro 3.0 - $59.95 Plus! XP - $59.95 Visual Studio .NET Architect Edition (8CD) - $139.95 Dreamweaver MX 2004 $69.95 Norton System Works 2003 - $59.95 Our site: http://0vnoo864oiodjiivni0d50i0.broachkm.com From w3c-dist-auth-request@frink.w3.org Sat Dec 03 14:03:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EicfG-00073u-Um for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 14:03:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23562 for ; Sat, 3 Dec 2005 14:02:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EicdV-0007Nv-Be for w3c-dist-auth-dist@listhub.w3.org; Sat, 03 Dec 2005 19:01:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EicdN-0007NG-UX for w3c-dist-auth@listhub.w3.org; Sat, 03 Dec 2005 19:01:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EicdJ-0005PL-LB for w3c-dist-auth@w3.org; Sat, 03 Dec 2005 19:01:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB3IcmGD009053; Sat, 3 Dec 2005 10:38:48 -0800 Date: Sat, 3 Dec 2005 10:38:48 -0800 Message-Id: <200512031838.jB3IcmGD009053@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EicdJ-0005PL-LB 0a9e7eb8f4a778bc1fad01d2a5ab06e5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512031838.jB3IcmGD009053@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10815 X-Loop: w3c-dist-auth@w3.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, 03 Dec 2005 19:01:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-03 10:38 ------- Re 1) Good catch. Re 2) Rewrote that part. Please check. Also: added Impl Note regading the option of using escaped XML. 4.4 Property Values The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. A property is always presented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: The value of the property appears inside the property name element. It may be any kind of well-formed XML content, including both text- only and mixed content. In the latter case, servers MUST preserve certain aspects of the content. Using the terminology from [REC-XML- INFOSET], the following rules apply: On the property name Element Information Item itself: [namespace name], [local name], [attributes] named "xml:lang" when present on the property name element itself or it's closest ancestor and [children] of type element or character. On all other Element Information Items: [namespace name], [local name], [attributes] and [children] of type element or character. On Attribute Information Items: [namespace name], [local name], [attributes] and [normalized value]. On Character Information Items:: [character code]. Future revisions of this specification may also require to preserve namespace prefixes for child elements of the property elements, thus servers SHOULD preserve the [prefix] as well. [[preserve.more.xml: Feedback if we should ask implementors to preserve more in the future is appreciated (such as comments).]] XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. Note that a property only has one single value in one language (when specified). Also note that whitespace inside values is always significant, and that servers MUST NOT support overriding this using the xml:space attribute. 4.4.1 Example - Property with mixed content Consider a dead property such as: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has working way too long on the long-awaited revision of ]]>. (where an xml:lang attribute with value 'en' appeared on a parent element when setting the property) When retrieving the property, a server may return: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has working way too long on the long-awaited revision of <RFC2518>. Note: o The [prefix] for the property name itself was not preserved, being non-significant, o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and that attribute order has not been preserved, o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope), o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and o the comment item was stripped (as would have been a processing instruction item). Implementation note: There are cases such as editing scenarios where clients may require that XML content is preserved character-by-character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 03 16:21:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiepL-0002ER-5w for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 16:21:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04786 for ; Sat, 3 Dec 2005 16:21:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eient-0001oI-Pv for w3c-dist-auth-dist@listhub.w3.org; Sat, 03 Dec 2005 21:20:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eieni-0001nG-JY for w3c-dist-auth@listhub.w3.org; Sat, 03 Dec 2005 21:20:10 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Eienf-000615-Sj for w3c-dist-auth@w3.org; Sat, 03 Dec 2005 21:20:10 +0000 Received: (qmail invoked by alias); 03 Dec 2005 21:20:06 -0000 Received: from p508F930D.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.147.13] by mail.gmx.net (mp004) with SMTP; 03 Dec 2005 22:20:06 +0100 X-Authenticated: #1915285 Message-ID: <43920B9E.4010607@gmx.de> Date: Sat, 03 Dec 2005 22:18:22 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> <438F3216.8020206@gmx.de> <438F4E81.1070007@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eienf-000615-Sj d0e00a4e42b0022d72bde25931b34698 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/43920B9E.4010607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10816 X-Loop: w3c-dist-auth@w3.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, 03 Dec 2005 21:20:21 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > How about adding to the DOS section? > > > WebDAV servers need to be aware of the possibility of a denial of > service attack at all levels. The proper response to such an attack > MAY be to simply > drop the connection, or if the server is able to make a response, > the server MAY use a 400-level status request such as 400 (Bad > Request) and indicate why the request was refused (a 500-level > status response would indicate that the problem is with the server, > whereas unintentional DOS attacks are something the client is > capable of remedying). Hm. What is an "unintential DOS attack"? From w3c-dist-auth-request@frink.w3.org Sat Dec 03 18:19:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eigep-0004nC-K2 for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 18:19:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13198 for ; Sat, 3 Dec 2005 18:18:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EigdT-0000cZ-PH for w3c-dist-auth-dist@listhub.w3.org; Sat, 03 Dec 2005 23:17:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EigdL-0000bv-FS for w3c-dist-auth@listhub.w3.org; Sat, 03 Dec 2005 23:17:35 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EigdI-0005xG-LB for w3c-dist-auth@w3.org; Sat, 03 Dec 2005 23:17:34 +0000 Received: (qmail invoked by alias); 02 Dec 2005 22:17:30 -0000 Received: from p508F9AB7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.183] by mail.gmx.net (mp027) with SMTP; 02 Dec 2005 23:17:30 +0100 X-Authenticated: #1915285 Message-ID: <4390C7A4.10204@gmx.de> Date: Fri, 02 Dec 2005 23:16:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> <7aee415fa04b4b5f318636ddc6674935@osafoundation.org> In-Reply-To: <7aee415fa04b4b5f318636ddc6674935@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EigdI-0005xG-LB b7bf9f23a2b9aeaf3d1ea36ad86fb303 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/4390C7A4.10204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10817 X-Loop: w3c-dist-auth@w3.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, 03 Dec 2005 23:17:43 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > I finally paged in enough context to be able to consider this set of > changes. > In particular, the justification, from bug text: > > > "The difference here is that with the originally proposed extension, the > client > can tell whether the server evaluated the extension, while with the > definition > in RCF2518bis, it can't (it has no way knowing whether the server just > ignored > the extension, or happens to have no dead properties)." > > That's not quite true, the server MUST support dead-props if it advertises > support for 'bis'. Besides, a smaller fix could be for the server to > return an > extra element saying "no-dead-props". But if a server implements "bis", it MUST also support lots of other unrelated features. This is a question of granularity, and optimally, we won't need "bis" at all because all the things we add can be discovered individually (such as support for DAV:lockroot, for example). > That said, has anybody at all implemented this? If not, then I guess > the change is > harmless even if the justification isn't quite true. We have implemented it but found we're not using it in our own client for the reasons given above. So the new revised proposal isn't based on theory, it's based on running code. This is the approach we find is working, and we've been using it since 2002 when we initially proposed it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Dec 03 18:21:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eigh1-0005G9-8z for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 18:21:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13294 for ; Sat, 3 Dec 2005 18:20:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiggR-0001Iy-8a for w3c-dist-auth-dist@listhub.w3.org; Sat, 03 Dec 2005 23:20:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiggP-0001IK-Lb for w3c-dist-auth@listhub.w3.org; Sat, 03 Dec 2005 23:20:45 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EiggL-00056O-Jv for w3c-dist-auth@w3.org; Sat, 03 Dec 2005 23:20:45 +0000 Received: (qmail invoked by alias); 02 Dec 2005 22:20:29 -0000 Received: from p508F9AB7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.183] by mail.gmx.net (mp019) with SMTP; 02 Dec 2005 23:20:29 +0100 X-Authenticated: #1915285 Message-ID: <4390C857.1050904@gmx.de> Date: Fri, 02 Dec 2005 23:19:03 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV References: <200512022213.jB2MDJMe004343@ietf.cse.ucsc.edu> In-Reply-To: <200512022213.jB2MDJMe004343@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EiggL-00056O-Jv 01f60018f6c1e5819fa7d6444d32fef4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/4390C857.1050904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10818 X-Loop: w3c-dist-auth@w3.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, 03 Dec 2005 23:20:47 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de > > > > ------- Additional Comments From lisa@osafoundation.org 2005-12-02 14:13 ------- > I don't see how the grammar allows this. Can you give more of an explanation? > Perhaps what the grammer ought to be? Explanation: Suggested change: state that LWS is not allowed here, just like in the grammar for "opaquelocktoken". Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Sat Dec 03 21:20:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EijUg-00060C-P4 for webdav-archive@megatron.ietf.org; Sat, 03 Dec 2005 21:20:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24829 for ; Sat, 3 Dec 2005 21:20:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EijTU-0000FF-KH for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 02:19:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EijTN-0000Ds-5w for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 02:19:29 +0000 Received: from adsl-68-126-173-45.dsl.snfc21.pacbell.net ([68.126.173.45] helo=joliet-jake.wsanchez.net) by maggie.w3.org with esmtp (Exim 4.50) id 1EijTB-0005ef-6p for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 02:19:28 +0000 Received: from [68.126.173.43] (adsl-68-126-173-43.dsl.snfc21.pacbell.net [68.126.173.43]) by joliet-jake.wsanchez.net (Postfix) with ESMTP id 0A8571B5B1D; Sat, 3 Dec 2005 15:12:05 -0800 (PST) In-Reply-To: <44f343732127f2b6a16a63e407637eae@osafoundation.org> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Julian Reschke , WebDAV Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Sat, 3 Dec 2005 15:11:56 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EijTB-0005ef-6p 74843d004fbd81089aa3f810a0b4124c X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/CD416928-1079-4F39-9433-30C207171DE5@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10819 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 02:19:36 +0000 Content-Transfer-Encoding: quoted-printable On Nov 29, 2005, at 1:43 PM, Lisa Dusseault wrote: > On Nov 29, 2005, at 1:12 PM, Julian Reschke wrote: >> >> Wilfredo S=E1nchez Vega wrote: >>> Question for you. >>> Apache HTTPD emits a weak etag for a file resource if the =20 >>> timestamp on the file is the same as the current time (one second =20= >>> accuracy) and a strong etag otherwise. >>> The reason for that logic, as I understand it, is that because =20 >>> the etag generation depends on the timestamp and that the file =20 >>> may change multiple times within a one-second period, an etag =20 >>> generated from a timestamp matching the current time isn't reliable. >> >> Finally a good explanation. > > Do other people consider this behavior to be incorrect according to =20= > the spec? (I'm assuming the explanation is correct and it aligns =20 > with what I've seen). But it seems that within-second changes do =20 > not guarantee "semantic equivalence" as required by HTTP. > > Lisa My best read of the spec leads me to believe that this is not =20 correct as per the spec. A more correct solution may be to append something to the strong =20 ETag if it is in the same timespan as now instead of using a weak =20 ETag in that case. However, this doesn't address the problem of correctly changing =20 the ETag if multiple changes occur within a subsecond timespan. But =20 then, neither does the weak ETag trick. If people agree that Apache HTTPd is incorrect here, I'll be happy =20= to implement, lobby for and commit an appropriate change for future =20 versions. -wsv From w3c-dist-auth-request@frink.w3.org Sun Dec 04 00:50:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eimlc-0008LL-Hk for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 00:50:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07403 for ; Sun, 4 Dec 2005 00:49:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EimkP-0002zO-Ee for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 05:49:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EimkH-0002yM-Vz for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 05:49:10 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EimkC-00023Q-PD for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 05:49:09 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E51814228D; Sat, 3 Dec 2005 21:48:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19194-10; Sat, 3 Dec 2005 21:48:57 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F970142289; Sat, 3 Dec 2005 21:48:55 -0800 (PST) In-Reply-To: <43920B9E.4010607@gmx.de> References: <200511302242.jAUMgNWH017058@ietf.cse.ucsc.edu> <438F3216.8020206@gmx.de> <438F4E81.1070007@gmx.de> <43920B9E.4010607@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1ffdf7d0b0fb7ba78d7b727f4302c222@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Sat, 3 Dec 2005 21:48:32 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EimkC-00023Q-PD 12fe104f616e5c57b7bca7c1889873ec X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/1ffdf7d0b0fb7ba78d7b727f4302c222@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10820 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 05:49:17 +0000 Content-Transfer-Encoding: 7bit Perhaps there's a better phrase for that -- I meant a client request that the server decided to consider a DOS attack but the client didn't. E.g. a PROPFIND depth infinity on root. Lisa On Dec 3, 2005, at 1:18 PM, Julian Reschke wrote: > > Lisa Dusseault wrote: >> How about adding to the DOS section? >> WebDAV servers need to be aware of the possibility of a denial of >> service attack at all levels. The proper response to such an >> attack MAY be to simply >> drop the connection, or if the server is able to make a >> response, >> the server MAY use a 400-level status request such as 400 (Bad >> Request) and indicate why the request was refused (a 500-level >> status response would indicate that the problem is with the >> server, >> whereas unintentional DOS attacks are something the client is >> capable of remedying). > > > Hm. What is an "unintential DOS attack"? > > From w3c-dist-auth-request@frink.w3.org Sun Dec 04 04:11:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EipuO-0004bC-MD for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 04:11:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20807 for ; Sun, 4 Dec 2005 04:10:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EipsH-0006ty-Is for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 09:09:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eips9-0006sH-A0 for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 09:09:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eips6-0000pz-4e for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 09:09:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB499Ew8010715; Sun, 4 Dec 2005 01:09:14 -0800 Date: Sun, 4 Dec 2005 01:09:14 -0800 Message-Id: <200512040909.jB499Ew8010715@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eips6-0000pz-4e 9fe637ba961022089178f12d8b11bb34 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/200512040909.jB499Ew8010715@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10821 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 09:09:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-04 01:09 ------- Explanation: Suggested change: state that LWS is not allowed here, just like in the grammar for "opaquelocktoken". ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 04:14:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eipwh-0005OC-3V for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 04:14:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20879 for ; Sun, 4 Dec 2005 04:13:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eipw8-0008F5-ES for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 09:13:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eipw6-0008EI-NE for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 09:13:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eipw3-0002BI-BF for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 09:13:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB49DJPS010738; Sun, 4 Dec 2005 01:13:19 -0800 Date: Sun, 4 Dec 2005 01:13:19 -0800 Message-Id: <200512040913.jB49DJPS010738@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eipw3-0002BI-BF 842f9befaadad3aa09c5b81fdd488c05 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200512040913.jB49DJPS010738@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10822 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 09:13:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-04 01:13 ------- We discussed this during the conference call: 5xx is a server error, in particular 503 means "not now but maybe later". If a server detects a DOS attack, that's the last thing it would want to tell the client. Servers are free to do whatever they want should they detect a DOS attack. If they want to be friendly, a 4xx with explanation would be right. Please alo note that the current draft is missing one of the changes I made, namely (at the end of Section 8.1.1): "Note that processing XML submitted by an untrusted source may cause risks connected to privacy, security, and service quality (see Section 19). Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance with a 400 (Bad Request) status code and an optional response body explaining the problem." () ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 06:19:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eiru1-0004JO-Cb for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 06:19:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00380 for ; Sun, 4 Dec 2005 06:18:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eirt5-00009M-LV for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 11:18:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eirt3-00008c-M1 for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 11:18:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eirt1-0005aS-14 for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 11:18:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4BINSH011059; Sun, 4 Dec 2005 03:18:23 -0800 Date: Sun, 4 Dec 2005 03:18:23 -0800 Message-Id: <200512041118.jB4BINSH011059@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eirt1-0005aS-14 4d72001a4a41ce91c25ceef22f834307 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512041118.jB4BINSH011059@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10824 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 11:18:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|REOPENED |NEW ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 06:19:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eiru2-0004Jf-7B for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 06:19:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00381 for ; Sun, 4 Dec 2005 06:18:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eirsd-00007H-TL for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 11:18:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EirsW-00006V-Dn for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 11:18:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EirsT-00036Q-5M for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 11:17:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4BHsUl011042; Sun, 4 Dec 2005 03:17:54 -0800 Date: Sun, 4 Dec 2005 03:17:54 -0800 Message-Id: <200512041117.jB4BHsUl011042@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EirsT-00036Q-5M 64b54e6e47ffd684541d31acba276908 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512041117.jB4BHsUl011042@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10823 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 11:18:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-04 03:17 ------- Thanks for the changes in the 2005-12-03 draft, but there are still some problems, the changes below attempt to remove them. OLD: 12.1 Response headers Use of the Location header with the Multi-Status response is intentionally undefined. Note that this specification does not define a way to redirect requests for individual resources within the scope of a Multi-Status response. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response. NEW: (remove that section) Section 12., para. 12: OLD: The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. The Multi-Status response syntax as defined in RFC2518 did not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in the body of Multi-Status responses. If a client receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource. NEW: The 300-303, 305 and 307 responses defined in HTTP 1.1 normally take a Location header to indicate where the client should make the request. In [RFC2518], the multistatus response format did not define a container for the Location header information, so servers MAY choose not to use these status codes in the body of Multi-Status responses. In this case, a client receives this status code in Multi-Status, it may reissue the request to the individual resource, so that the server can issue a response with a Location header for that resource. Section 12., para. 13: OLD: Additionally, this specification defines a new element that servers MAY use in the response element to provide a location value in Multi- Status (see Section 13.29). NEW: Additionally, this specification defines a new element that servers may use in the response element to provide a location value inside a multistatus response (see Section 13.9). (we're not making a nomative statement here, so MAY is wrong; also fixes the reference) Section 13., para. 41: OLD: Purpose: In normal responses (not Multi-Status), some status codes go along with a Location header. When these status codes are used in a Multi-Status response, this element is used instead. NEW: Purpose: HTTP defines the 'Location' response header (see [RFC2616], Section 14.30) for use with some HTTP status codes (such as 201 and the 300 series codes). When these status codes are used inside a 'multistatus' response body, this element can be used to provide the accompanying 'Location' header. (among other things, include a ref to the right RFC2616 section) Section 13., para. 42: OLD: Description: Contains a single href element with the same URL that would be used in a Location header. NEW: Description: Contains a single href element with the same value that would be used in a Location header. (Location is not restricted to be a URL) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 09:10:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiuZZ-0006RP-LX for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 09:10:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13718 for ; Sun, 4 Dec 2005 09:09:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiuYG-0002kv-TL for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 14:09:16 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiuY9-0002i1-Ar for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 14:09:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiuY6-00014I-6j for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 14:09:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4E93FA021849; Sun, 4 Dec 2005 06:09:03 -0800 Date: Sun, 4 Dec 2005 06:09:03 -0800 Message-Id: <200512041409.jB4E93FA021849@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiuY6-00014I-6j 4501bfe707efbe3b3336ecf590ed989c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512041409.jB4E93FA021849@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10825 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 14:09:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-04 06:09 ------- As far as I remember, there was also consensus to simply state that relative references are always relative to the Request-URI, independant of whether there was a Destination header present. My suggestion is to replace the whole paragraph with the text below, using proper terminology from RFC3986, and also giving an example. See also marked-up version, following links from . 12.1 URL handling The Multi-Status response format may contain 'href' elements (Section 13.7) in multiple places, namely as child element of 'response' elements (Section 13.24). When the contents of an 'href' element contains a Relative Reference ([RFC3986], Section 4.2), it is relative to the Request-URI of the HTTP request. Interoperability experience shows that many clients do not fully implement the Reference Resolution defined in Section 5 of [RFC3986]. Therefore servers SHOULD NOT use 'href' values that: o use forms of relative references other than absolute paths (see "absolute-path", [RFC3986], Section 3.3), o use dot-segments ("." or ".."), o use a notation for the authority part of a URI (see "authority", [RFC3986], Section 3.2) other the one used in the HTTP request or o use a different notation for the part of the path that identifies the Request-URI. URLs for collections appearing in the results SHOULD end in a '/' character. 12.1.1 Example for correct URL handling Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below: >>Request: PROPFIND /sample/ HTTP/1.1 Host: example.com Depth: 1 In this case, the server should return 'href' elements containing either o 'http://example.com/sample/' and 'http://example.com/sample/a%20test', or o '/example.com/sample/' and '/example.com/sample/a%20test'. Note that even though the server may be storing the member resource internally as 'a test', it must be percent-encoded when used inside a URI reference (see [RFC3986], Section 2.1). Also note that a legal URI may still contain characters that need to be escaped within XML character data, such as the ampersand character. Also note the proposed change to the subsection about the 'href' element. 13.7 href XML Element Name: href Purpose: Identifies the content of the element as a URI reference. Some uses of 'href' limit the URI to be a HTTP URL to a WebDAV resource. Refer to the specification text where 'href' is used to see what limitations apply in each case. Value: URI reference (see Section 4.1 of [RFC3986]) Extensibility: MAY be extended with attributes which SHOULD be ignored. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 11:28:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eiwj1-0007OF-Jd for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 11:28:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24800 for ; Sun, 4 Dec 2005 11:27:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eiwhi-0002wI-38 for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 16:27:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EiwhY-0002uJ-MV for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 16:27:01 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EiwhV-0001Gc-Fl for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 16:26:59 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0979014228A; Sun, 4 Dec 2005 08:26:55 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26079-02; Sun, 4 Dec 2005 08:26:54 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 664AE142289; Sun, 4 Dec 2005 08:26:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <200512040909.jB499ET7010711@ietf.cse.ucsc.edu> References: <200512040909.jB499ET7010711@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1f05a53936892c281e1cbebe22131440@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Sun, 4 Dec 2005 08:26:48 -0800 To: Julian Reschke , WebDAV WG X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EiwhV-0001Gc-Fl 647413ea85f06239cd8d1ee4bb6bd1ce X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/1f05a53936892c281e1cbebe22131440@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10826 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 16:27:10 +0000 Content-Transfer-Encoding: 7bit If I understand correctly, that's not the only place where RFC2616's LWS rules get us into trouble. TimeOut = "Timeout" ":" 1#TimeType TimeType = ("Second-" DAVTimeOutVal | "Infinite") DAVTimeOutVal = 1*digit Applying the 2616 word-based grammer to those rules, we could have Timeout headers like Timeout: Second- 1111 Timeout: Second-1 1 1 1 Is my understanding of 2616 BNF grammar correct? I'm not sure if 1*DIGIT is one token or several, so it's not entirely clear to me if the second example is allowed. Certainly the intent of 2616 is not to allow that because values like Content-Length are defined as 1*DIGIT. Lisa On Dec 4, 2005, at 1:09 AM, bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 > > julian.reschke@greenbytes.de changed: > > What |Removed |Added > ----------------------------------------------------------------------- > ----- > AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-12-04 01:09 ------- > Explanation: > > > Suggested change: state that LWS is not allowed here, just like in the > grammar for "opaquelocktoken". > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 11:44:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eiwy4-0002ax-Hq for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 11:44:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25959 for ; Sun, 4 Dec 2005 11:43:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EiwxN-0008B0-GX for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 16:43:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EiwxL-0008AL-VF for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 16:43:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EiwxK-0000op-2f for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 16:43:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4GhH2K022012; Sun, 4 Dec 2005 08:43:17 -0800 Date: Sun, 4 Dec 2005 08:43:17 -0800 Message-Id: <200512041643.jB4GhH2K022012@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EiwxK-0000op-2f c48e2f63fa06f7007c12f90ed9a87c15 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512041643.jB4GhH2K022012@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10827 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 16:43:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 ------- Additional Comments From lisa@osafoundation.org 2005-12-04 08:43 ------- A bunch of good suggestions here, however I've taken the liberty of rewriting some sections more and some sections less in order to fine-tune. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 12:02:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EixFd-0007VH-87 for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:02:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27470 for ; Sun, 4 Dec 2005 12:01:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EixEu-0006VR-3d for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 17:01:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EixEp-0006UZ-N7 for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 17:01:23 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EixEi-0003SJ-An for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 17:01:23 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B91914228A for ; Sun, 4 Dec 2005 09:01:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10003-03 for ; Sun, 4 Dec 2005 09:01:13 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CB999142289 for ; Sun, 4 Dec 2005 09:01:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <8e2248ab337b2e0fba769b53a3f3e6f6@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDAV WG From: Lisa Dusseault Date: Sun, 4 Dec 2005 09:01:06 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EixEi-0003SJ-An a13727b7d9c56691518958666be0fe18 X-Original-To: w3c-dist-auth@w3.org Subject: Proposal for response URLs in Multi-Status: always based on Request-URI X-Archived-At: http://www.w3.org/mid/8e2248ab337b2e0fba769b53a3f3e6f6@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10828 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 17:01:28 +0000 Content-Transfer-Encoding: 7bit We've discussed the allowability of relative URLs in the 'href' element in the 'response' elements of Multi-Status responses. I'll call each of these a "response URL" for now. I believe our conclusion was that in response to PROPFIND, response URLs which are relative URLs MUST be relative to the Request-URI, and those which are absolute MUST begin with the Request-URI (exactly the same scheme, host, port and path). For MOVE and COPY, one could consider relative URLs as being resolved against the Destination header instead of the Request-URI, but I don't believe that anybody does this. One could also imagine seeing absolute URLs that were part of the Destination namespace rather than the Request-URI namespace, but again, I don't believe that anybody does this. Thus, are there any objections if we treat all Multi-Status responses the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH? That the response URLs MUST always be in the Request-URI namespace, and if relative, be resolved against the Request-URI? Would making this requirement a MUST for all Multi-Status responses break any extensions using Multi-Status -- or do we limit the requirement to Multi-Status responses to methods defined in RFC2518bis only? Lisa From w3c-dist-auth-request@frink.w3.org Sun Dec 04 12:08:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EixLx-00011w-5k for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:08:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28100 for ; Sun, 4 Dec 2005 12:07:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EixLK-0008OF-1Z for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 17:08:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EixLI-0008NQ-6r for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 17:08:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EixLE-0007ms-VB for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 17:08:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4H7wPZ022046; Sun, 4 Dec 2005 09:07:58 -0800 Date: Sun, 4 Dec 2005 09:07:58 -0800 Message-Id: <200512041707.jB4H7wPZ022046@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EixLE-0007ms-VB c1e3a49d1ac9d13d163b82e750ccda40 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512041707.jB4H7wPZ022046@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10829 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 17:08:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 ------- Additional Comments From lisa@osafoundation.org 2005-12-04 09:07 ------- I'm still not clear on a few things - Is the requirement for absolute URLs that they be "inside" (I mean "inside the namespace of") the Request-URI? Will that break extensions of Multi-Status? - Can't relative URLs be relative paths? I've sent mail to the list about the first of these ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 12:14:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EixRF-0002rT-3r for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:14:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28482 for ; Sun, 4 Dec 2005 12:13:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EixQY-0001gs-Ma for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 17:13:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EixQW-0001fu-Tp for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 17:13:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EixQT-0007hD-SJ for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 17:13:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4HDLfa022065; Sun, 4 Dec 2005 09:13:21 -0800 Date: Sun, 4 Dec 2005 09:13:21 -0800 Message-Id: <200512041713.jB4HDLfa022065@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EixQT-0007hD-SJ e0520e87ca90d80945613a44dda6fe9c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200512041713.jB4HDLfa022065@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10830 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 17:13:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-04 09:13 ------- Done. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 12:16:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EixTd-0003QS-Kw for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:16:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28619 for ; Sun, 4 Dec 2005 12:15:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EixT2-0003vc-55 for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 17:16:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EixSz-0003uE-SF for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 17:16:02 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EixSx-000071-6k for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 17:16:01 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8A5D614227B; Sun, 4 Dec 2005 09:15:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16099-01; Sun, 4 Dec 2005 09:15:47 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 03C1D142275; Sun, 4 Dec 2005 09:15:46 -0800 (PST) In-Reply-To: <4390C7A4.10204@gmx.de> References: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> <7aee415fa04b4b5f318636ddc6674935@osafoundation.org> <4390C7A4.10204@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Lisa Dusseault Date: Sun, 4 Dec 2005 09:15:44 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EixSx-000071-6k 7acc1c5bb5b883b846a3b57f5d991878 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/fb2d7d8d8f59e4b7c9b1ba9dae74b198@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10831 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 17:16:04 +0000 Content-Transfer-Encoding: 7bit On Dec 2, 2005, at 2:16 PM, Julian Reschke wrote: > > Lisa Dusseault wrote: >> I finally paged in enough context to be able to consider this set of >> changes. >> In particular, the justification, from bug text: >> >> "The difference here is that with the originally proposed extension, >> the client >> can tell whether the server evaluated the extension, while with the >> definition >> in RCF2518bis, it can't (it has no way knowing whether the server >> just ignored >> the extension, or happens to have no dead properties)." >> That's not quite true, the server MUST support dead-props if it >> advertises >> support for 'bis'. Besides, a smaller fix could be for the server >> to return an >> extra element saying "no-dead-props". > > But if a server implements "bis", it MUST also support lots of other > unrelated features. This is a question of granularity, and optimally, > we won't need "bis" at all because all the things we add can be > discovered individually (such as support for DAV:lockroot, for > example). This isn't my idea of optimality. Servers should implement all of RFC2518bis, not cherry-pick bits and pieces. Lisa From w3c-dist-auth-request@frink.w3.org Sun Dec 04 12:33:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eixk4-000073-3c for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 12:33:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00078 for ; Sun, 4 Dec 2005 12:32:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eixiv-0000pL-13 for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 17:32:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eixis-0000oG-Hw for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 17:32:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eixip-0008Eo-Nn for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 17:32:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB4HWNG6022089; Sun, 4 Dec 2005 09:32:23 -0800 Date: Sun, 4 Dec 2005 09:32:23 -0800 Message-Id: <200512041732.jB4HWNG6022089@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eixip-0008Eo-Nn c869d330a81f6d5c9bd776f68faa02e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512041732.jB4HWNG6022089@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10832 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 17:32:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From lisa@osafoundation.org 2005-12-04 09:32 ------- We're definitely getting closer... - I believe any "xml:lang" value in scope must be preserved, not just on the property element or its parent. - I am adding "in the value" to some of these to be clear where the Info Items are. - Does it make sense to say that on attributes, [attributes] must be preserved? I think this was a cut-and-paste error so I am leaving it out. - Did you consider whether [references] ought to be preserved on attributes? What's the consequence if they're not? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 04 16:19:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej1Gd-00080B-Pw for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 16:19:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18261 for ; Sun, 4 Dec 2005 16:18:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ej1Eq-00073R-IJ for w3c-dist-auth-dist@listhub.w3.org; Sun, 04 Dec 2005 21:17:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ej1Eg-0006zf-DW for w3c-dist-auth@listhub.w3.org; Sun, 04 Dec 2005 21:17:30 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ej1Ed-0003jl-6b for w3c-dist-auth@w3.org; Sun, 04 Dec 2005 21:17:29 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB4LHNpI022702 for ; Sun, 4 Dec 2005 16:17:23 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB4LHNw6118542 for ; Sun, 4 Dec 2005 16:17:23 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jB4LHNW4013392 for ; Sun, 4 Dec 2005 16:17:23 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jB4LHNDt013389 for ; Sun, 4 Dec 2005 16:17:23 -0500 In-Reply-To: <8e2248ab337b2e0fba769b53a3f3e6f6@osafoundation.org> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 4 Dec 2005 16:17:23 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/04/2005 16:17:23, Serialize complete at 12/04/2005 16:17:23 Content-Type: multipart/alternative; boundary="=_alternative 0074F2CC852570CD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Ej1Ed-0003jl-6b 032bdd2faaef8099f8b61f19053972ae X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for response URLs in Multi-Status: always based on Request-URI X-Archived-At: http://www.w3.org/mid/OFEE20606F.C3D0C0D9-ON852570CD.0074CE6C-852570CD.0074F312@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10833 X-Loop: w3c-dist-auth@w3.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, 04 Dec 2005 21:17:40 +0000 This is a multipart message in MIME format. --=_alternative 0074F2CC852570CD_= Content-Type: text/plain; charset="US-ASCII" +1 for MUST on the relative URI in a multistatus being interpreted relative to the Request-URI. Cheers, Geoff Lisa wrote on 12/04/2005 12:01:06 PM: > > > We've discussed the allowability of relative URLs in the 'href' element > in the 'response' elements of Multi-Status responses. I'll call each > of these a "response URL" for now. I believe our conclusion was that > in response to PROPFIND, response URLs which are relative URLs MUST be > relative to the Request-URI, and those which are absolute MUST begin > with the Request-URI (exactly the same scheme, host, port and path). > > For MOVE and COPY, one could consider relative URLs as being resolved > against the Destination header instead of the Request-URI, but I don't > believe that anybody does this. One could also imagine seeing absolute > URLs that were part of the Destination namespace rather than the > Request-URI namespace, but again, I don't believe that anybody does > this. > > Thus, are there any objections if we treat all Multi-Status responses > the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH? > That the response URLs MUST always be in the Request-URI namespace, and > if relative, be resolved against the Request-URI? > > Would making this requirement a MUST for all Multi-Status responses > break any extensions using Multi-Status -- or do we limit the > requirement to Multi-Status responses to methods defined in RFC2518bis > only? > > Lisa > > --=_alternative 0074F2CC852570CD_= Content-Type: text/html; charset="US-ASCII"
+1 for MUST on the relative URI in a multistatus being interpreted
relative to the Request-URI.

Cheers,
Geoff

Lisa wrote on 12/04/2005 12:01:06 PM:

>
>
> We've discussed the allowability of relative URLs in the 'href' element
> in the 'response' elements of Multi-Status responses.  I'll call each
> of these a "response URL" for now.  I believe our conclusion was that
> in response to PROPFIND, response URLs which are relative URLs MUST be
> relative to the Request-URI, and those which are absolute MUST begin
> with the Request-URI (exactly the same scheme, host, port and path).
>
> For MOVE and COPY, one could consider relative URLs as being resolved
> against the Destination header instead of the Request-URI, but I don't
> believe that anybody does this.  One could also imagine seeing absolute
> URLs that were part of the Destination namespace rather than the
> Request-URI namespace, but again, I don't believe that anybody does
> this.
>
> Thus, are there any objections if we treat all Multi-Status responses
> the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH?  
> That the response URLs MUST always be in the Request-URI namespace, and
> if relative, be resolved against the Request-URI?
>
> Would making this requirement a MUST for all Multi-Status responses
> break any extensions using Multi-Status -- or do we limit the
> requirement to Multi-Status responses to methods defined in RFC2518bis
> only?
>
> Lisa
>
>
--=_alternative 0074F2CC852570CD_=-- From w3c-dist-auth-request@frink.w3.org Sun Dec 04 19:28:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej4Ds-0008Nv-C1 for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 19:28:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05281 for ; Sun, 4 Dec 2005 19:28:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ej4CX-0008Tm-H9 for w3c-dist-auth-dist@listhub.w3.org; Mon, 05 Dec 2005 00:27:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ej4CP-0008Ng-Aj for w3c-dist-auth@listhub.w3.org; Mon, 05 Dec 2005 00:27:21 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Ej4CI-0002dx-Mv for w3c-dist-auth@w3.org; Mon, 05 Dec 2005 00:27:20 +0000 Received: (qmail invoked by alias); 05 Dec 2005 00:27:10 -0000 Received: from p508F83E8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.232] by mail.gmx.net (mp032) with SMTP; 05 Dec 2005 01:27:10 +0100 X-Authenticated: #1915285 Message-ID: <4393891D.2090504@gmx.de> Date: Mon, 05 Dec 2005 01:26:05 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <8e2248ab337b2e0fba769b53a3f3e6f6@osafoundation.org> In-Reply-To: <8e2248ab337b2e0fba769b53a3f3e6f6@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ej4CI-0002dx-Mv 1cfee426f1a6fd615c10714bc6653132 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for response URLs in Multi-Status: always based on Request-URI X-Archived-At: http://www.w3.org/mid/4393891D.2090504@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10834 X-Loop: w3c-dist-auth@w3.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, 05 Dec 2005 00:27:29 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > We've discussed the allowability of relative URLs in the 'href' element I think we should stick with proper terminology: there is no such thing as a relative URL, RFC3986 calls these things "relative references". > in the 'response' elements of Multi-Status responses. I'll call each of > these a "response URL" for now. I believe our conclusion was that in > response to PROPFIND, response URLs which are relative URLs MUST be > relative to the Request-URI, and those which are absolute MUST begin > with the Request-URI (exactly the same scheme, host, port and path). Yes. > For MOVE and COPY, one could consider relative URLs as being resolved > against the Destination header instead of the Request-URI, but I don't > believe that anybody does this. One could also imagine seeing absolute > URLs that were part of the Destination namespace rather than the > Request-URI namespace, but again, I don't believe that anybody does this. > > Thus, are there any objections if we treat all Multi-Status responses > the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH? > That the response URLs MUST always be in the Request-URI namespace, and > if relative, be resolved against the Request-URI? No. Of course a multistatus upon COPY/MOVE can contain URLs below the destination URI, not the Request-URI. And other methods such as REPORT and SEARCH may return URLs completely independently of the Request-URI. But yes, if an is a relative reference, it is always relative to the Request-URI. That was certainly the consensus each time this was discussed. > Would making this requirement a MUST for all Multi-Status responses > break any extensions using Multi-Status -- or do we limit the > requirement to Multi-Status responses to methods defined in RFC2518bis > only? See above, and please review (you do remember that we agreed on the conference call that I should make a proposal for spec text, right?). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Dec 04 19:29:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej4Ei-0000L7-UB for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 19:29:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05361 for ; Sun, 4 Dec 2005 19:28:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ej4E8-0000dQ-5s for w3c-dist-auth-dist@listhub.w3.org; Mon, 05 Dec 2005 00:29:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ej4E5-0000ci-Rq for w3c-dist-auth@listhub.w3.org; Mon, 05 Dec 2005 00:29:05 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Ej4E3-0006iw-1K for w3c-dist-auth@w3.org; Mon, 05 Dec 2005 00:29:04 +0000 Received: (qmail invoked by alias); 05 Dec 2005 00:28:57 -0000 Received: from p508F83E8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.232] by mail.gmx.net (mp014) with SMTP; 05 Dec 2005 01:28:57 +0100 X-Authenticated: #1915285 Message-ID: <43938989.6000909@gmx.de> Date: Mon, 05 Dec 2005 01:27:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <200512040909.jB499ET7010711@ietf.cse.ucsc.edu> <1f05a53936892c281e1cbebe22131440@osafoundation.org> In-Reply-To: <1f05a53936892c281e1cbebe22131440@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ej4E3-0006iw-1K e81bdfd53fde8ff7b9ca4b8f312f54e3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/43938989.6000909@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10835 X-Loop: w3c-dist-auth@w3.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, 05 Dec 2005 00:29:08 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > If I understand correctly, that's not the only place where RFC2616's LWS > rules get us into trouble. > > TimeOut = "Timeout" ":" 1#TimeType > TimeType = ("Second-" DAVTimeOutVal | "Infinite") > DAVTimeOutVal = 1*digit > > Applying the 2616 word-based grammer to those rules, we could have > Timeout headers like > > Timeout: Second- 1111 Yes. > Timeout: Second-1 1 1 1 No. > Is my understanding of 2616 BNF grammar correct? I'm not sure if > 1*DIGIT is one token or several, so it's not entirely clear to me if the > second example is allowed. Certainly the intent of 2616 is not to allow > that because values like Content-Length are defined as 1*DIGIT. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Dec 04 19:31:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej4GK-0000cE-9J for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 19:31:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05436 for ; Sun, 4 Dec 2005 19:30:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ej4Fl-0002mm-Ub for w3c-dist-auth-dist@listhub.w3.org; Mon, 05 Dec 2005 00:30:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ej4Fk-0002lf-74 for w3c-dist-auth@listhub.w3.org; Mon, 05 Dec 2005 00:30:48 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Ej4Fi-0007BH-2P for w3c-dist-auth@w3.org; Mon, 05 Dec 2005 00:30:47 +0000 Received: (qmail invoked by alias); 05 Dec 2005 00:30:45 -0000 Received: from p508F83E8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.131.232] by mail.gmx.net (mp028) with SMTP; 05 Dec 2005 01:30:45 +0100 X-Authenticated: #1915285 Message-ID: <439389F4.4080007@gmx.de> Date: Mon, 05 Dec 2005 01:29:40 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <200511261907.jAQJ73R3021118@ietf.cse.ucsc.edu> <7aee415fa04b4b5f318636ddc6674935@osafoundation.org> <4390C7A4.10204@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ej4Fi-0007BH-2P 038cd1181e8491f53140e9a5bb2df501 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/439389F4.4080007@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10836 X-Loop: w3c-dist-auth@w3.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, 05 Dec 2005 00:30:49 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> But if a server implements "bis", it MUST also support lots of other >> unrelated features. This is a question of granularity, and optimally, >> we won't need "bis" at all because all the things we add can be >> discovered individually (such as support for DAV:lockroot, for example). > > This isn't my idea of optimality. Servers should implement all of > RFC2518bis, not cherry-pick bits and pieces. On the other hand, putting a set of totally unrelated changes into one single bag, and hoping that server implementors will be thrilled to implement all of this or nothing at all isn't realistic either. In particular if this set contains stuff that can't be implemented by some. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Dec 04 20:41:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej5MO-0007g5-F9 for webdav-archive@megatron.ietf.org; Sun, 04 Dec 2005 20:41:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10888 for ; Sun, 4 Dec 2005 20:40:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ej5LD-0002OG-1k for w3c-dist-auth-dist@listhub.w3.org; Mon, 05 Dec 2005 01:40:31 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ej5L6-0002Mh-Es for w3c-dist-auth@listhub.w3.org; Mon, 05 Dec 2005 01:40:24 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ej5L2-0008Iv-FP for w3c-dist-auth@w3.org; Mon, 05 Dec 2005 01:40:23 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB51eEGX031235 for ; Sun, 4 Dec 2005 20:40:14 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB51eEw6098540 for ; Sun, 4 Dec 2005 20:40:14 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jB51eETF018132 for ; Sun, 4 Dec 2005 20:40:14 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jB51eELs018124 for ; Sun, 4 Dec 2005 20:40:14 -0500 In-Reply-To: <4393891D.2090504@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 4 Dec 2005 20:40:18 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/04/2005 20:40:14, Serialize complete at 12/04/2005 20:40:14 Content-Type: multipart/alternative; boundary="=_alternative 00092EC6852570CE_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ej5L2-0008Iv-FP e95a369731475e1791eed2f041159bed X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for response URLs in Multi-Status: always based on Request-URI X-Archived-At: http://www.w3.org/mid/OFA4EAFE40.7F8CDC0E-ON852570CE.0003AF63-852570CE.00092EFD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10837 X-Loop: w3c-dist-auth@w3.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, 05 Dec 2005 01:40:31 +0000 This is a multipart message in MIME format. --=_alternative 00092EC6852570CE_= Content-Type: text/plain; charset="US-ASCII" Note that my +1 was for interpreting relative references in the DAV:response elements as being relative to the Request URI, but as Julian states below, there should be no restriction on a URI that appears in the DAV:response element (i.e. they can reference any resource, not just resources under the Request URI). I vote that we adopt Julian's text. Cheers, Geoff Julian wrote on 12/04/2005 07:26:05 PM: > > Lisa Dusseault wrote: > > > > > > We've discussed the allowability of relative URLs in the 'href' element > > I think we should stick with proper terminology: there is no such thing > as a relative URL, RFC3986 calls these things "relative references". > > > in the 'response' elements of Multi-Status responses. I'll call each of > > these a "response URL" for now. I believe our conclusion was that in > > response to PROPFIND, response URLs which are relative URLs MUST be > > relative to the Request-URI, and those which are absolute MUST begin > > with the Request-URI (exactly the same scheme, host, port and path). > > Yes. > > > For MOVE and COPY, one could consider relative URLs as being resolved > > against the Destination header instead of the Request-URI, but I don't > > believe that anybody does this. One could also imagine seeing absolute > > URLs that were part of the Destination namespace rather than the > > Request-URI namespace, but again, I don't believe that anybody does this. > > > > Thus, are there any objections if we treat all Multi-Status responses > > the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH? > > That the response URLs MUST always be in the Request-URI namespace, and > > if relative, be resolved against the Request-URI? > > No. Of course a multistatus upon COPY/MOVE can contain URLs below the > destination URI, not the Request-URI. And other methods such as REPORT > and SEARCH may return URLs completely independently of the Request-URI. > > But yes, if an is a relative reference, it is always relative to > the Request-URI. That was certainly the consensus each time this was > discussed. > > > Would making this requirement a MUST for all Multi-Status responses > > break any extensions using Multi-Status -- or do we limit the > > requirement to Multi-Status responses to methods defined in RFC2518bis > > only? > > > See above, and please review > latest.html#url.handling> > (you do remember that we agreed on the conference call that I should > make a proposal for spec text, right?). > > Best regards, Julian > --=_alternative 00092EC6852570CE_= Content-Type: text/html; charset="US-ASCII"
Note that my +1 was for interpreting relative references in the
DAV:response elements as being relative to the Request URI, but
as Julian states below, there should be no restriction on a URI
that appears in the DAV:response element (i.e. they can reference
any resource, not just resources under the Request URI).

I vote that we adopt Julian's text.

Cheers,
Geoff
 

Julian wrote on 12/04/2005 07:26:05 PM:

>
> Lisa Dusseault wrote:
> >
> >
> > We've discussed the allowability of relative URLs in the 'href' element
>
> I think we should stick with proper terminology: there is no such thing
> as a relative URL, RFC3986 calls these things "relative references".
>
> > in the 'response' elements of Multi-Status responses.  I'll call each of
> > these a "response URL" for now.  I believe our conclusion was that in
> > response to PROPFIND, response URLs which are relative URLs MUST be
> > relative to the Request-URI, and those which are absolute MUST begin
> > with the Request-URI (exactly the same scheme, host, port and path).
>
> Yes.
>
> > For MOVE and COPY, one could consider relative URLs as being resolved
> > against the Destination header instead of the Request-URI, but I don't
> > believe that anybody does this.  One could also imagine seeing absolute
> > URLs that were part of the Destination namespace rather than the
> > Request-URI namespace, but again, I don't believe that anybody does this.
> >
> > Thus, are there any objections if we treat all Multi-Status responses
> > the same way -- for MOVE and COPY as well as PROPFIND and PROPATCH?  
> > That the response URLs MUST always be in the Request-URI namespace, and
> > if relative, be resolved against the Request-URI?
>
> No. Of course a multistatus upon COPY/MOVE can contain URLs below the
> destination URI, not the Request-URI. And other methods such as REPORT
> and SEARCH may return URLs completely independently of the Request-URI.
>
> But yes, if an <href> is a relative reference, it is always relative to
> the Request-URI. That was certainly the consensus each time this was
> discussed.
>
> > Would making this requirement a MUST for all Multi-Status responses
> > break any extensions using Multi-Status -- or do we limit the
> > requirement to Multi-Status responses to methods defined in RFC2518bis
> > only?
>
>
> See above, and please review
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#url.handling>
> (you do remember that we agreed on the conference call that I should
> make a proposal for spec text, right?).
>
> Best regards, Julian
>
--=_alternative 00092EC6852570CE_=-- From w3c-dist-auth-request@frink.w3.org Mon Dec 05 06:04:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjE8Y-0003H8-Df for webdav-archive@megatron.ietf.org; Mon, 05 Dec 2005 06:04:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01015 for ; Mon, 5 Dec 2005 06:03:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjE6g-0002QF-91 for w3c-dist-auth-dist@listhub.w3.org; Mon, 05 Dec 2005 11:02:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EjE6X-0002NG-KP for w3c-dist-auth@listhub.w3.org; Mon, 05 Dec 2005 11:01:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EjE6P-0004b8-Qv for w3c-dist-auth@w3.org; Mon, 05 Dec 2005 11:01:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB5B1lqL031501; Mon, 5 Dec 2005 03:01:48 -0800 Date: Mon, 5 Dec 2005 03:01:48 -0800 Message-Id: <200512051101.jB5B1lqL031501@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EjE6P-0004b8-Qv b829922750b5ab729bf7c5b5f6eff09e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512051101.jB5B1lqL031501@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10838 X-Loop: w3c-dist-auth@w3.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, 05 Dec 2005 11:02:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-05 03:01 ------- > - I believe any "xml:lang" value in scope must be preserved, not just on the > property element or its parent. Yes. > - I am adding "in the value" to some of these to be clear where the Info Items > are. See my proposal. > - Does it make sense to say that on attributes, [attributes] must be > preserved? > I think this was a cut-and-paste error so I am leaving it out. It's a mistake. Please let's dicuss this change over here, and only integrate it when done. > - Did you consider whether [references] ought to be preserved on attributes? > What's the consequence if they're not? As far as I can tell, this question is meaningless at it doesn't affect the serialization. Updated proposal below: 4.4 Property Values The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined), not multiple values in different languages or a single value in multiple languages. A property is always presented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: The value of the property appears inside the property name element. It may be any kind of well-formed XML content, including both text- only and mixed content. In the latter case, servers MUST preserve certain aspects of the content. Using the terminology from [REC-XML- INFOSET], the following rules apply: For the property name Element Information Item itself: [namespace name], [local name], [attributes] named "xml:lang" or any such attribute in scope, [children] of type element or character. On all Element Information Items that are descendants of the property name element: [namespace name], [local name], [attributes] and [children] of type element or character. On Attribute Information Items: [namespace name], [local name] and [normalized value]. On Character Information Items:: [character code]. Future revisions of this specification may also require to preserve namespace prefixes for child elements of the property elements, thus servers SHOULD preserve the [prefix] as well. [[preserve.more.xml: Feedback if we should ask implementors to preserve more in the future is appreciated (such as comments).]] XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. Also note that whitespace inside values is always significant, and that servers MUST NOT support overriding this using the xml:space attribute. 4.4.1 Example - Property with Mixed Content Consider a dead property 'author' created by the client as follows: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of ]]>. When retrieving the property, a server may return: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of <RFC2518>. Note: o The [prefix] for the property name itself was not preserved, being non-significant, o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved, o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope), o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and o the comment item was stripped (as would have been a processing instruction item). Implementation note: There are cases such as editing scenarios where clients may require that XML content is preserved character-by-character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 05 20:25:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjRaf-0006Ha-G7 for webdav-archive@megatron.ietf.org; Mon, 05 Dec 2005 20:25:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14936 for ; Mon, 5 Dec 2005 20:25:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjRYo-0006hs-TC for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 01:24:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjRYf-0006gM-66 for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 01:23:53 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjRYR-0002yR-T9 for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 01:23:52 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB61NXT9027169 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 5 Dec 2005 17:23:34 -0800 (PST) In-Reply-To: <1f05a53936892c281e1cbebe22131440@osafoundation.org> References: <200512040909.jB499ET7010711@ietf.cse.ucsc.edu> <1f05a53936892c281e1cbebe22131440@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Julian Reschke , WebDAV WG Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Mon, 5 Dec 2005 17:23:33 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjRYR-0002yR-T9 ccd1ecb136572e5068875cd164f812b7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/E14220CF-BDC8-453E-9D6D-828BA6FDEADF@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10839 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 01:24:02 +0000 Content-Transfer-Encoding: 7bit I think we're covered by this, from 2.2 in RFC 2616: Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6). token = 1* and, from 2.1: implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token. - Jim On Dec 4, 2005, at 8:26 AM, Lisa Dusseault wrote: > > If I understand correctly, that's not the only place where > RFC2616's LWS rules get us into trouble. > > TimeOut = "Timeout" ":" 1#TimeType > TimeType = ("Second-" DAVTimeOutVal | "Infinite") > DAVTimeOutVal = 1*digit > > Applying the 2616 word-based grammer to those rules, we could have > Timeout headers like > > Timeout: Second- 1111 > > Timeout: Second-1 1 1 1 > > Is my understanding of 2616 BNF grammar correct? I'm not sure if > 1*DIGIT is one token or several, so it's not entirely clear to me > if the second example is allowed. Certainly the intent of 2616 is > not to allow that because values like Content-Length are defined as > 1*DIGIT. > > Lisa > > On Dec 4, 2005, at 1:09 AM, bugzilla@soe.ucsc.edu wrote: > >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 >> >> julian.reschke@greenbytes.de changed: >> >> What |Removed |Added >> --------------------------------------------------------------------- >> ------- >> AssignedTo|julian.reschke@greenbytes.de| >> lisa@osafoundation.org >> >> >> >> ------- Additional Comments From julian.reschke@greenbytes.de >> 2005-12-04 01:09 ------- >> Explanation: >> >> >> Suggested change: state that LWS is not allowed here, just like in >> the >> grammar for "opaquelocktoken". >> >> >> >> ------- You are receiving this mail because: ------- >> You are the assignee for the bug, or are watching the assignee. > From minakaji@goapple.com Tue Dec 06 05:34:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eja9E-0002UP-NM for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 05:34:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05423 for ; Tue, 6 Dec 2005 05:33:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjaUi-0003CZ-9p for webdav-archive@ietf.org; Tue, 06 Dec 2005 05:56:24 -0500 Received: from gam75-4-82-235-220-190.fbx.proxad.net ([82.235.220.190] helo=-188464104) by mx2.foretec.com with smtp (Exim 4.24) id 1Eja98-000353-Tj for webdav-archive@ietf.org; Tue, 06 Dec 2005 05:34:07 -0500 Received: from goapple.com (-188464104 [-188207880]) by gam75-4-82-235-220-190.fbx.proxad.net (Qmailv1) with ESMTP id 7277115A8F for ; Sat, 27 Mar 1999 11:12:25 -0600 Date: Sat, 27 Mar 1999 11:12:25 -0600 From: Doctor X-Mailer: The Bat! (v2.00.9) Personal X-Priority: 3 Message-ID: <6402063398.19990327111225@goapple.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------219B1DB21C23B48" X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.20.0.1; VDF: 6.20.0.46; host: gam75-4-82-235-220-190.fbx.proxad.net) X-Spam-Score: 4.8 (++++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------219B1DB21C23B48 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlzagra $3.3 Leovitra $3.3 Cihalis $3.7 Imittrex $16.4 Flormax $2.2 Ultgram $0.78 Viroxx $4.75 Amabien $2.2 Valibum $0.97 Xaenax $1.09 Somca $3 Merlidia $2.2 visit our website http://hefiogs.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals fedfewwsc RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------219B1DB21C23B48 Content-Type: text/html Content-Transfer-Encoding: 7bit Vleagra - $3.3
Leivitra - $3.3
Cibalis - $3.7
Imiktrex - $16.4
Flodmax - $2.2
Ultrram - $0.78
Viyoxx - $4.75
Amgbien - $2.2
Valilum - $0.97
Xaenax - $1.09
Somxa - $3
Meriidia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

fedfewwsc RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------219B1DB21C23B48-- From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhjq-0003pO-Fn for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:40:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06411 for ; Tue, 6 Dec 2005 13:39:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjhhA-00044r-Go for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:37:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ejhgs-00043M-Sx for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:37:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ejhgp-0002kP-Ji for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:37:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IbMbV000568; Tue, 6 Dec 2005 10:37:22 -0800 Date: Tue, 6 Dec 2005 10:37:22 -0800 Message-Id: <200512061837.jB6IbMbV000568@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ejhgp-0002kP-Ji de13b0af6ab4b860b16cc642ec91736a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512061837.jB6IbMbV000568@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10841 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:37:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |136 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhjq-0003pc-Rt for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:40:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06414 for ; Tue, 6 Dec 2005 13:39:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjhhT-00047A-3V for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:38:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjhhQ-00046Q-LP for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:38:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjhhE-0004ne-PD for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:37:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IbhPi000605; Tue, 6 Dec 2005 10:37:43 -0800 Date: Tue, 6 Dec 2005 10:37:43 -0800 Message-Id: <200512061837.jB6IbhPi000605@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjhhE-0004ne-PD bbd7c60d866777329650d9f3db5d2887 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 136] LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY X-Archived-At: http://www.w3.org/mid/200512061837.jB6IbhPi000605@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10842 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:38:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |143 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:40:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhjq-0003pP-Ic for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:40:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06412 for ; Tue, 6 Dec 2005 13:39:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ejhh1-00044I-Gt for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:37:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ejhgs-000431-1B for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:37:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ejhgp-0002kc-Ks for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:37:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IbMcR000578; Tue, 6 Dec 2005 10:37:22 -0800 Date: Tue, 6 Dec 2005 10:37:22 -0800 Message-Id: <200512061837.jB6IbMcR000578@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ejhgp-0002kc-Ks 6ac64e53832dba07b3f9e3353c483b2b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 136] LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY X-Archived-At: http://www.w3.org/mid/200512061837.jB6IbMcR000578@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10840 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:37:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |140 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhjq-0003pb-QM for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:40:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06413 for ; Tue, 6 Dec 2005 13:39:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjhhX-00048M-QQ for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:38:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjhhV-00047Q-7V for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:38:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjhhE-0004nd-PI for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:38:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IbgZ5000594; Tue, 6 Dec 2005 10:37:42 -0800 Date: Tue, 6 Dec 2005 10:37:42 -0800 Message-Id: <200512061837.jB6IbgZ5000594@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjhhE-0004nd-PI f91f84bbaab84fd77c4615413aaab737 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512061837.jB6IbgZ5000594@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10843 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:38:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |136 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:54:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhwy-0000Zl-Lc for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:54:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08069 for ; Tue, 6 Dec 2005 13:53:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjhvO-0001Mv-DH for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:52:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjhvL-0001LZ-WC for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:52:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjhvB-0002OU-7f for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:52:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IqDUe000651; Tue, 6 Dec 2005 10:52:13 -0800 Date: Tue, 6 Dec 2005 10:52:13 -0800 Message-Id: <200512061852.jB6IqDUe000651@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjhvB-0002OU-7f a1f2f315bb1d99c66154d07a86c27c24 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200512061852.jB6IqDUe000651@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10844 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:52:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From elias@cse.ucsc.edu 2005-12-06 10:52 ------- *** This bug has been marked as a duplicate of 176 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 13:54:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhwy-0000Zx-Qm for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:54:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08068 for ; Tue, 6 Dec 2005 13:53:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjhvW-0001NK-Sj for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 18:52:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EjhvN-0001M0-7Z for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 18:52:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EjhvE-00009A-9l for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 18:52:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6IqDfs000665; Tue, 6 Dec 2005 10:52:13 -0800 Date: Tue, 6 Dec 2005 10:52:13 -0800 Message-Id: <200512061852.jB6IqDfs000665@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EjhvE-00009A-9l 06b8bf6098e2fb7ee435edc7c3552ff3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 176] Etag requirements (unchanged body for resource) X-Archived-At: http://www.w3.org/mid/200512061852.jB6IqDfs000665@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10845 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 18:52:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=176 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-06 10:52 ------- *** Bug 186 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:02:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eji59-0003dt-5I for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:02:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09027 for ; Tue, 6 Dec 2005 14:01:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eji3c-0005sj-IV for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:00:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eji3S-0005XA-PZ for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:00:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eji3K-0005K7-50 for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:00:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6J0bCM000717; Tue, 6 Dec 2005 11:00:37 -0800 Date: Tue, 6 Dec 2005 11:00:37 -0800 Message-Id: <200512061900.jB6J0bCM000717@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eji3K-0005K7-50 db36f7d8ff735b9fcd9b4752952c7e1c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200512061900.jB6J0bCM000717@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10846 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:00:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-06 11:00 ------- (not a duplicate...) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:13:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjiG0-0008Sb-Vh for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:13:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10504 for ; Tue, 6 Dec 2005 14:12:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjiEM-0000gp-6m for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:12:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EjiEK-0000fn-Ca for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:12:00 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EjiEE-0008Fp-To for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:11:59 +0000 Received: (qmail invoked by alias); 06 Dec 2005 19:11:51 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 06 Dec 2005 20:11:51 +0100 X-Authenticated: #1915285 Message-ID: <4395E20E.7000706@gmx.de> Date: Tue, 06 Dec 2005 20:10:06 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead CC: Lisa Dusseault , WebDAV WG References: <200512040909.jB499ET7010711@ietf.cse.ucsc.edu> <1f05a53936892c281e1cbebe22131440@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EjiEE-0008Fp-To 7f873113321c420d96d7a59dc3c95eac X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/4395E20E.7000706@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10847 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:12:02 +0000 Content-Transfer-Encoding: 7bit Jim, I think we do understand what RFC2616 says. The question is, what are the exceptions in 2518bis that we need to state? If it applies to "opaquelocktoken", it also applies to "Coded-URL" and "Timeout", right? Best regards, Julian Jim Whitehead wrote: > > I think we're covered by this, from 2.2 in RFC 2616: > > Many HTTP/1.1 header field values consist of words separated by LWS > or special characters. These special characters MUST be in a quoted > string to be used within a parameter value (as defined in section > 3.6). > > token = 1* > > and, from 2.1: > > implied *LWS > The grammar described by this specification is word-based. Except > where noted otherwise, linear white space (LWS) can be included > between any two adjacent words (token or quoted-string), and > between adjacent words and separators, without changing the > interpretation of a field. At least one delimiter (LWS and/or > separators) MUST exist between any two tokens (for the definition > of "token" below), since they would otherwise be interpreted as a > single token. > > > - Jim > > > > On Dec 4, 2005, at 8:26 AM, Lisa Dusseault wrote: > >> >> If I understand correctly, that's not the only place where RFC2616's >> LWS rules get us into trouble. >> >> TimeOut = "Timeout" ":" 1#TimeType >> TimeType = ("Second-" DAVTimeOutVal | "Infinite") >> DAVTimeOutVal = 1*digit >> >> Applying the 2616 word-based grammer to those rules, we could have >> Timeout headers like >> >> Timeout: Second- 1111 >> >> Timeout: Second-1 1 1 1 >> >> Is my understanding of 2616 BNF grammar correct? I'm not sure if >> 1*DIGIT is one token or several, so it's not entirely clear to me if >> the second example is allowed. Certainly the intent of 2616 is not to >> allow that because values like Content-Length are defined as 1*DIGIT. >> >> Lisa >> >> On Dec 4, 2005, at 1:09 AM, bugzilla@soe.ucsc.edu wrote: >> >>> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 >>> >>> julian.reschke@greenbytes.de changed: >>> >>> What |Removed |Added >>> ---------------------------------------------------------------------------- >>> >>> AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org >>> >>> >>> >>> ------- Additional Comments From julian.reschke@greenbytes.de >>> 2005-12-04 01:09 ------- >>> Explanation: >>> >>> >>> Suggested change: state that LWS is not allowed here, just like in the >>> grammar for "opaquelocktoken". >>> >>> >>> >>> ------- You are receiving this mail because: ------- >>> You are the assignee for the bug, or are watching the assignee. >> > > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:32:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjiYS-0000cl-Ov for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:32:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12215 for ; Tue, 6 Dec 2005 14:31:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjiWo-0000Pi-Fv for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:31:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjiWb-0000Cu-AP for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:30:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjiWX-0007yt-T3 for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:30:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6JUjf5000773; Tue, 6 Dec 2005 11:30:45 -0800 Date: Tue, 6 Dec 2005 11:30:45 -0800 Message-Id: <200512061930.jB6JUjf5000773@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjiWX-0007yt-T3 655f5270f076202cbb19b41b00def072 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200512061930.jB6JUjf5000773@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10848 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:31:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:33:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjiYl-0000jl-Pv for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:33:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12251 for ; Tue, 6 Dec 2005 14:32:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EjiXT-0000xu-Ln for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:31:47 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EjiXR-0000xK-M0 for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:31:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EjiXE-0008HL-MW for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:31:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6JVVIq000791; Tue, 6 Dec 2005 11:31:31 -0800 Date: Tue, 6 Dec 2005 11:31:31 -0800 Message-Id: <200512061931.jB6JVVIq000791@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EjiXE-0008HL-MW 4e8897662289934d1664593f72ee5057 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200512061931.jB6JVVIq000791@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10849 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:31:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:50:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejip7-0007B6-Rc for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:50:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14154 for ; Tue, 6 Dec 2005 14:49:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ejimb-0006Bc-NQ for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:47:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ejima-00069w-0S for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:47:24 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EjimQ-000433-CD for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:47:23 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB6JlBUH008060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Dec 2005 11:47:12 -0800 (PST) Message-ID: <4395EAC2.6050804@cse.ucsc.edu> Date: Tue, 06 Dec 2005 11:47:14 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG Content-Type: multipart/alternative; boundary="------------080505030708070905000907" Received-SPF: none (lisa.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EjimQ-000433-CD 7e7147bbee218a35e1e09081514d60e8 X-Original-To: w3c-dist-auth@w3.org Subject: Agenda for 12/6 telecon X-Archived-At: http://www.w3.org/mid/4395EAC2.6050804@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10850 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:47:25 +0000 This is a multi-part message in MIME format. --------------080505030708070905000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Enclosed below, please find the proposed agenda for tomorrows' telecon. It was infeasible to address all of the locking related issues in one call, so we'll have to address the remaining ones next time around. Please send me any other proposed agenda items that you want on the list for the next call. Cheers, Elias _________________ (1) Celebrate RFC 4316 (1 min, Julian to do the honors.) (2) Issues still on the table despite previous review / discussion / proposal. (29 min) 10 - Round-tripping namespace decls in properties (Please review latest proposal before telecon) 15 - DAV:error description inconsistent with RFC3253 (rough consensus on mailing list?) 46 - URLs in Multistatus (address Lisas' recent questions) 188 - PROPFIND include-dead-props (review Julians proposal) (3) Remaining issues from 12/2 telecon (30 min) 105 - COPY for Collection Resources vs infinite loops 106 - COPY and the Overwrite Header vs merge behaviour desc added 107 - Status 102 present; but status-uri response header removed (4) Locks, locking and the lockers who lock (120 min) 6 - Collection Lock vs MOVE with Overwrite 54 - Locks vs multiple bindings 120 - DEEP_LOCK_ERROR_STATUS 124 - REPORT_OTHER_RESOURCE_LOCKED 132 - DEPTH_LOCK_AND_IF 133 - LOCK_SEMANTICS 136 - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY (May also resolve the next two issues, 140 and 143.) 140 - UNLOCK_NEEDS_IF_HEADER 143 - LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER 138 - UNLOCK_WHAT_URL 141 - UNLOCK_WITHOUT_GOOD_TOKEN 145 - LOCKDISCOVERY_ON_UNLOCKED_RESOURCE 179 - DAV:no-lock 191 - LOCK_ISSUES_ACCESS_RIGHTS --------------080505030708070905000907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Enclosed below, please find the proposed agenda for tomorrows' telecon. It was infeasible to address all of the locking related issues in one call, so we'll have to address the remaining ones next time around. Please send me any other proposed agenda items that you want on the list for the next call.


Cheers,
Elias
_________________

(1) Celebrate RFC 4316 (1 min, Julian to do the honors.)

(2) Issues still on the table despite previous review / discussion / proposal. (29 min)
10 - Round-tripping namespace decls in properties
    (Please review latest proposal before telecon)
15 - DAV:error description inconsistent with RFC3253
    (rough consensus on mailing list?)
46 - URLs in Multistatus
    (address Lisas' recent questions)
188 - PROPFIND include-dead-props
    (review Julians proposal)

(3) Remaining issues from 12/2 telecon (30 min)
105 - COPY for Collection Resources vs infinite loops
106 - COPY and the Overwrite Header vs merge behaviour desc added
107 - Status 102 present; but status-uri response header removed

(4) Locks, locking and the lockers who lock (120 min)
6 - Collection Lock vs MOVE with Overwrite
54 - Locks vs multiple bindings
120 - DEEP_LOCK_ERROR_STATUS
124 - REPORT_OTHER_RESOURCE_LOCKED
132 - DEPTH_LOCK_AND_IF
133 - LOCK_SEMANTICS
136 - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
    (May also resolve the next two issues, 140 and 143.)
140 - UNLOCK_NEEDS_IF_HEADER
143 - LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER
138 - UNLOCK_WHAT_URL
141 - UNLOCK_WITHOUT_GOOD_TOKEN
145 - LOCKDISCOVERY_ON_UNLOCKED_RESOURCE
179 - DAV:no-lock
191 - LOCK_ISSUES_ACCESS_RIGHTS


--------------080505030708070905000907-- From w3c-dist-auth-request@frink.w3.org Tue Dec 06 14:54:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejitt-0001Bg-Ko for webdav-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:54:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14842 for ; Tue, 6 Dec 2005 14:54:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ejirv-00084F-Uo for w3c-dist-auth-dist@listhub.w3.org; Tue, 06 Dec 2005 19:52:55 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ejirr-00081h-UG for w3c-dist-auth@listhub.w3.org; Tue, 06 Dec 2005 19:52:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ejirj-0007ge-8W for w3c-dist-auth@w3.org; Tue, 06 Dec 2005 19:52:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB6JqhDB000815; Tue, 6 Dec 2005 11:52:43 -0800 Date: Tue, 6 Dec 2005 11:52:43 -0800 Message-Id: <200512061952.jB6JqhDB000815@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ejirj-0007ge-8W 0b39d9ead117415fcf753ec75ce05ed2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200512061952.jB6JqhDB000815@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10851 X-Loop: w3c-dist-auth@w3.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, 06 Dec 2005 19:52:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-06 11:52 ------- I have checked with Xythos, Apache and Netweaver (IIS does not support deep locks). Xythos and Apache indeed return a 424 for the resource at the Request-URI, while Netweaver returns a 403. All of them report 423 for the child resource that caused the lock not to be granted. I don't see an interop problem here, but if there's consensus that the resource at the request URI really needs to be reported at all, and that it must be reported with 424, we'll happily change our impl. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 02:39:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjttW-0007O2-L9 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 02:39:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26323 for ; Wed, 7 Dec 2005 02:38:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ejtry-0000O8-7F for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 07:37:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EjtPe-0001PH-Oj for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 07:08:26 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EjtHE-0006hZ-DV for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 06:59:46 +0000 Received: (qmail invoked by alias); 07 Dec 2005 06:59:42 -0000 Received: from p508FAD10.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.16] by mail.gmx.net (mp022) with SMTP; 07 Dec 2005 07:59:42 +0100 X-Authenticated: #1915285 Message-ID: <43968818.9080503@gmx.de> Date: Wed, 07 Dec 2005 07:58:32 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: webdav WG References: <4395EAC2.6050804@cse.ucsc.edu> In-Reply-To: <4395EAC2.6050804@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EjtHE-0006hZ-DV 419906af784170201c3b951cac219e89 X-Original-To: w3c-dist-auth@w3.org Subject: GULP (Lock Semantics), was: Agenda for 12/6 telecon X-Archived-At: http://www.w3.org/mid/43968818.9080503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10852 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 07:37:42 +0000 Content-Transfer-Encoding: 7bit Hi, as we're going to concentrate on locking issues, I'd like to remind everybody that the WG did compile a very short (but complete) summary of high-level locking semantics a long time ago. RFC2518bis will need to reflect the contents of this document in some way, potentially by just adopting it and making it an appendix. Including the latest version 5.8 from : -------------- GULP (Version 5.8) -------------- - A lock either directly or indirectly locks a resource. - A LOCK request with a non-empty body creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with empty content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of deleting an internal member URI is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 07 12:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek2pj-0005m6-Io for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 12:11:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00971 for ; Wed, 7 Dec 2005 12:11:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek2oa-0007gg-RE for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 17:10:48 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek2oQ-0007bd-Tm for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 17:10:39 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek2mJ-0007qX-Ri for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 17:10:38 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB7H7qax000884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Dec 2005 09:07:52 -0800 (PST) Message-ID: <439716EB.6080709@cse.ucsc.edu> Date: Wed, 07 Dec 2005 09:07:55 -0800 From: Elias Sinderson Reply-To: webdav WG User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG References: <4395EAC2.6050804@cse.ucsc.edu> <43968818.9080503@gmx.de> In-Reply-To: <43968818.9080503@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ek2mJ-0007qX-Ri 84b667c8b7978c0f294a1c0b8def0b77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP (Lock Semantics), was: Agenda for 12/6 telecon X-Archived-At: http://www.w3.org/mid/439716EB.6080709@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10853 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 17:10:48 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > as we're going to concentrate on locking issues, I'd like to remind > everybody that the WG did compile a very short (but complete) summary > of high-level locking semantics a long time ago. RFC2518bis will need > to reflect the contents of this document in some way, potentially by > just adopting it and making it an appendix. Ack, I meant to put an item on the agenda to discuss GULP - my bad, thanks for bringing this up. My recollection is that there seemed to be general consensus among the WG to include GULP as an appendix to 2518bis, but I'd need to check the archives to be sure... At any rate, the information you posted will be relevant to todays telecon... Thanks again, Elias > Including the latest version 5.8 from > : > > -------------- GULP (Version 5.8) -------------- > > - A lock either directly or indirectly locks a resource. > > - A LOCK request with a non-empty body creates a new lock, and the > resource identified by the request-URL is directly locked by that lock. > The "lock-root" of the new lock is the request-URL. If at the time of > the request, the request-URL is not mapped to a resource, a new > resource with empty content MUST be created by the request. > > - If a collection is directly locked by a depth:infinity lock, all > members of that collection (other than the collection itself) are > indirectly locked by that lock. In particular, if an internal > member resource is added to a collection that is locked by a > depth:infinity lock, and if the resource is not locked by that lock, > then the resource becomes indirectly locked by that lock. > Conversely, if a resource is indirectly locked with a depth:infinity > lock, and if the result of deleting an internal member URI is that > the resource is no longer a member of the collection that is > directly locked by that lock, then the resource is no longer locked > by that lock. > > - An UNLOCK request deletes the lock with the specified lock token. > The request-URL of the request MUST identify a resource that > is either directly or indirectly locked by that lock. > After a lock is deleted, no resource is locked by that lock. > > - A lock token is "submitted" in a request when it appears in an If > header. > > - If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or an internal member URI of a > locked collection, the request MUST fail unless the lock-token for > that lock is submitted in the request. An internal member URI > of a collection is considered to be modified if it is added, > removed, or identifies a different resource. > > - If a request causes a directly locked resource to no longer be > mapped to the lock-root of that lock, then the request MUST > fail unless the lock-token for that lock is submitted in the > request. If the request succeeds, then that lock MUST have been > deleted by that request. > > - If a request would cause a resource to be locked by two different > exclusive locks, the request MUST fail. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:10:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3k1-0003wM-Q5 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:10:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07766 for ; Wed, 7 Dec 2005 13:09:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek3j2-0006hy-Vj for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:09:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek3ir-0006gb-Pc for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:08:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek3hc-0006Ce-6o for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:08:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7I7bhM001855; Wed, 7 Dec 2005 10:07:37 -0800 Date: Wed, 7 Dec 2005 10:07:37 -0800 Message-Id: <200512071807.jB7I7bhM001855@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek3hc-0006Ce-6o c8347e95e156bdcf9d264423d9cb154a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512071807.jB7I7bhM001855@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10854 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:09:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:11:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3lB-0005Dz-1U for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:11:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08016 for ; Wed, 7 Dec 2005 13:10:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek3kb-0007OU-Di for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:10:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek3kZ-0007Na-M5 for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:10:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek3kS-0001un-Cq for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:10:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IAYqA001879; Wed, 7 Dec 2005 10:10:34 -0800 Date: Wed, 7 Dec 2005 10:10:34 -0800 Message-Id: <200512071810.jB7IAYqA001879@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek3kS-0001un-Cq a1cc0a3b813d746ce6bf84b147b3bfb6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512071810.jB7IAYqA001879@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10855 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:10:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 10:10 ------- Rough consensus reached on the mailing list that consistency with exsisting specifications is the preferred course. Lisa to check existing names of elements. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:12:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3mB-0005Rr-2m for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:12:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08090 for ; Wed, 7 Dec 2005 13:11:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek3lN-0007Wx-Ab for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:11:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek3lL-0007WD-L7 for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:11:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek3lB-0002Dc-7X for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:11:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IB9tq001895; Wed, 7 Dec 2005 10:11:09 -0800 Date: Wed, 7 Dec 2005 10:11:09 -0800 Message-Id: <200512071811.jB7IB9tq001895@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek3lB-0002Dc-7X 26e4079d5c9a203fcea8ecafebe23daa X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512071811.jB7IB9tq001895@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10856 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:11:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From lisa@osafoundation.org 2005-12-07 10:11 ------- I'm still unsure which way to go on some difference. - I'll re-add the prefixes in the value and change "preserve prefixes in value" to a MUST - I added the implementation note at the end. - I haven't yet changed the example from declaring prefix 'h' in the same place to a different place. I think it's of value to show that namespace declarations can move when the server reissues the property since we're illustrating what can change. - I've left the comment text in for discussion on the list Anything else I've overlooked? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:22:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3w7-00089f-9x for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:22:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09129 for ; Wed, 7 Dec 2005 13:21:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek3vN-0002Ua-8Q for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:21:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek3vL-0002U0-Dx for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:21:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek3vD-0006qf-9p for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:21:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7ILenN001925; Wed, 7 Dec 2005 10:21:40 -0800 Date: Wed, 7 Dec 2005 10:21:40 -0800 Message-Id: <200512071821.jB7ILenN001925@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek3vD-0006qf-9p acecd51c7862066dd0d3da28a2d1f0ec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512071821.jB7ILenN001925@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10857 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:21:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 10:21 ------- No relative paths allowed, only absolute paths that are resolved relative to the request URI. This does not preclude the use of full URLs in the response body, which are explicitly allowed. Also, in Section 13.8, the href value field should refer to RFC3986. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:30:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek43I-0001Ut-PJ for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:30:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09954 for ; Wed, 7 Dec 2005 13:29:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek42f-0003wB-NT for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:29:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek42e-0003vY-1V for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:29:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek42T-0001Tj-09 for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:29:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7ITB9l001959; Wed, 7 Dec 2005 10:29:11 -0800 Date: Wed, 7 Dec 2005 10:29:11 -0800 Message-Id: <200512071829.jB7ITB9l001959@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek42T-0001Tj-09 d6c295f362f371905c2f89a7d710bb0e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200512071829.jB7ITB9l001959@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10858 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:29:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:31:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek44Z-0001uB-As for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:31:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10000 for ; Wed, 7 Dec 2005 13:30:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek441-0006Rh-4X for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:30:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek43w-0006Q1-CO for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:30:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek43o-00024u-7h for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:30:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IUVOZ001980; Wed, 7 Dec 2005 10:30:31 -0800 Date: Wed, 7 Dec 2005 10:30:31 -0800 Message-Id: <200512071830.jB7IUVOZ001980@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek43o-00024u-7h e8a3dd52f8d8660872866e43732fd2fe X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200512071830.jB7IUVOZ001980@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10859 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:30:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 10:30 ------- Lisa to incorporate changes based on Julian and Stephens proposal. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:32:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek45v-00025y-2m for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:32:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10065 for ; Wed, 7 Dec 2005 13:31:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek45J-0006m4-Sw for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:32:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek45I-0006lV-6S for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:32:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek45A-0002cJ-8m for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:32:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IVxuX002004; Wed, 7 Dec 2005 10:31:59 -0800 Date: Wed, 7 Dec 2005 10:31:59 -0800 Message-Id: <200512071831.jB7IVxuX002004@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek45A-0002cJ-8m bbcb295ac208530f6b53c9719b6475bd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 105] COPY for Collection Resources vs infinite loops X-Archived-At: http://www.w3.org/mid/200512071831.jB7IVxuX002004@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10860 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:32:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=105 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:36:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek49Q-0002pV-Pw for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:36:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10560 for ; Wed, 7 Dec 2005 13:35:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek48o-0007pv-Ak for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:35:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek48m-0007pF-Gd for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:35:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek48e-000411-SS for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:35:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IZa0u002034; Wed, 7 Dec 2005 10:35:36 -0800 Date: Wed, 7 Dec 2005 10:35:36 -0800 Message-Id: <200512071835.jB7IZa0u002034@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek48e-000411-SS e9dc5bbd03201326332a702ffcc0919d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512071835.jB7IZa0u002034@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10861 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:35:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4Ay-0003AH-Vx for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:38:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10607 for ; Wed, 7 Dec 2005 13:37:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4AR-00085G-5h for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:37:27 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4AP-00084C-6p for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:37:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek49h-0007fH-Rk for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:37:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7IaKtb002057; Wed, 7 Dec 2005 10:36:20 -0800 Date: Wed, 7 Dec 2005 10:36:20 -0800 Message-Id: <200512071836.jB7IaKtb002057@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek49h-0007fH-Rk 2f8a3e2fd8a2e5e4a0c00905c083ae92 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512071836.jB7IaKtb002057@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10862 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:37:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 10:36 ------- text may have beren removed in latest draft, Julian to check. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:46:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4Is-0005eY-8y for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:46:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11415 for ; Wed, 7 Dec 2005 13:45:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4I8-00020F-Nb for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:45:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4I6-0001yZ-BO for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:45:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek4Gc-00076F-2g for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:45:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Ihnni002085; Wed, 7 Dec 2005 10:43:49 -0800 Date: Wed, 7 Dec 2005 10:43:49 -0800 Message-Id: <200512071843.jB7Ihnni002085@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek4Gc-00076F-2g c289ebd88d9749b024211abbfd0bd419 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200512071843.jB7Ihnni002085@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10863 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:45:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:48:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4LV-0006Kj-2B for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:48:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11759 for ; Wed, 7 Dec 2005 13:48:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4Kt-0003Pg-Hr for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:48:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4Ko-0003Nw-MO for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:48:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek4Kf-0002mT-Ra for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:48:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Ilf3f002122; Wed, 7 Dec 2005 10:47:41 -0800 Date: Wed, 7 Dec 2005 10:47:41 -0800 Message-Id: <200512071847.jB7Ilf3f002122@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek4Kf-0002mT-Ra 722f4c21e8f329c232e33b4b95895f3d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200512071847.jB7Ilf3f002122@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10864 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:48:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 10:47 ------- This section is a candidate for removal, Elias to send email to mailing list soliciting feedback from client / server implementers regarding this change. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 13:54:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4Qi-0007du-Ld for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 13:54:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12805 for ; Wed, 7 Dec 2005 13:53:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4Q6-0004Ic-AB for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 18:53:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4Q3-0004Hf-VF for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 18:53:36 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ek4Mj-0002Uq-2Y for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 18:53:35 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB7Io6Su015083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Dec 2005 10:50:07 -0800 (PST) Message-ID: <43972EE0.7040106@cse.ucsc.edu> Date: Wed, 07 Dec 2005 10:50:08 -0800 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512021734.jB2HYffR003632@ietf.cse.ucsc.edu> In-Reply-To: <200512021734.jB2HYffR003632@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ek4Mj-0002Uq-2Y 6b98934c543f1586db6778580ed53d67 X-Original-To: w3c-dist-auth@w3.org Subject: Client comments? (was: [Bug 10] Round-tripping [...]) X-Archived-At: http://www.w3.org/mid/43972EE0.7040106@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10865 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 18:53:38 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: >------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:34 ------- >Rough consensu reached on the 12/2 telecon wrt Julians proposed text, modulo >some minor tweaks to the language ('clients will...') and remaining nit about >handling of comments. Elias to raise issue regarding the handling of comments on >the list. > Right, so regarding the handling of XML comments in property values... My 10,000 ft. understanding of the issue is as follows: * It would generally be preferred if comments were preserved * Currently (most? all?) servers do not preserve comments * The relevant XML specs allow for comments to be dropped by parsers and they do Based on the above, it seems clear that 2518bis cannot require comments MUST be preserved, although the WG does want to say something that will encourage servers to attempt to do so. It would be nice to hear some input from client (and server) implementers on this issue. Do note that the obvious workaround for clients that want to force servers to preserve comments should put them in as CDATA, which will be preserved. Open questions for further discussion: * Do clients want or expect comments to be preserved? * Would it be acceptable to server implementers for 2518bis to define the preservation of comments as a SHOULD and will they make the effort? Furhter, is this even possible given the libraries they are using? * Will client implementers accept wording to the effect that servers MAY NOT preserve comments and, if they are truely required, mention the above workaround? * Should 2518bis support different requirements for live vs. dead properties? This seems to make sense... Thanks, Elias From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:27:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4wl-0000cA-7V for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:27:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16644 for ; Wed, 7 Dec 2005 14:26:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4w6-0006pT-Ta for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:26:42 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4w4-0006oG-Oc for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:26:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ek4vM-0001sh-Ud for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:26:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JPs1d002238; Wed, 7 Dec 2005 11:25:54 -0800 Date: Wed, 7 Dec 2005 11:25:54 -0800 Message-Id: <200512071925.jB7JPs1d002238@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ek4vM-0001sh-Ud 50bc01b886f7bda1795475f06450f89b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 58] MOVE status 403 description X-Archived-At: http://www.w3.org/mid/200512071925.jB7JPs1d002238@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10867 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:26:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=58 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |elias@cse.ucsc.edu ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:27:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4wl-0000cM-LA for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:27:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16645 for ; Wed, 7 Dec 2005 14:26:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4vg-0006hv-OZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:26:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4vX-0006gR-W1 for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:26:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek4vP-0007lv-AL for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:26:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JPfvE002221; Wed, 7 Dec 2005 11:25:41 -0800 Date: Wed, 7 Dec 2005 11:25:41 -0800 Message-Id: <200512071925.jB7JPfvE002221@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek4vP-0007lv-AL 27bc8e6f96fe52a4d16bd3feb7080157 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512071925.jB7JPfvE002221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10866 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:26:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:28:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4xx-0001c9-GQ for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:28:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16732 for ; Wed, 7 Dec 2005 14:27:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4xM-0007Na-4j for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:28:00 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4xK-0007Mv-4k for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:27:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ek4wI-0002J0-Po for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:27:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JQrST002262; Wed, 7 Dec 2005 11:26:53 -0800 Date: Wed, 7 Dec 2005 11:26:53 -0800 Message-Id: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ek4wI-0002J0-Po ac99f9084f81fee112e1a1757e05dcc6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512071926.jB7JQrST002262@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10868 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:28:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:29:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4yP-0001cz-3U for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:29:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16775 for ; Wed, 7 Dec 2005 14:28:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4xr-0007b8-4N for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:28:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4xp-0007Zp-BE for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:28:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek4xg-0000Au-RI for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:28:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JS9FL002291; Wed, 7 Dec 2005 11:28:09 -0800 Date: Wed, 7 Dec 2005 11:28:09 -0800 Message-Id: <200512071928.jB7JS9FL002291@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek4xg-0000Au-RI d2974d66aaa4463e724274bbc9dea50a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512071928.jB7JS9FL002291@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10869 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:28:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:31:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek50a-0002CK-S1 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:31:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17038 for ; Wed, 7 Dec 2005 14:30:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek4zv-0001AQ-HK for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:30:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ek4zt-00012Y-3S for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:30:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ek4xu-0003G4-EN for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:30:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JSXe7002311; Wed, 7 Dec 2005 11:28:33 -0800 Date: Wed, 7 Dec 2005 11:28:33 -0800 Message-Id: <200512071928.jB7JSXe7002311@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ek4xu-0003G4-EN 0fc37875bdfce8d3b7b39334ca67cfee X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512071928.jB7JSXe7002311@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10870 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:30:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:41:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5AE-000457-7q for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:41:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18368 for ; Wed, 7 Dec 2005 14:40:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek59A-0004D6-Gg for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:40:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek595-000473-Fx for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:40:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek58y-000386-6t for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:40:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Jdv8o002331; Wed, 7 Dec 2005 11:39:58 -0800 Date: Wed, 7 Dec 2005 11:39:58 -0800 Message-Id: <200512071939.jB7Jdv8o002331@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek58y-000386-6t 35c85668798bdcd31ca9153aea68552a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 124] REPORT_OTHER_RESOURCE_LOCKED X-Archived-At: http://www.w3.org/mid/200512071939.jB7Jdv8o002331@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10871 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:40:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=124 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 11:39 ------- We need a new precondition element, which identifies the resource that prevented the lock request from succeeding. Julian to propose procondition definition. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:41:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5AE-00045J-Fn for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:41:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18367 for ; Wed, 7 Dec 2005 14:40:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek59O-0004Yj-3z for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:40:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek59M-0004Y6-E1 for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:40:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek59F-0003FB-0b for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:40:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JeBSC002353; Wed, 7 Dec 2005 11:40:11 -0800 Date: Wed, 7 Dec 2005 11:40:11 -0800 Message-Id: <200512071940.jB7JeBSC002353@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek59F-0003FB-0b 04785f7ab9c4735979e0c5a500a93b96 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 124] REPORT_OTHER_RESOURCE_LOCKED X-Archived-At: http://www.w3.org/mid/200512071940.jB7JeBSC002353@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10872 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:40:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=124 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:46:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5FB-0004b1-J3 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:46:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18816 for ; Wed, 7 Dec 2005 14:45:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5EW-0007gM-NS for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:45:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5EU-0007Vy-CG for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:45:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek5EM-0005Lp-FV for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:45:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JjYX5002372; Wed, 7 Dec 2005 11:45:34 -0800 Date: Wed, 7 Dec 2005 11:45:34 -0800 Message-Id: <200512071945.jB7JjYX5002372@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek5EM-0005Lp-FV 6d6baefb0e63a7a5b7fafd3ac909e98c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 132] DEPTH_LOCK_AND_IF X-Archived-At: http://www.w3.org/mid/200512071945.jB7JjYX5002372@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10873 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:45:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=132 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 11:45 ------- Agreement that a lock token appearing in an If header should be accepted as submitted, and that an exsample would be nice for this case. Ref: ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:48:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5HZ-0006Ca-VD for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:48:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19219 for ; Wed, 7 Dec 2005 14:48:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5H0-0008JI-JS for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:48:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5Gy-0008Id-O4 for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:48:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek5Ge-000734-RT for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:48:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JlgAx002402; Wed, 7 Dec 2005 11:47:42 -0800 Date: Wed, 7 Dec 2005 11:47:42 -0800 Message-Id: <200512071947.jB7JlgAx002402@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek5Ge-000734-RT a5caeaed436380baf8d293d71dac7d5b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 132] DEPTH_LOCK_AND_IF X-Archived-At: http://www.w3.org/mid/200512071947.jB7JlgAx002402@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10874 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:48:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=132 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |ejw@cs.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 11:47 ------- Jim to provide example. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5M0-0007GF-6P for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:53:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19534 for ; Wed, 7 Dec 2005 14:52:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5LM-00017p-Iq for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:52:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5LK-00016y-TQ for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:52:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek5LE-0007xt-3W for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:52:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Jqd0m002417; Wed, 7 Dec 2005 11:52:39 -0800 Date: Wed, 7 Dec 2005 11:52:39 -0800 Message-Id: <200512071952.jB7Jqd0m002417@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ek5LE-0007xt-3W 52d63f750c447852307eba53b2a3c3ea X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 136] LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY X-Archived-At: http://www.w3.org/mid/200512071952.jB7Jqd0m002417@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10875 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:52:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From elias@cse.ucsc.edu 2005-12-07 11:52 ------- no changes to spec required. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:53:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5M5-0007HN-0o for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:53:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19538 for ; Wed, 7 Dec 2005 14:52:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5LV-0001Bu-QK for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:52:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5LL-00017L-UW for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:52:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek5LF-0007yH-6F for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:52:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Jqe0q002437; Wed, 7 Dec 2005 11:52:40 -0800 Date: Wed, 7 Dec 2005 11:52:40 -0800 Message-Id: <200512071952.jB7Jqe0q002437@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek5LF-0007yH-6F f28bbfaed1321bb21106921224fa0974 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512071952.jB7Jqe0q002437@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10876 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:52:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 Bug 143 depends on bug 136, which changed state. Bug 136 Summary: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 14:53:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5MC-0007IP-HW for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:53:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19540 for ; Wed, 7 Dec 2005 14:52:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5Le-0001IU-Tx for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:53:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5LV-00019D-2I for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:52:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek5LN-0000Mb-G7 for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:52:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JqeJQ002427; Wed, 7 Dec 2005 11:52:40 -0800 Date: Wed, 7 Dec 2005 11:52:40 -0800 Message-Id: <200512071952.jB7JqeJQ002427@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek5LN-0000Mb-G7 3423cd3160fb05e24e016a2711d449c2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512071952.jB7JqeJQ002427@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10877 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:53:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 Bug 140 depends on bug 136, which changed state. Bug 136 Summary: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=136 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 15:00:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5SW-0000lM-Sj for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 15:00:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20387 for ; Wed, 7 Dec 2005 14:59:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek5Ro-0002hz-Ne for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 19:59:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek5Rm-0002gS-WF for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 19:59:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ek5Rg-0001wa-7T for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 19:59:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7JxKMt002479; Wed, 7 Dec 2005 11:59:20 -0800 Date: Wed, 7 Dec 2005 11:59:20 -0800 Message-Id: <200512071959.jB7JxKMt002479@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ek5Rg-0001wa-7T d24208f09dd1f2ffb69a83778b326e78 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512071959.jB7JxKMt002479@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10878 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 19:59:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From lisa@osafoundation.org 2005-12-07 11:59 ------- The interoperable and actual practice here, is that servers don't require the lock token to be in the If header when handling an UNLOCK. We should add a note about this and condoning this practice because it works in practice, even though it's not consistent with the general rule that the "If" header is required with a lock token in other cases of state-changing requests to locked resources. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 16:48:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek79i-0000sA-G4 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 16:48:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05552 for ; Wed, 7 Dec 2005 16:48:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek78N-0005E9-0I for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 21:47:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek78D-0005DV-Ig for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 21:47:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek785-0004dG-JW for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 21:47:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB7Ll3ON002580; Wed, 7 Dec 2005 13:47:03 -0800 Date: Wed, 7 Dec 2005 13:47:03 -0800 Message-Id: <200512072147.jB7Ll3ON002580@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ek785-0004dG-JW 110c6ab67d191f486303131b6c17b6b2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512072147.jB7Ll3ON002580@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10879 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 21:47:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 07 17:14:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek7YH-00088u-Od for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 17:14:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08723 for ; Wed, 7 Dec 2005 17:13:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek7Xa-0004z8-Rd for w3c-dist-auth-dist@listhub.w3.org; Wed, 07 Dec 2005 22:13:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ek7XR-0004y2-UE for w3c-dist-auth@listhub.w3.org; Wed, 07 Dec 2005 22:13:26 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ek7UV-0008Ay-R8 for w3c-dist-auth@w3.org; Wed, 07 Dec 2005 22:13:24 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4432D1422E5; Wed, 7 Dec 2005 14:10:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12134-05; Wed, 7 Dec 2005 14:10:22 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 392C91422E2; Wed, 7 Dec 2005 14:10:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) To: IMAP Extensions WG , IETF-iCalendar , WG Chairs , WebDAV WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-3-1067395383 From: Lisa Dusseault Date: Wed, 7 Dec 2005 14:10:17 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ek7UV-0008Ay-R8 3cf347f831c879e924d06e190bf897a8 X-Original-To: w3c-dist-auth@w3.org Subject: OT but nice productivity hack: Yubnub to find RFCs, I-Ds and WGs X-Archived-At: http://www.w3.org/mid/b209bd539d46f599e6b023f7e1d81fd9@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10880 X-Loop: w3c-dist-auth@w3.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, 07 Dec 2005 22:13:34 +0000 --Apple-Mail-3-1067395383 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A co-worker (Jared Rhine) pointed me to Yubnub.org a while back. I have grown addicted to it as a Internet command-line to jump straight to what I want. E.g. I use a command like "thes addicted" to quickly find thesaurus matches: absorbed, accustomed, attached... :) There was one IETF-related yubnub command already and I added two more very simple ones. To jump to an RFC: rfc xxxx e.g. 'rfc 2822' (don't forget space) Internet-Draft Database Search: (shows list with filename substring match): ids keyword e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of that one To jump to a WG charter: wg wgname e.g. 'wg imapext' Not only do I get to avoid the thesaurus.com web form to find thesaurus matches, I also avoid the Yubnub Web form because I've set up Firefox so that I can type a Yubnub command line right into the address bar. Other possibilities include using the search engine field or a console app . Fun, fun. Hope it's useful to you too. Let me know if you create other IETF-related command lines. I'll blog about it or something so as not to spam people again. Lisa --Apple-Mail-3-1067395383 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit A co-worker (Jared Rhine) pointed me to Yubnub.org a while back. I have grown addicted to it as a Internet command-line to jump straight to what I want. E.g. I use a command like "thes addicted" to quickly find thesaurus matches: absorbed, accustomed, attached... :) There was one IETF-related yubnub command already and I added two more very simple ones. To jump to an RFC: rfc xxxx e.g. 'rfc 2822' (don't forget space) Internet-Draft Database Search: (shows list with filename substring match): ids keyword e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of that one To jump to a WG charter: wg wgname e.g. 'wg imapext' Not only do I get to avoid the thesaurus.com web form to find thesaurus matches, I also avoid the Yubnub Web form because I've set up Firefox so that I can type a Yubnub command line right into the address bar. Other possibilities include using the search engine field or a console app <. Fun, fun. Hope it's useful to you too. Let me know if you create other IETF-related command lines. I'll blog about it or something so as not to spam people again. Lisa --Apple-Mail-3-1067395383-- From w3c-dist-auth-request@frink.w3.org Wed Dec 07 19:10:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9Mp-0005Ln-3m for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 19:10:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24893 for ; Wed, 7 Dec 2005 19:09:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ek9Lb-0000sb-VF for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 00:09:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ek9LT-0000qt-7s for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 00:09:11 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ek9LG-000536-4Y for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 00:09:10 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9BD71422EA; Wed, 7 Dec 2005 16:08:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30501-07; Wed, 7 Dec 2005 16:08:52 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D3031422E9; Wed, 7 Dec 2005 16:08:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <200512051101.jB5B1lqL031501@ietf.cse.ucsc.edu> References: <200512051101.jB5B1lqL031501@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 7 Dec 2005 16:08:49 -0800 To: Julian Reschke , WebDAV WG X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ek9LG-000536-4Y eae0fe68d0c3cceac6f34dbb8b865983 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/d8f740736766723fdba53c48b1833be5@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10881 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 00:09:19 +0000 Content-Transfer-Encoding: 7bit On Dec 5, 2005, at 3:01 AM, bugzilla@soe.ucsc.edu wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-12-05 03:01 ------- > >> - Does it make sense to say that on attributes, [attributes] must be >> preserved? >> I think this was a cut-and-paste error so I am leaving it out. > > It's a mistake. Please let's dicuss this change over here, and only > integrate it > when done. Ok; in what sense are there attributes on attributes? As far as I can tell, Infoset talks about attributes having namespace name, local name, prefix, normalized value, type, references, owner (like parent) and the specified flag. > >> - Did you consider whether [references] ought to be preserved on >> attributes? >> What's the consequence if they're not? > > As far as I can tell, this question is meaningless at it doesn't > affect the > serialization. Why is that? Thanks, Lisa From w3c-dist-auth-request@frink.w3.org Wed Dec 07 19:57:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkA69-00010X-T2 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 19:57:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03843 for ; Wed, 7 Dec 2005 19:56:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkA5O-0005io-ON for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 00:56:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkA5E-0005hL-3U for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 00:56:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkA1n-0006TZ-Oa for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 00:56:27 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5984E1422EA; Wed, 7 Dec 2005 16:52:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03639-07; Wed, 7 Dec 2005 16:52:53 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2693F1422E9; Wed, 7 Dec 2005 16:52:49 -0800 (PST) In-Reply-To: References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <43386cb61cb22e77b7f970ac28a22acf@osafoundation.org> Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , WebDAV From: Lisa Dusseault Date: Wed, 7 Dec 2005 16:52:19 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkA1n-0006TZ-Oa 3a3560c552a27eb6454c338d6c44f750 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/43386cb61cb22e77b7f970ac28a22acf@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10882 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 00:56:38 +0000 Content-Transfer-Encoding: quoted-printable On Dec 3, 2005, at 3:11 PM, Wilfredo S=E1nchez Vega wrote: > On Nov 29, 2005, at 1:43 PM, Lisa Dusseault wrote: >> >> Do other people consider this behavior to be incorrect according to=20= >> the spec? (I'm assuming the explanation is correct and it aligns=20 >> with what I've seen). But it seems that within-second changes do not=20= >> guarantee "semantic equivalence" as required by HTTP. >> >> Lisa > > My best read of the spec leads me to believe that this is not=20 > correct as per the spec. > > A more correct solution may be to append something to the strong=20 > ETag if it is in the same timespan as now instead of using a weak ETag=20= > in that case. > > However, this doesn't address the problem of correctly changing the=20= > ETag if multiple changes occur within a subsecond timespan. But then,=20= > neither does the weak ETag trick. > > If people agree that Apache HTTPd is incorrect here, I'll be happy=20= > to implement, lobby for and commit an appropriate change for future=20 > versions. > Wow, that would be fantastic. But I bet you'd get a strong reply if=20 you asked such a question on the Apache list. Lisa From w3c-dist-auth-request@frink.w3.org Wed Dec 07 20:03:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAC5-0002Tb-FI for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 20:03:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04526 for ; Wed, 7 Dec 2005 20:02:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkABT-0000W5-CF for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 01:02:55 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkABK-0000Td-Ts for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 01:02:47 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkA8C-0000MC-HV for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 01:02:45 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jB80xFQs029127; Wed, 7 Dec 2005 16:59:15 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay7.apple.com (Apple SCV relay) with ESMTP id CBA50AE; Wed, 7 Dec 2005 16:59:14 -0800 (PST) In-Reply-To: <43386cb61cb22e77b7f970ac28a22acf@osafoundation.org> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <43386cb61cb22e77b7f970ac28a22acf@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Julian Reschke , WebDAV Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 7 Dec 2005 16:59:14 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkA8C-0000MC-HV b12bb6d24637c7962be1643dda2aa655 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/F7916F49-868C-492F-A7EB-B9CA815D0899@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10883 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 01:02:55 +0000 Content-Transfer-Encoding: 7bit On Dec 7, 2005, at 4:52 PM, Lisa Dusseault wrote: > Wow, that would be fantastic. But I bet you'd get a strong reply > if you asked such a question on the Apache list. I was hoping for an answer here first. :-) That is, I'd like a could of voices other than me to agree that Apache HTTPd's behaviour is out-of-spec. -wsv From w3c-dist-auth-request@frink.w3.org Wed Dec 07 20:50:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkAvy-0005Fg-Li for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 20:50:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07871 for ; Wed, 7 Dec 2005 20:50:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkAuv-0000ZE-6w for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 01:49:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkAuk-0000Xg-PZ for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 01:49:43 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkAub-0002x6-IM for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 01:49:41 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB81nNj8003889 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 7 Dec 2005 17:49:23 -0800 (PST) In-Reply-To: References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> Cc: Lisa Dusseault , Julian Reschke , WebDAV Content-Transfer-Encoding: quoted-printable From: Jim Whitehead Date: Wed, 7 Dec 2005 17:49:22 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1EkAub-0002x6-IM 28f82e4c0ca496add15e5b26b184d9d4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10884 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 01:49:53 +0000 Content-Transfer-Encoding: quoted-printable I don't have a firm read on whether the Apache HTTPd behavior is non-=20 compliant. However, I strongly feel that its current behavior is very =20= bad for clients. What clients really need is for the ETag to not change unless the =20 content changes. So, if an ETag starts out weak, it should stay weak. If it starts =20 strong, it should stay strong. The weak->strong transition is a =20 problem. I don't think clients care particularly about weak vs strong =20= etags. In fact, if the server does some amount of background =20 processing on the content, but returns a semantically equivalent =20 representation then the server should be using weak etags =20 consistently, AFAIK. For example, if a CalDAV server receives an =20 event, bursts it out into its database, then reconstructs a slightly =20 different XML representation that is semantically equivalent, it =20 should only be using weak etags in this case to represent the fact =20 that there are minor tweaks to the representation of the resource. - Jim On Dec 3, 2005, at 3:11 PM, Wilfredo S=E1nchez Vega wrote: > > On Nov 29, 2005, at 1:43 PM, Lisa Dusseault wrote: > >> On Nov 29, 2005, at 1:12 PM, Julian Reschke wrote: >>> >>> Wilfredo S=E1nchez Vega wrote: >>>> Question for you. >>>> Apache HTTPD emits a weak etag for a file resource if the =20 >>>> timestamp on the file is the same as the current time (one =20 >>>> second accuracy) and a strong etag otherwise. >>>> The reason for that logic, as I understand it, is that because =20= >>>> the etag generation depends on the timestamp and that the file =20 >>>> may change multiple times within a one-second period, an etag =20 >>>> generated from a timestamp matching the current time isn't =20 >>>> reliable. >>> >>> Finally a good explanation. >> >> Do other people consider this behavior to be incorrect according =20 >> to the spec? (I'm assuming the explanation is correct and it =20 >> aligns with what I've seen). But it seems that within-second =20 >> changes do not guarantee "semantic equivalence" as required by HTTP. >> >> Lisa > > My best read of the spec leads me to believe that this is not =20 > correct as per the spec. > > A more correct solution may be to append something to the strong =20 > ETag if it is in the same timespan as now instead of using a weak =20 > ETag in that case. > > However, this doesn't address the problem of correctly changing =20 > the ETag if multiple changes occur within a subsecond timespan. =20 > But then, neither does the weak ETag trick. > > If people agree that Apache HTTPd is incorrect here, I'll be =20 > happy to implement, lobby for and commit an appropriate change for =20 > future versions. > > -wsv > > From w3c-dist-auth-request@frink.w3.org Wed Dec 07 21:36:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBe3-0006sy-Mo for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 21:36:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12247 for ; Wed, 7 Dec 2005 21:35:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkBdE-000647-AX for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 02:35:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkBd6-000637-DR for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 02:35:32 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkBaI-0004fp-Kf for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 02:35:31 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jB82W5lc009491; Wed, 7 Dec 2005 18:32:05 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 5B119324002; Wed, 7 Dec 2005 18:32:05 -0800 (PST) In-Reply-To: <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> Cc: Lisa Dusseault , Julian Reschke , WebDAV Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 7 Dec 2005 18:32:04 -0800 To: Jim Whitehead X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkBaI-0004fp-Kf 89c1610de9fdf62eb2764e4ece6fbea2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10885 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 02:35:40 +0000 Content-Transfer-Encoding: 7bit On Dec 7, 2005, at 5:49 PM, Jim Whitehead wrote: > I don't have a firm read on whether the Apache HTTPd behavior is > non-compliant. However, I strongly feel that its current behavior > is very bad for clients. > > What clients really need is for the ETag to not change unless the > content changes. Well, I'd argue that what they *really* need is for the ETag to change if the content changes. While I agree than changing the ETag for otherwise-same content is inconvenient and best avoided, unless it's happening a lot (it this case it happens at most once), I don't see that as tragic. Note that this situation only arises during the one-second span of time that a resource is modified. That does mean that it's almost always going to yield the "temporary" ETag on a PUT request, but rarely on a GET. As long as httpd is using a filesystem timestamp to compute the ETag, this is going to be unavoidable. An MD5 hash would be a great ETag, but it, and anything that involves opening the file, is far more expensive to compute. I think the trade-off here is a reasonable one, given the data we have available. The other option is to punt and not emit an ETag, since we arguably don't have accurate enough information. But I think that would be worse. Anyway, whether it changes or not is unrelated to the issue I'm angling for, which is whether the use of a weak etag is wrong. > So, if an ETag starts out weak, it should stay weak. If it starts > strong, it should stay strong. The weak->strong transition is a > problem. I don't think clients care particularly about weak vs > strong etags. In fact, if the server does some amount of background > processing on the content, but returns a semantically equivalent > representation then the server should be using weak etags > consistently, AFAIK. For example, if a CalDAV server receives an > event, bursts it out into its database, then reconstructs a > slightly different XML representation that is semantically > equivalent, it should only be using weak etags in this case to > represent the fact that there are minor tweaks to the > representation of the resource. OK, that's a vote for "the weak etag is wrong". -wsv From w3c-dist-auth-request@frink.w3.org Wed Dec 07 21:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBgD-0007aD-6S for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 21:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12311 for ; Wed, 7 Dec 2005 21:37:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkBfe-0006M6-88 for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 02:38:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkBfc-0006LY-B9 for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 02:38:08 +0000 Received: from rgminet01.oracle.com ([148.87.122.30]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkBeq-0001ZO-CE for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 02:38:06 +0000 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jB82bEjk001049; Wed, 7 Dec 2005 19:37:14 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jB82bEIT017525; Wed, 7 Dec 2005 19:37:14 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-247.vpn.oracle.com [141.144.96.247]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB82b58U017478; Wed, 7 Dec 2005 19:37:07 -0700 Message-ID: <43979C55.9040408@oracle.com> Date: Wed, 07 Dec 2005 21:37:09 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: webdav WG , briank@networkresonance.com, Lisa Dusseault Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Received-SPF: none (maggie.w3.org: domain of bernard.desruisseaux@oracle.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EkBeq-0001ZO-CE 0afb1a6fa74b49f69684cdf24967a505 X-Original-To: w3c-dist-auth@w3.org Subject: draft-ietf-webdav-quota-07.txt: DAV:quota-not-exceeded X-Archived-At: http://www.w3.org/mid/43979C55.9040408@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10886 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 02:38:10 +0000 Content-Transfer-Encoding: 7bit In Section 6. Error reporting shouldn't DAV:quota-not-exceeded be a postcondition instead of a precondition? Cheers, Bernard From w3c-dist-auth-request@frink.w3.org Wed Dec 07 21:52:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBtG-0002BU-D1 for webdav-archive@megatron.ietf.org; Wed, 07 Dec 2005 21:52:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13548 for ; Wed, 7 Dec 2005 21:51:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkBsI-0003AS-V0 for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 02:51:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkBsD-00039B-Lz for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 02:51:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkBs7-00081y-0y for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 02:51:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB82p23H002882; Wed, 7 Dec 2005 18:51:02 -0800 Date: Wed, 7 Dec 2005 18:51:02 -0800 Message-Id: <200512080251.jB82p23H002882@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkBs7-00081y-0y dea93f3afca56ad80d485d4f5cf729d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512080251.jB82p23H002882@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10887 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 02:51:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From wsanchez@wsanchez.net 2005-12-07 18:51 ------- I still maintain that it is unreasonable to require a server to preserve namespace prefixes. WebDAV requires that server authors understand XML and XML namespaces. Adding requirements imposed by additional specifications (XSLT, etc.) puts an undo burden on server authors, given that some XML libraries, when asked to simply read XML into a DOM and then render that XML *do* rewrite namespace prefixes. If a server author can't simply ask a library to render the XML and instead has to dive into the innards of the library or write their own renderer, you've obviated the alleged value of using XML in the first place. Dealing with XML in WebDAV is hard enough as things are. This is especially bothersome given that if a client cares about preserving XML exactly as given, than a simple encoding of the XML will guarantee that, and the server can remain blissfully ignorant of that content. If you instead put the XML elements in a property, the server *has to* parse them, and clients should be willing to accept the consequenses of that. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 08 03:54:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHXU-0002cj-Bn for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:54:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14743 for ; Thu, 8 Dec 2005 03:53:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkHVS-00080N-J4 for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 08:52:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkHV7-0007xn-Dh for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 08:51:41 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EkHS4-0004pP-FO for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 08:51:40 +0000 Received: (qmail invoked by alias); 08 Dec 2005 08:41:48 -0000 Received: from p508FB3EC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.236] by mail.gmx.net (mp023) with SMTP; 08 Dec 2005 09:41:48 +0100 X-Authenticated: #1915285 Message-ID: <4397F187.3020303@gmx.de> Date: Thu, 08 Dec 2005 09:40:39 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <200512051101.jB5B1lqL031501@ietf.cse.ucsc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkHS4-0004pP-FO e987c9274042e6a9daeaa3f4e2e0d425 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/4397F187.3020303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10888 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 08:52:02 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Dec 5, 2005, at 3:01 AM, bugzilla@soe.ucsc.edu wrote: > >> >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 >> >> ------- Additional Comments From julian.reschke@greenbytes.de >> 2005-12-05 03:01 ------- >> >>> - Does it make sense to say that on attributes, [attributes] must be >>> preserved? >>> I think this was a cut-and-paste error so I am leaving it out. >> >> It's a mistake. Please let's dicuss this change over here, and only >> integrate it >> when done. > > Ok; in what sense are there attributes on attributes? As far as I can > tell, Infoset talks about attributes having namespace name, local name, > prefix, normalized value, type, references, owner (like parent) and the > specified flag. As I said: it was a mistake. Attributes do not have attributes. >>> - Did you consider whether [references] ought to be preserved on >>> attributes? >>> What's the consequence if they're not? >> >> As far as I can tell, this question is meaningless at it doesn't >> affect the >> serialization. > > Why is that? I'm not sure how to answer that... What's relevant to us is what's going over the wire, thus the XML serialization. That part of the Infoset doesn't seem to be relevant here. Am I missing something? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 08 04:03:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHgV-00052W-OI for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 04:03:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15970 for ; Thu, 8 Dec 2005 04:02:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkHfn-0003Bu-8J for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 09:02:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkHfZ-0003Ar-5a for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 09:02:29 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EkHfL-0002Iu-EI for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 09:02:26 +0000 Received: (qmail invoked by alias); 08 Dec 2005 08:54:45 -0000 Received: from p508FB3EC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.236] by mail.gmx.net (mp028) with SMTP; 08 Dec 2005 09:54:45 +0100 X-Authenticated: #1915285 Message-ID: <4397F490.5000109@gmx.de> Date: Thu, 08 Dec 2005 09:53:36 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512021734.jB2HYffR003632@ietf.cse.ucsc.edu> <43972EE0.7040106@cse.ucsc.edu> In-Reply-To: <43972EE0.7040106@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkHfL-0002Iu-EI 009d13f9a13197a05d5ad584557827dc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Client comments? X-Archived-At: http://www.w3.org/mid/4397F490.5000109@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10889 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 09:02:43 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > > bugzilla@soe.ucsc.edu wrote: > >> ------- Additional Comments From elias@cse.ucsc.edu 2005-12-02 09:34 >> ------- >> Rough consensu reached on the 12/2 telecon wrt Julians proposed text, >> modulo >> some minor tweaks to the language ('clients will...') and remaining >> nit about >> handling of comments. Elias to raise issue regarding the handling of >> comments on >> the list. >> > Right, so regarding the handling of XML comments in property values... > > My 10,000 ft. understanding of the issue is as follows: > * It would generally be preferred if comments were preserved > * Currently (most? all?) servers do not preserve comments I think all I tested recently. > * The relevant XML specs allow for comments to be dropped by parsers and > they do ...allows them to be dropped by parsers, yes, but I don't think many parsers do so. It's the servers who drop them. > Based on the above, it seems clear that 2518bis cannot require comments > MUST be preserved, although the WG does want to say something that will > encourage servers to attempt to do so. It would be nice to hear some > input from client (and server) implementers on this issue. Do note that > the obvious workaround for clients that want to force servers to > preserve comments should put them in as CDATA, which will be preserved. ...which will make those property values behave extremely strange in general purpose clients (will display escaped XML including the comment) or with things like SEARCH. > Open questions for further discussion: > * Do clients want or expect comments to be preserved? We do not. > * Would it be acceptable to server implementers for 2518bis to define > the preservation of comments as a SHOULD and will they make the effort? If there's support for that requirement, we can implement it. > Furhter, is this even possible given the libraries they are using? I think: in general yes, but there's no guarantee that every XML parser will do it. This is more likely to be a problem in size-constrained devices though (where there may be a "minimal" XML parser installed), not on servers. > * Will client implementers accept wording to the effect that servers MAY > NOT preserve comments and, if they are truely required, mention the > above workaround? "MAY NOT" reflects the current state of the art. > * Should 2518bis support different requirements for live vs. dead > properties? This seems to make sense... I'm not sure how the distinction between live and dead properties is of any relevance here (and thus confusing). In particular, the whole issue only applies to things you can PROPPATCH, right? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 08 08:06:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkLTE-0005tZ-E6 for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 08:06:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11544 for ; Thu, 8 Dec 2005 08:05:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkLRq-0004jb-58 for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 13:04:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkLRg-0004h8-St for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 13:04:25 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EkLRY-00057k-Bt for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 13:04:23 +0000 Received: (qmail invoked by alias); 08 Dec 2005 13:03:57 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 08 Dec 2005 14:03:57 +0100 X-Authenticated: #1915285 Message-ID: <43982EE8.1060103@gmx.de> Date: Thu, 08 Dec 2005 14:02:32 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Jim Whitehead , Lisa Dusseault , WebDAV References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> In-Reply-To: <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkLRY-00057k-Bt eee1a7d5577e3973695ea4a2f10efa65 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/43982EE8.1060103@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10890 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 13:04:34 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA11544 Wilfredo S=E1nchez Vega wrote: > On Dec 7, 2005, at 5:49 PM, Jim Whitehead wrote: >=20 >> I don't have a firm read on whether the Apache HTTPd behavior is=20 >> non-compliant. However, I strongly feel that its current behavior is=20 >> very bad for clients. >> >> What clients really need is for the ETag to not change unless the=20 >> content changes. >=20 > Well, I'd argue that what they *really* need is for the ETag to chang= e=20 > if the content changes. +1 > While I agree than changing the ETag for otherwise-same content is=20 > inconvenient and best avoided, unless it's happening a lot (it this cas= e=20 > it happens at most once), I don't see that as tragic. I note that I changed my own opinion several times now. One possible=20 interpretation of Apache's behaviour is that in the case where content=20 indeed changes several times within a second, a client may *want* not to=20 have to re-sync until the resource is stable again. This is achieved by=20 the current implementation. > Note that this situation only arises during the one-second span of=20 > time that a resource is modified. That does mean that it's almost=20 > always going to yield the "temporary" ETag on a PUT request, but rarely= =20 > on a GET. >=20 > As long as httpd is using a filesystem timestamp to compute the ETag,= =20 > this is going to be unavoidable. An MD5 hash would be a great ETag, bu= t=20 > it, and anything that involves opening the file, is far more expensive=20 > to compute. I think the trade-off here is a reasonable one, given the=20 > data we have available. The other option is to punt and not emit an=20 > ETag, since we arguably don't have accurate enough information. But I=20 > think that would be worse. >=20 > Anyway, whether it changes or not is unrelated to the issue I'm=20 > angling for, which is whether the use of a weak etag is wrong. >=20 >> So, if an ETag starts out weak, it should stay weak. If it starts=20 >> strong, it should stay strong. The weak->strong transition is a=20 >> problem. I don't think clients care particularly about weak vs strong=20 >> etags. In fact, if the server does some amount of background=20 >> processing on the content, but returns a semantically equivalent=20 >> representation then the server should be using weak etags=20 >> consistently, AFAIK. For example, if a CalDAV server receives an=20 >> event, bursts it out into its database, then reconstructs a slightly=20 >> different XML representation that is semantically equivalent, it=20 >> should only be using weak etags in this case to represent the fact=20 >> that there are minor tweaks to the representation of the resource. I think I disagree here. A few days ago I asked about this on the HTTP=20 mailing list, and the consensus seems to be: - just because a server accepts a PUT and returns a (strong) ETag=20 doesn't mean that it didn't rewrite the contents - the ETag is *not* for the entity body returned with PUT, but for the=20 entity you would get upon a subsequent GET/HEAD - and yes, RFC2616 needs to be clarified (see thread=20 ) > OK, that's a vote for "the weak etag is wrong". My take is that the current drafts requirements for strong ETags and for=20 ETags returned upon PUT are questionable. I think it has been=20 demonstrated that 1) in some cases, weak ETags are just fine, and that 2) a requirement to return an ETag upon PUT will *need* to also clarify=20 what that means The latter optimally would be an erratum to RFC2616, which well require=20 a discussion over on the HTTP mailing list, with proposed text changes=20 and consensus among the readers of the list (I'm *not* volunteering to=20 do this because of other priorities). Best regards, JUlian From w3c-dist-auth-request@frink.w3.org Thu Dec 08 09:49:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkN5A-0005O1-B4 for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 09:49:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22861 for ; Thu, 8 Dec 2005 09:48:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkN41-0000kC-Qb for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 14:48:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkN3t-0000iI-2q for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 14:47:57 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EkN3l-0006az-5n for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 14:47:56 +0000 Received: (qmail invoked by alias); 08 Dec 2005 14:47:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 08 Dec 2005 15:47:31 +0100 X-Authenticated: #1915285 Message-ID: <4398472E.2020600@gmx.de> Date: Thu, 08 Dec 2005 15:46:06 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> In-Reply-To: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkN3l-0006az-5n 671bc93b992bc983c1d578c3c26b35d2 X-Original-To: w3c-dist-auth@w3.org Subject: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/4398472E.2020600@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10891 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 14:48:05 +0000 Content-Transfer-Encoding: 7bit Hi. yesterday's conference call resulted in kind of interesting news on this issues. As far as I can tell, the current authors of the draft for RFC2518bis took the position that the text called GULP - the Grand Unified Locking Proposal (see for instance [1]) - doesn't need to be incorporated into RFC2518bis because all it says is already covered over there. When we discussed BugZilla issue 54 [2], we discovered that there's indeed disagreement on locking semantics, and that we need to resolve that one way or another. So what we ended up are two separate questions, which are: (1) Should there be a single (normative) place in the doc which provides a high-level overview of locking, similar but not necessarily identical with GULP? As far as I can tell, the attendees of the conference call concluded that yes, we want that. (2) What are the semantics for a lock on a resource having multiple bindings (issue 54)? Consider: - A resource Z identified by URLs /foo/a and /foo/b. - Z gets locked by a LOCK request on /foo/a. In this situation, is a lock token required to DELETE /foo/b? GULP's answer to that one is that you don't need the lock token. Removing the URI /foo/b does not affect the state of resource Z, nor does it affect any URL that is protected by that lock (/foo/a and /foo/). A lock token would need to be provided if the resource /foo itself would be locked, but it isn't. On the other hand, a PUT or a PROPPATCH applied to /foo/b will require the lock token because it affects the state of resource Z. This may be confusing, but follows from the fact that the URI of a resource is not part of it's lockable state. My assumption is that any other attempt to define this would be even more confusing. Feedback appreciated, Julian [1] [2] From w3c-dist-auth-request@frink.w3.org Thu Dec 08 10:16:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNVX-0002Cc-Kf for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 10:16:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26425 for ; Thu, 8 Dec 2005 10:15:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkNUg-0005jb-HU for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 15:15:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkNUX-0005Xj-30 for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 15:15:29 +0000 Received: from mx1.init7.net ([213.144.129.5] helo=taguan.init7.net) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkNUD-0000wy-PT for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 15:15:28 +0000 Received: from daddy.numcom.local ([213.144.131.169]) by taguan.init7.net (8.13.4/8.13.4/Debian-3) with ESMTP id jB8FF6YG016012 for ; Thu, 8 Dec 2005 16:15:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Dec 2005 16:14:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <60897A0F7690ED43A1E0995D0534F8FB040100@daddy.numcom.local> Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcX8BpG/FgoSXQa3SZ2xkleIrsEw8wAA03gw From: "Lukas Mathis" To: "WebDav" Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of lukas.mathis@numcom.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkNUD-0000wy-PT 0b3f411b861354f9cca1c2bfd233c83a X-Original-To: w3c-dist-auth@w3.org Subject: RE: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/60897A0F7690ED43A1E0995D0534F8FB040100@daddy.numcom.local Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10892 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 15:15:38 +0000 Content-Transfer-Encoding: quoted-printable > In this situation, is a lock token required to DELETE /foo/b?=20 > GULP's answer to that one is that you don't need the lock=20 > token. (...)=20 > On the other hand, a PUT or a PROPPATCH applied to /foo/b=20 > will require the lock token because it affects the state of=20 > resource Z. Makes sense to me. +1. --=20 Lukas Mathis, Numcom Software AG Hardturmstrasse 66, CH-8005 Z=FCrich Direct +41(0)43-204 06 08 mailto:lukas.mathis@numcom.com, http://www.numcom.com/ From w3c-dist-auth-request@frink.w3.org Thu Dec 08 11:47:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkOvC-0001vr-2C for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 11:47:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08281 for ; Thu, 8 Dec 2005 11:46:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkOu0-0005fj-ML for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 16:45:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkOtr-0005b4-V7 for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 16:45:43 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkOtj-0000IK-50 for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 16:45:43 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB8GjYjj020635 for ; Thu, 8 Dec 2005 11:45:34 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB8GjY5W123822 for ; Thu, 8 Dec 2005 11:45:34 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jB8GjXY8028192 for ; Thu, 8 Dec 2005 11:45:34 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jB8GjXqi028102 for ; Thu, 8 Dec 2005 11:45:33 -0500 In-Reply-To: <4398472E.2020600@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 8 Dec 2005 11:23:54 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/08/2005 11:45:33, Serialize complete at 12/08/2005 11:45:33 Content-Type: multipart/alternative; boundary="=_alternative 005A107D852570D1_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EkOtj-0000IK-50 05527e9f27fba98233e9c939b5faf4fb X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF812C54E3.EBDB621A-ON852570D1.0059256C-852570D1.005A14E6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10893 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 16:45:52 +0000 This is a multipart message in MIME format. --=_alternative 005A107D852570D1_= Content-Type: text/plain; charset="US-ASCII" I agree that the locking semantics outlined for (2) are correct. I also agree that it is essential that there be a single place in the doc which provides a comprehensive normative description of locking semantics (similar, but not necessarily identical to GULP) that provides an answer to questions such as (2). Cheers, Geoff Julian wrote on 12/08/2005 09:46:06 AM: > > yesterday's conference call resulted in kind of interesting > news on this issues. > > As far as I can tell, the current authors of the draft for RFC2518bis > took the position that the text called GULP - the Grand Unified Locking > Proposal (see for instance [1]) - doesn't need to be incorporated into > RFC2518bis because all it says is already covered over there. > > When we discussed BugZilla issue 54 [2], we discovered that there's > indeed disagreement on locking semantics, and that we need to resolve > that one way or another. > > So what we ended up are two separate questions, which are: > > (1) Should there be a single (normative) place in the doc which provides > a high-level overview of locking, similar but not necessarily identical > with GULP? > > As far as I can tell, the attendees of the conference call concluded > that yes, we want that. > > (2) What are the semantics for a lock on a resource having multiple > bindings (issue 54)? Consider: > > - A resource Z identified by URLs /foo/a and /foo/b. > > - Z gets locked by a LOCK request on /foo/a. > > In this situation, is a lock token required to DELETE /foo/b? GULP's > answer to that one is that you don't need the lock token. Removing the > URI /foo/b does not affect the state of resource Z, nor does it affect > any URL that is protected by that lock (/foo/a and /foo/). A lock token > would need to be provided if the resource /foo itself would be locked, > but it isn't. > > On the other hand, a PUT or a PROPPATCH applied to /foo/b will require > the lock token because it affects the state of resource Z. This may be > confusing, but follows from the fact that the URI of a resource is not > part of it's lockable state. My assumption is that any other attempt to > define this would be even more confusing. > > > Feedback appreciated, > > Julian > > > [1] > > [2] > --=_alternative 005A107D852570D1_= Content-Type: text/html; charset="US-ASCII"
I agree that the locking semantics outlined for (2) are correct.

I also agree that it is essential that there be a single
place in the doc which provides a comprehensive
normative description of locking semantics (similar, but
not necessarily identical to GULP) that provides an answer
to questions such as (2).

Cheers,
Geoff

Julian wrote on 12/08/2005 09:46:06 AM:
>
> yesterday's conference call resulted in kind of interesting
> news on this issues.
>
> As far as I can tell, the current authors of the draft for RFC2518bis
> took the position that the text called GULP - the Grand Unified Locking
> Proposal (see for instance [1]) - doesn't need to be incorporated into
> RFC2518bis because all it says is already covered over there.
>
> When we discussed BugZilla issue 54 [2], we discovered that there's
> indeed disagreement on locking semantics, and that we need to resolve
> that one way or another.
>
> So what we ended up are two separate questions, which are:
>
> (1) Should there be a single (normative) place in the doc which provides
> a high-level overview of locking, similar but not necessarily identical
> with GULP?
>
> As far as I can tell, the attendees of the conference call concluded
> that yes, we want that.
>
> (2) What are the semantics for a lock on a resource having multiple
> bindings (issue 54)? Consider:
>
> - A resource Z identified by URLs /foo/a and /foo/b.
>
> - Z gets locked by a LOCK request on /foo/a.
>
> In this situation, is a lock token required to DELETE /foo/b? GULP's
> answer to that one is that you don't need the lock token. Removing the
> URI /foo/b does not affect the state of resource Z, nor does it affect
> any URL that is protected by that lock (/foo/a and /foo/). A lock token
> would need to be provided if the resource /foo itself would be locked,
> but it isn't.
>
> On the other hand, a PUT or a PROPPATCH applied to /foo/b will require
> the lock token because it affects the state of resource Z. This may be
> confusing, but follows from the fact that the URI of a resource is not
> part of it's lockable state. My assumption is that any other attempt to
> define this would be even more confusing.
>
>
> Feedback appreciated,
>
> Julian
>
>
> [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>
>
> [2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>
>
--=_alternative 005A107D852570D1_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 08 12:37:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPhs-0003Xa-Q1 for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 12:37:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15183 for ; Thu, 8 Dec 2005 12:36:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkPgo-0004EU-3b for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 17:36:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkPgg-0004C3-4f for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 17:36:10 +0000 Received: from bay105-dav6.bay105.hotmail.com ([65.54.224.78] helo=hotmail.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EkPgW-0003WQ-Fh for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 17:36:09 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Dec 2005 09:35:56 -0800 Message-ID: Received: from 68.65.245.13 by BAY105-DAV6.phx.gbl with DAV; Thu, 08 Dec 2005 17:35:56 +0000 X-Originating-IP: [68.65.245.13] X-Originating-Email: [digitallysmooth@hotmail.com] X-Sender: digitallysmooth@hotmail.com Reply-To: "DigitallySmooth" From: "DigitallySmooth" To: "IMAP Extensions WG" , "IETF-iCalendar" , "WG Chairs" , "WebDAV WG" , "Lisa Dusseault" References: Date: Thu, 8 Dec 2005 09:35:56 -0800 Organization: DigitallySmooth MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C5FBDA.CA2B3A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-OriginalArrivalTime: 08 Dec 2005 17:35:56.0879 (UTC) FILETIME=[D8A3C5F0:01C5FC1D] Received-SPF: pass (lisa.w3.org: domain of digitallysmooth@hotmail.com designates 65.54.224.78 as permitted sender) X-W3C-Hub-Spam-Status: Yes, score=5.1 X-W3C-Scan-Sig: lisa.w3.org 1EkPgW-0003WQ-Fh 679a478d8e86181c80812790d59337a6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: OT but nice productivity hack: Yubnub to find RFCs, I-Ds and WGs X-Archived-At: http://www.w3.org/mid/BAY105-DAV62032F7B0571942291632A2420@phx.gbl Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10894 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 17:36:18 +0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C5FBDA.CA2B3A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable how do I get off this list? ----- Original Message -----=20 From: Lisa Dusseault=20 To: IMAP Extensions WG ; IETF-iCalendar ; WG Chairs ; WebDAV WG=20 Sent: Wednesday, December 07, 2005 2:10 PM Subject: OT but nice productivity hack: Yubnub to find RFCs, I-Ds and = WGs A co-worker (Jared Rhine) pointed me to Yubnub.org a while back. I = have grown addicted to it as a Internet command-line to jump straight to = what I want. E.g. I use a command like "thes addicted" to quickly find = thesaurus matches: absorbed, accustomed, attached... :)=20 There was one IETF-related yubnub command already and I added two more = very simple ones. To jump to an RFC: rfc xxxx e.g. 'rfc 2822' (don't forget space) Internet-Draft Database Search: (shows list with filename substring = match): ids keyword e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not = draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of = that one To jump to a WG charter: wg wgname e.g. 'wg imapext' Not only do I get to avoid the thesaurus.com web form to find = thesaurus matches, I also avoid the Yubnub Web form because I've set up = Firefox so that I can type a Yubnub command line right into the address = bar. Other possibilities include using the search engine field or a = console app . Fun, fun. Hope it's useful to you too. Let me know if you create other = IETF-related command lines. I'll blog about it or something so as not to = spam people again. Lisa ------=_NextPart_000_001F_01C5FBDA.CA2B3A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
how do I get off this = list?
----- Original Message -----
From:=20 Lisa=20 Dusseault
To: IMAP Extensions WG ; IETF-iCalendar ; WG = Chairs ; WebDAV WG=20
Sent: Wednesday, December 07, = 2005 2:10=20 PM
Subject: OT but nice = productivity hack:=20 Yubnub to find RFCs, I-Ds and WGs


A co-worker (Jared Rhine) pointed me to Yubnub.org = a while=20 back. I have grown addicted to it as a Internet command-line to jump = straight=20 to what I want. E.g. I use a command like "thes addicted" to quickly = find=20 thesaurus matches: absorbed, accustomed, attached... :)

There = was one=20 IETF-related yubnub command already and I added two more very simple=20 ones.

To jump to an RFC: rfc xxxx
e.g. 'rfc 2822' = (don't=20 forget space)

Internet-Draft Database Search: (shows list with = filename=20 substring match): ids keyword
e.g. 'ids dusseault' to find=20 draft-dusseault-caldav-08, but not draft-ietf-webdav-rfc2518bis = because=20 'dusseault' isn't in the title of that one

To jump to a WG = charter:=20 wg wgname
e.g. 'wg imapext'

Not only do I get to = avoid the=20 thesaurus.com web form to find thesaurus matches, I also avoid the = Yubnub Web=20 form because I've set up Firefox so that I can type a Yubnub command = line=20 right into the address bar. Other possibilities include using the = search=20 engine field or a console app=20 = <http://www.yubnub.org/documentation/describe_installation>.
Fun,=20 fun. Hope it's useful to you too. Let me know if you create other = IETF-related=20 command lines. I'll blog about it or something so as not to spam = people=20 again.

Lisa

------=_NextPart_000_001F_01C5FBDA.CA2B3A00-- From w3c-dist-auth-request@frink.w3.org Thu Dec 08 12:38:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPiX-00047t-9w for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 12:38:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15258 for ; Thu, 8 Dec 2005 12:37:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkPhq-0005Y5-6j for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 17:37:22 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkPho-0005X0-9r for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 17:37:20 +0000 Received: from bay105-dav6.bay105.hotmail.com ([65.54.224.78] helo=hotmail.com) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkPgo-0000Kt-04 for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 17:37:19 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Dec 2005 09:36:15 -0800 Message-ID: Received: from 68.65.245.13 by BAY105-DAV6.phx.gbl with DAV; Thu, 08 Dec 2005 17:36:15 +0000 X-Originating-IP: [68.65.245.13] X-Originating-Email: [digitallysmooth@hotmail.com] X-Sender: digitallysmooth@hotmail.com Reply-To: "DigitallySmooth" From: "DigitallySmooth" To: , References: <200512072147.jB7Ll3ON002580@ietf.cse.ucsc.edu> Date: Thu, 8 Dec 2005 09:36:15 -0800 Organization: DigitallySmooth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-OriginalArrivalTime: 08 Dec 2005 17:36:15.0535 (UTC) FILETIME=[E3C273F0:01C5FC1D] Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of digitallysmooth@hotmail.com designates 65.54.224.78 as permitted sender) X-W3C-Hub-Spam-Status: No, score=1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkPgo-0000Kt-04 bff964e0048b3e0aaec5c7162343d787 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 120] DEEP_LOCK_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/BAY105-DAV68BC5EF6106694FF0FF0DA2420@phx.gbl Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10895 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 17:37:22 +0000 Content-Transfer-Encoding: 7bit how do I get off this list please? ----- Original Message ----- From: To: Sent: Wednesday, December 07, 2005 1:47 PM Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 > > lisa@osafoundation.org changed: > > What |Removed |Added > -------------------------------------------------------------------------- -- > Status|NEW |RESOLVED > Resolution| |FIXED > > > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > > From w3c-dist-auth-request@frink.w3.org Thu Dec 08 14:55:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRrc-0007tx-Ln for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 14:55:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03518 for ; Thu, 8 Dec 2005 14:54:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkRqM-00031P-U4 for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 19:54:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkRLk-0004dk-PD for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 19:22:40 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkR6p-0006Bb-Jt for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 19:07:24 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jB8J6vcA014436; Thu, 8 Dec 2005 11:06:57 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id B2B9F3B2; Thu, 8 Dec 2005 11:06:57 -0800 (PST) In-Reply-To: <43982EE8.1060103@gmx.de> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> Cc: Jim Whitehead , Lisa Dusseault , WebDAV Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 8 Dec 2005 11:06:56 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EkR6p-0006Bb-Jt 1ae789296922a6bc613f3c8c29c9a84f X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10896 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 19:54:18 +0000 Content-Transfer-Encoding: quoted-printable On Dec 8, 2005, at 5:02 AM, Julian Reschke wrote: > > Wilfredo S=E1nchez Vega wrote: >> On Dec 7, 2005, at 5:49 PM, Jim Whitehead wrote: >>> I don't have a firm read on whether the Apache HTTPd behavior is =20 >>> non-compliant. However, I strongly feel that its current behavior =20= >>> is very bad for clients. >>> >>> What clients really need is for the ETag to not change unless the =20= >>> content changes. >> Well, I'd argue that what they *really* need is for the ETag to =20 >> change if the content changes. > > +1 > >> While I agree than changing the ETag for otherwise-same content =20 >> is inconvenient and best avoided, unless it's happening a lot (it =20 >> this case it happens at most once), I don't see that as tragic. > > I note that I changed my own opinion several times now. One =20 > possible interpretation of Apache's behaviour is that in the case =20 > where content indeed changes several times within a second, a =20 > client may *want* not to have to re-sync until the resource is =20 > stable again. This is achieved by the current implementation. Yes, but it would also be achieved if a strong ETag was delivered =20 during the first second (including on PUT). Use of a weak ETag =20 doesn't help with that, as far as I can tell. My read is that the using a strong ETag in the first second would =20 be more correct than the current implementation and that issuing no =20 ETag at all in the first second would be the most correct. But the =20 latter may be more problematic in a practical sense than the former, =20 despite being more correct. >>> So, if an ETag starts out weak, it should stay weak. If it starts =20= >>> strong, it should stay strong. The weak->strong transition is a =20 >>> problem. I don't think clients care particularly about weak vs =20 >>> strong etags. In fact, if the server does some amount of =20 >>> background processing on the content, but returns a semantically =20 >>> equivalent representation then the server should be using weak =20 >>> etags consistently, AFAIK. For example, if a CalDAV server =20 >>> receives an event, bursts it out into its database, then =20 >>> reconstructs a slightly different XML representation that is =20 >>> semantically equivalent, it should only be using weak etags in =20 >>> this case to represent the fact that there are minor tweaks to =20 >>> the representation of the resource. > > I think I disagree here. A few days ago I asked about this on the =20 > HTTP mailing list, and the consensus seems to be: > > - just because a server accepts a PUT and returns a (strong) ETag =20 > doesn't mean that it didn't rewrite the contents > > - the ETag is *not* for the entity body returned with PUT, but for =20 > the entity you would get upon a subsequent GET/HEAD > > - and yes, RFC2616 needs to be clarified > > (see thread 2005OctDec/thread.html#13>) Consensus on that thread seems to be that a ETag on PUT should be =20 the ETag you'd get on a subsequent GET. I don't see any discussion =20 about strong vs. weak and whether changing from strong to weak and =20 back is a good idea, which is, I think the point that Jim was making. >> OK, that's a vote for "the weak etag is wrong". > > My take is that the current drafts requirements for strong ETags =20 > and for ETags returned upon PUT are questionable. I think it has =20 > been demonstrated that > > 1) in some cases, weak ETags are just fine, and that > > 2) a requirement to return an ETag upon PUT will *need* to also =20 > clarify what that means > > The latter optimally would be an erratum to RFC2616, which well =20 > require a discussion over on the HTTP mailing list, with proposed =20 > text changes and consensus among the readers of the list (I'm *not* =20= > volunteering to do this because of other priorities). I'm not sure why you think the requirements for strong ETags in =20 the current HTTP spec is a problem. I agree that clarification on =20 the expected ETag on PUT would be useful. -wsv From w3c-dist-auth-request@frink.w3.org Thu Dec 08 15:54:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSmA-00087Q-3u for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 15:54:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09690 for ; Thu, 8 Dec 2005 15:53:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkSkp-0004zZ-NQ for w3c-dist-auth-dist@listhub.w3.org; Thu, 08 Dec 2005 20:52:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkSkd-0004ut-JA for w3c-dist-auth@listhub.w3.org; Thu, 08 Dec 2005 20:52:27 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1EkSkV-00036p-7I for w3c-dist-auth@w3.org; Thu, 08 Dec 2005 20:52:27 +0000 Received: (qmail invoked by alias); 08 Dec 2005 20:52:16 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 08 Dec 2005 21:52:16 +0100 X-Authenticated: #1915285 Message-ID: <43989C90.6070103@gmx.de> Date: Thu, 08 Dec 2005 21:50:24 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Jim Whitehead , Lisa Dusseault , WebDAV References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> In-Reply-To: <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EkSkV-00036p-7I 819a9a00695bef2b5e9f43f5b2f7008f X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/43989C90.6070103@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10897 X-Loop: w3c-dist-auth@w3.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, 08 Dec 2005 20:52:39 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09690 Wilfredo S=E1nchez Vega wrote: > ... > Yes, but it would also be achieved if a strong ETag was delivered=20 > during the first second (including on PUT). Use of a weak ETag doesn't= =20 > help with that, as far as I can tell. But with the current algorithm, the server can't return a strong ETag,=20 unless it blocks updates of that content for one second. That may be=20 unacceptable for some resources. > ... >> I think I disagree here. A few days ago I asked about this on the HTTP= =20 >> mailing list, and the consensus seems to be: >> >> - just because a server accepts a PUT and returns a (strong) ETag=20 >> doesn't mean that it didn't rewrite the contents >> >> - the ETag is *not* for the entity body returned with PUT, but for the= =20 >> entity you would get upon a subsequent GET/HEAD >> >> - and yes, RFC2616 needs to be clarified >> >> (see thread=20 >> )=20 >> >=20 > Consensus on that thread seems to be that a ETag on PUT should be the= =20 > ETag you'd get on a subsequent GET. I don't see any discussion about=20 > strong vs. weak and whether changing from strong to weak and back is a=20 > good idea, which is, I think the point that Jim was making. Yes, that question wasn't asked over there. >>> OK, that's a vote for "the weak etag is wrong". >> >> My take is that the current drafts requirements for strong ETags and=20 >> for ETags returned upon PUT are questionable. I think it has been=20 >> demonstrated that >> >> 1) in some cases, weak ETags are just fine, and that >> >> 2) a requirement to return an ETag upon PUT will *need* to also=20 >> clarify what that means >> >> The latter optimally would be an erratum to RFC2616, which well=20 >> require a discussion over on the HTTP mailing list, with proposed text= =20 >> changes and consensus among the readers of the list (I'm *not*=20 >> volunteering to do this because of other priorities). >=20 > I'm not sure why you think the requirements for strong ETags in the=20 > current HTTP spec is a problem. I agree that clarification on the=20 I was talking about the current version of RFC2518bis... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 08 19:23:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkW37-0002L2-VO for webdav-archive@megatron.ietf.org; Thu, 08 Dec 2005 19:23:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11577 for ; Thu, 8 Dec 2005 19:22:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkW1R-00083G-32 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 00:22:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkW1H-00081e-RV for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 00:21:51 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkW1B-0004l4-2W for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 00:21:51 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jB90LPcn023411; Thu, 8 Dec 2005 16:21:28 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 3288D375; Thu, 8 Dec 2005 16:21:25 -0800 (PST) In-Reply-To: <43989C90.6070103@gmx.de> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> <43989C90.6070103@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> Cc: Jim Whitehead , Lisa Dusseault , WebDAV Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 8 Dec 2005 16:21:24 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EkW1B-0004l4-2W bad59655dd224b4a8b709052ef61302d X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10898 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 00:22:01 +0000 Content-Transfer-Encoding: 7bit On Dec 8, 2005, at 12:50 PM, Julian Reschke wrote: > But with the current algorithm, the server can't return a strong > ETag, unless it blocks updates of that content for one second. That > may be unacceptable for some resources. Why couldn't it? Just append a suffix or prefix? What HTTPd does right now is use the same ETag string but prefixes it with 'W/' to make it weak. This accomplishes the goal of making the first-second etag different, but I think it should do that without making the tag weak, which implies something that isn't the case. -wsv From w3c-dist-auth-request@frink.w3.org Fri Dec 09 05:06:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekf9K-0004jQ-Tt for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 05:06:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10794 for ; Fri, 9 Dec 2005 05:05:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekf7a-0002fE-4w for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 10:04:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekf7Q-0002cn-Q1 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 10:04:49 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1Ekf6S-0006Hg-3W for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 10:04:45 +0000 Received: (qmail invoked by alias); 09 Dec 2005 10:02:48 -0000 Received: from p508FAFFC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.252] by mail.gmx.net (mp012) with SMTP; 09 Dec 2005 11:02:48 +0100 X-Authenticated: #1915285 Message-ID: <43995600.6070808@gmx.de> Date: Fri, 09 Dec 2005 11:01:36 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512080251.jB82p23H002882@ietf.cse.ucsc.edu> In-Reply-To: <200512080251.jB82p23H002882@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekf6S-0006Hg-3W be00cf9f39f28fc1f18d75685e812b9b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/43995600.6070808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10899 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 10:04:58 +0000 Content-Transfer-Encoding: 7bit Wilfredo, thanks for the feedback. In our conference call, when we discussed this, the rational was that if we want server implementors to implement this at some point int the future, we need to tell them now. This is not extraordinary when upgrading specs. More comments: > I still maintain that it is unreasonable to require a server to preserve namespace prefixes. WebDAV > requires that server authors understand XML and XML namespaces. That is correct. > Adding requirements imposed by additional specifications (XSLT, etc.) puts an undo burden on server > authors, given that some XML libraries, when asked to simply read XML into a DOM and then render I think this is a misunderstanding. Preserving prefixes is not "imposed" by additional specifications. There was never any W3C spec that said that prefixes are irrelevant (or, if there is, please let me know). > that XML *do* rewrite namespace prefixes. If a server author can't simply ask a library to render the > XML and instead has to dive into the innards of the library or write their own renderer, you've obviated > the alleged value of using XML in the first place. Dealing with XML in WebDAV is hard enough as things > are. Yes, and I confess that some years ago, I wrote a library in which I also deliberately threw away prefixes. On the other hand, I really can't think of any W3C spec that licenses parsers or serializers to throw out prefix information. Server implementors will just have to make sure that the libraries they use work properly (just as for other less-well understood XML features). > This is especially bothersome given that if a client cares about preserving XML exactly as given, than a > simple encoding of the XML will guarantee that, and the server can remain blissfully ignorant of that > content. If you instead put the XML elements in a property, the server *has to* parse them, and clients > should be willing to accept the consequenses of that. Escaping XML so it becomes string data solves one problem, but creates lots of others (including weird display in generic clients, and surprising results in SEARCH requests). So I really don't buy in it being a proper solution to this problem in the generic case. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 05:07:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekf9e-0005DC-9z for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 05:07:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10841 for ; Fri, 9 Dec 2005 05:06:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekf93-0003Wh-K4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 10:06:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekf92-0003W6-7O for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 10:06:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekf8r-0005bu-0P for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 10:06:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9A6E4x004539; Fri, 9 Dec 2005 02:06:14 -0800 Date: Fri, 9 Dec 2005 02:06:14 -0800 Message-Id: <200512091006.jB9A6E4x004539@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekf8r-0005bu-0P 745cfe9edc7f918ec10222a9d824bbad X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512091006.jB9A6E4x004539@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10900 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 10:06:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-09 02:06 ------- Wilfredo, thanks for the feedback. In our conference call, when we discussed this, the rational was that if we want server implementors to implement this at some point int the future, we need to tell them now. This is not extraordinary when upgrading specs. More comments: > I still maintain that it is unreasonable to require a server to preserve namespace prefixes. WebDAV > requires that server authors understand XML and XML namespaces. That is correct. > Adding requirements imposed by additional specifications (XSLT, etc.) puts an undo burden on server > authors, given that some XML libraries, when asked to simply read XML into a DOM and then render I think this is a misunderstanding. Preserving prefixes is not "imposed" by additional specifications. There was never any W3C spec that said that prefixes are irrelevant (or, if there is, please let me know). > that XML *do* rewrite namespace prefixes. If a server author can't simply ask a library to render the > XML and instead has to dive into the innards of the library or write their own renderer, you've obviated > the alleged value of using XML in the first place. Dealing with XML in WebDAV is hard enough as things > are. Yes, and I confess that some years ago, I wrote a library in which I also deliberately threw away prefixes. On the other hand, I really can't think of any W3C spec that licenses parsers or serializers to throw out prefix information. Server implementors will just have to make sure that the libraries they use work properly (just as for other less-well understood XML features). > This is especially bothersome given that if a client cares about preserving XML exactly as given, than a > simple encoding of the XML will guarantee that, and the server can remain blissfully ignorant of that > content. If you instead put the XML elements in a property, the server *has to* parse them, and clients > should be willing to accept the consequenses of that. Escaping XML so it becomes string data solves one problem, but creates lots of others (including weird display in generic clients, and surprising results in SEARCH requests). So I really don't buy in it being a proper solution to this problem in the generic case. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 05:30:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkfWU-0005GH-Ac for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 05:30:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13876 for ; Fri, 9 Dec 2005 05:29:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkfVX-0004pF-Og for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 10:29:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkfVR-0004nI-5L for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 10:29:37 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.50) id 1EkfUv-0008Ls-Oe for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 10:29:33 +0000 Received: (qmail invoked by alias); 09 Dec 2005 09:52:07 -0000 Received: from p508FAFFC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.252] by mail.gmx.net (mp034) with SMTP; 09 Dec 2005 10:52:07 +0100 X-Authenticated: #1915285 Message-ID: <43995379.8050501@gmx.de> Date: Fri, 09 Dec 2005 10:50:49 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Jim Whitehead , Lisa Dusseault , WebDAV References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> <43989C90.6070103@gmx.de> <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> In-Reply-To: <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkfUv-0008Ls-Oe 09b982cdfefe28d59689839f18de8ba5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/43995379.8050501@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10901 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 10:29:43 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA13876 Wilfredo S=E1nchez Vega wrote: >=20 > On Dec 8, 2005, at 12:50 PM, Julian Reschke wrote: >=20 >> But with the current algorithm, the server can't return a strong ETag,= =20 >> unless it blocks updates of that content for one second. That may be=20 >> unacceptable for some resources. >=20 > Why couldn't it? Just append a suffix or prefix? What HTTPd does=20 But where would it get the suffix from? If it had any way to store it,=20 we wouldn't have the problem in the first place... > right now is use the same ETag string but prefixes it with 'W/' to make= =20 > it weak. This accomplishes the goal of making the first-second etag=20 > different, but I think it should do that without making the tag weak,=20 > which implies something that isn't the case. It also accomplishes that clients will not be "forced" to sync multiple=20 times within a second. Consider a resource that changes 10 times per second, then is stable. A=20 hypothetical client that does conditional GET requests will get an=20 arbitrary version of the resource from within the first second, and then=20 later the stable one. Seems to me that this is a good trade-off somehow. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 06:20:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkgIF-0001jj-Fg for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:20:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19282 for ; Fri, 9 Dec 2005 06:19:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkgGs-0001JY-TY for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 11:18:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkgGk-0001HH-30 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 11:18:30 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EkgGa-0004pF-0F for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 11:18:29 +0000 Received: (qmail invoked by alias); 09 Dec 2005 10:52:46 -0000 Received: from p508FAFFC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.252] by mail.gmx.net (mp029) with SMTP; 09 Dec 2005 11:52:46 +0100 X-Authenticated: #1915285 Message-ID: <439961B3.6000901@gmx.de> Date: Fri, 09 Dec 2005 11:51:31 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) 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 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: lisa.w3.org 1EkgGa-0004pF-0F 7844d225415bb96c31ffa4dc7bef6553 X-Original-To: w3c-dist-auth@w3.org Subject: Implementations of draft-ietf-webdav-redirectref-protocol X-Archived-At: http://www.w3.org/mid/439961B3.6000901@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10902 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 11:18:38 +0000 Content-Transfer-Encoding: 7bit Hi. I noticed that the IESG now has the redirect ref spec () on its agenda and was wondering about existing implementations. Here's a summary of implementations I'm aware of: 1) Servers The WebDAV server in SAP Netweaver's Knowledge Management implements draft-ietf-webdav-redirectref-protocol-12, and is expected to be upgraded soon to -13. 2) Clients 2a) The SAP Netweaver KM's remote WebDAV connector implements raft-ietf-webdav-redirectref-protocol-12 (see above) 2b) The SAP Portal Drive Windows client supports discovery and display of redirects (they get mapped to Windows .LNK or .URL files), but does not support authoring redirects. Note that this client is an OEM version of a generic WebDAV client for Windows, so support for redirects potentially will be available in that version as well once other servers start implementing the protocol. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 06:21:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkgJC-0001xF-MB for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:21:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19321 for ; Fri, 9 Dec 2005 06:20:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkgIe-0002Le-36 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 11:20:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkgIY-0002Iy-Il for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 11:20:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkgIG-0005fw-IC for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 11:20:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9BJxeO004597; Fri, 9 Dec 2005 03:19:59 -0800 Date: Fri, 9 Dec 2005 03:19:59 -0800 Message-Id: <200512091119.jB9BJxeO004597@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkgIG-0005fw-IC 989e98ffbdaef6e5577384a35bdafa2d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200512091119.jB9BJxeO004597@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10903 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 11:20:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-09 03:19 ------- I found a minor problem with the language I proposed: the attack is not based on recursively defined internal entities, but on *nested* internal entities. Please update paragraph to: Furthermore, there's also a risk based on the evaluation of "internal entities" as defined in section 4.2.2 of [XML]. A small, carefully crafted request using nested internal entities may require enormous amounts of memory and/or processing time to process. Server implementors should be aware of this risk and configure their XML parsers so that requests like these can be detected and rejected as early as possible. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 08:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiNG-0004jU-FR for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 08:33:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03929 for ; Fri, 9 Dec 2005 08:32:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkiLN-0007Ow-4m for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 13:31:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkiLC-0007MA-5w for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 13:31:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkiL0-0004sF-CG for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 13:31:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9DUk7D004894; Fri, 9 Dec 2005 05:30:46 -0800 Date: Fri, 9 Dec 2005 05:30:46 -0800 Message-Id: <200512091330.jB9DUk7D004894@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkiL0-0004sF-CG 244a3c55018f133d7fce7091fbdea78d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/200512091330.jB9DUk7D004894@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10904 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 13:31:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-09 05:30 ------- > > This is especially bothersome given that if a client cares about > > preserving XML exactly as given, than a > > simple encoding of the XML will guarantee that, and the server can > > remain blissfully ignorant of that > > content. If you instead put the XML elements in a property, the > > server *has to* parse them, and clients > > should be willing to accept the consequenses of that. > Escaping XML so it becomes string data solves one problem, but creates > lots of others (including weird display in generic clients, and > surprising results in SEARCH requests). So I really don't buy in it > being a proper solution to this problem in the generic case. In addition, whatever body defined that property would have to very clearly and very explicitly state that this property never takes a top-level escaped string as a value, and that when an escaped string is returned for that property value, the client should unescape the string before processing the value. Unless this is done, even non-generic clients that are specifically written to understand that property will fail to unescape the string (resulting in even more serious consequences that for a generic client, since a generic client at least won't try to do any significant processing of the value). So escaping the XML is not something that a client writer can do to address this problem ... it would have to be the property definer (and even then, you are likely to get many clients that neglect to do the unescaping). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 08:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiNG-0004jZ-Td for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 08:33:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03932 for ; Fri, 9 Dec 2005 08:32:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkiMa-0007ZZ-3q for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 13:32:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkiMX-0007YI-MZ; Fri, 09 Dec 2005 13:32:38 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkiJL-0003r3-EO; Fri, 09 Dec 2005 13:32:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jB9DTBPq005442; Fri, 9 Dec 2005 08:29:11 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB9DTBYS121918; Fri, 9 Dec 2005 08:29:11 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jB9DTBdR017390; Fri, 9 Dec 2005 08:29:11 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jB9DTBiC017387; Fri, 9 Dec 2005 08:29:11 -0500 In-Reply-To: <43995600.6070808@gmx.de> To: Julian Reschke Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Fri, 9 Dec 2005 08:29:08 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/09/2005 08:29:11, Serialize complete at 12/09/2005 08:29:11 Content-Type: multipart/alternative; boundary="=_alternative 0049FCE9852570D2_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkiJL-0003r3-EO 266bbaafebf949a1236764ae7e1b1e80 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/OF489CA5FB.8DDE42A6-ON852570D2.004840D8-852570D2.0049FD60@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10905 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 13:32:40 +0000 This is a multipart message in MIME format. --=_alternative 0049FCE9852570D2_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/09/2005 05:01:36 AM: > > This is especially bothersome given that if a client cares about > > preserving XML exactly as given, than a > > simple encoding of the XML will guarantee that, and the server can > > remain blissfully ignorant of that > > content. If you instead put the XML elements in a property, the > > server *has to* parse them, and clients > > should be willing to accept the consequenses of that. > Escaping XML so it becomes string data solves one problem, but creates > lots of others (including weird display in generic clients, and > surprising results in SEARCH requests). So I really don't buy in it > being a proper solution to this problem in the generic case. In addition, whatever body defined that property would have to very clearly and very explicitly state that this property never takes a top-level escaped string as a value, and that when an escaped string is returned for that property value, the client should unescape the string before processing the value. Unless this is done, even non-generic clients that are specifically written to understand that property will fail to unescape the string (resulting in even more serious consequences that for a generic client, since a generic client at least won't try to do any significant processing of the value). So escaping the XML is not something that a client writer can do to address this problem ... it would have to be the property definer (and even then, you are likely to get many clients that neglect to do the unescaping). Cheers, Geoff --=_alternative 0049FCE9852570D2_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/09/2005 05:01:36 AM:

> > This is especially bothersome given that if a client cares about
> > preserving XML exactly as given, than a
> > simple encoding of the XML will guarantee that, and the server can
> > remain blissfully ignorant of that
> > content.  If you instead put the XML elements in a property, the
> > server *has to* parse them, and clients
> > should be willing to accept the consequenses of that.

> Escaping XML so it becomes string data solves one problem, but creates
> lots of others (including weird display in generic clients, and
> surprising results in SEARCH requests). So I really don't buy in it
> being a proper solution to this problem in the generic case.

In addition, whatever body defined that property would have to very
clearly and very explicitly state that this property never
takes a top-level escaped string as a value, and that when an escaped
string is returned for that property value, the client should unescape the string
before processing the value.  Unless this is done, even non-generic
clients that are specifically written to understand that property will
fail to unescape the string (resulting in even more serious consequences
that for a generic client, since a generic client at least won't try to
do any significant processing of the value).

So escaping the XML is not something that a client writer can do to address
this problem ... it would have to be the property definer (and even then,
you are likely to get many clients that neglect to do the unescaping).

Cheers,
Geoff
--=_alternative 0049FCE9852570D2_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 09 13:05:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekmd0-0002AB-Jj for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:05:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08853 for ; Fri, 9 Dec 2005 13:04:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekmbv-0002pa-1o for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:04:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekmbm-0002np-60 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:04:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekmba-0003E9-IK for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:04:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9I4O4F005072; Fri, 9 Dec 2005 10:04:24 -0800 Date: Fri, 9 Dec 2005 10:04:24 -0800 Message-Id: <200512091804.jB9I4O4F005072@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekmba-0003E9-IK 674c74f8534106383ba624a33cba0623 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] New: Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512091804.jB9I4O4F005072@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10906 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:04:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 Summary: Move description of lock-null resources into appendix Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.7.6 OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org ...such as the Changes section. Keeping it in 7.6 is IMHO confusing because we don't want servers to implement that. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 13:08:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmfR-0002xQ-LR for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:08:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09243 for ; Fri, 9 Dec 2005 13:07:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekmei-0004YA-IO for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:07:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekmeg-0004Wl-WC for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:07:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkmeX-0006GN-9A for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:07:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9I6xur005093; Fri, 9 Dec 2005 10:06:59 -0800 Date: Fri, 9 Dec 2005 10:06:59 -0800 Message-Id: <200512091806.jB9I6xur005093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkmeX-0006GN-9A 149cd298bd24d913ca87cc689750ebc9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512091806.jB9I6xur005093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10907 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:07:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-09 10:06 ------- I agree. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 13:10:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmhL-0003FG-35 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:10:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09458 for ; Fri, 9 Dec 2005 13:09:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekmgd-00057x-LQ for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:09:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekmga-00056j-D3 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:09:36 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekme8-0006Nb-0Q for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:09:35 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB9I6uV8017579 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 9 Dec 2005 10:06:57 -0800 (PST) In-Reply-To: <43995600.6070808@gmx.de> References: <200512080251.jB82p23H002882@ietf.cse.ucsc.edu> <43995600.6070808@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: WebDAV WG Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Fri, 9 Dec 2005 10:06:56 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekme8-0006Nb-0Q 46e156f8b66f1ac1b7c3527f04ad2835 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/CC116264-DCCC-4E26-BE4C-F801B86188F0@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10908 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:09:39 +0000 Content-Transfer-Encoding: 7bit Wilfredo writes: >> I still maintain that it is unreasonable to require a server to >> preserve namespace prefixes. WebDAV requires that server authors >> understand XML and XML namespaces. I'd like to better understand what the perceived implementation issues are. One issue we create by preserving namespaces is the potential for inconsistency. Consider: Request A uses namespace mapping foo="http://www.webdav.org/" and sets the value of property foo:prop1 using it. Request B uses namespace mapping foo="http://www.ucsc.edu/" and sets the value of property foo:prop2 using it. Request C requests properties prop1 and prop2. Servers could handle this by using appropriately scoped namespace declarations. It would involve a change in XML handling for some servers that put all namespace declarations at the beginning of the multistatus XML response. > >> This is especially bothersome given that if a client cares about >> preserving XML exactly as given, than a simple encoding of the XML >> will guarantee that, and the server can remain blissfully ignorant >> of that content. If you instead put the XML elements in a >> property, the server *has to* parse them, and clients should be >> willing to accept the consequenses of that. > > Escaping XML so it becomes string data solves one problem, but > creates lots of others (including weird display in generic clients, > and surprising results in SEARCH requests). So I really don't buy > in it being a proper solution to this problem in the generic case. I agree. - Jim From w3c-dist-auth-request@frink.w3.org Fri Dec 09 13:39:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekn9u-0001DT-5e for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:39:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13024 for ; Fri, 9 Dec 2005 13:38:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekn8m-0003h2-6b for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:38:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekn8f-0003fm-Cp for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:38:37 +0000 Received: from mail.gmx.net ([213.165.64.21]) by lisa.w3.org with smtp (Exim 4.50) id 1Ekn7p-0001Ax-Fp for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:38:36 +0000 Received: (qmail invoked by alias); 09 Dec 2005 18:37:42 -0000 Received: from p508FC1A2.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.162] by mail.gmx.net (mp007) with SMTP; 09 Dec 2005 19:37:42 +0100 X-Authenticated: #1915285 Message-ID: <4399CE8C.3050307@gmx.de> Date: Fri, 09 Dec 2005 19:35:56 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , WebDAV WG References: <200512080251.jB82p23H002882@ietf.cse.ucsc.edu> <43995600.6070808@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekn7p-0001Ax-Fp 381de8c8c2b221ce1bb0432b20903163 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 10] Round-tripping namespace decls in properties X-Archived-At: http://www.w3.org/mid/4399CE8C.3050307@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10909 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:38:44 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I'd like to better understand what the perceived implementation issues are. > > One issue we create by preserving namespaces is the potential for > inconsistency. > > Consider: > > Request A uses namespace mapping foo="http://www.webdav.org/" and sets > the value of property foo:prop1 using it. > > Request B uses namespace mapping foo="http://www.ucsc.edu/" and sets the > value of property foo:prop2 using it. > > Request C requests properties prop1 and prop2. > > Servers could handle this by using appropriately scoped namespace > declarations. It would involve a change in XML handling for some servers > that put all namespace declarations at the beginning of the multistatus > XML response. Jim, this is a non-issue. Nobody has asked for preserving namespace prefixes for the property element itself. > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 13:58:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknSI-00065o-Pm for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 13:58:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15486 for ; Fri, 9 Dec 2005 13:57:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknRc-0006Ks-2L for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:58:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EknRU-0006Jc-9h for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:58:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EknRL-0000PV-0U for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:58:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9Ivc4O005159; Fri, 9 Dec 2005 10:57:38 -0800 Date: Fri, 9 Dec 2005 10:57:38 -0800 Message-Id: <200512091857.jB9Ivc4O005159@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EknRL-0000PV-0U 4aab2de96ae2beace550b9f3352faa39 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 203] New: DAV:lockdiscovery in multistatus (8.11.8) X-Archived-At: http://www.w3.org/mid/200512091857.jB9Ivc4O005159@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10910 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:58:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=203 Summary: DAV:lockdiscovery in multistatus (8.11.8) Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.8.11.8 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org >From the example: http://example.com/webdav/ HTTP/1.1 424 Failed Dependency also in the explanation: Note also that the DAV: lockdiscovery property for the Request-URI has been included as required. This isn't defined anywhere else, isn't implented and last but not least doesn't make any sense at all. Please remove it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:00:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknTq-0006ZN-P1 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:00:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15773 for ; Fri, 9 Dec 2005 13:59:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknTH-0006hq-2d for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 18:59:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknTD-0006gJ-5x for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:59:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknT4-0002XB-Tz for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:59:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9IxguH005206; Fri, 9 Dec 2005 10:59:42 -0800 Date: Fri, 9 Dec 2005 10:59:42 -0800 Message-Id: <200512091859.jB9IxguH005206@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknT4-0002XB-Tz 82b8931d36c17594a548631a66d802b6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 6] Collection Lock vs MOVE with Overwrite X-Archived-At: http://www.w3.org/mid/200512091859.jB9IxguH005206@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10911 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 18:59:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |93 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:00:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknU6-0006ac-Ob for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:00:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15817 for ; Fri, 9 Dec 2005 13:59:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknTO-00072x-Ft for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:00:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknTE-0006gY-3n for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 18:59:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknT6-0002Xh-0W for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 18:59:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9IxhtW005224; Fri, 9 Dec 2005 10:59:43 -0800 Date: Fri, 9 Dec 2005 10:59:43 -0800 Message-Id: <200512091859.jB9IxhtW005224@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknT6-0002Xh-0W 76e889409f11d4f388098158d25083ec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 93] Write Locks and Collections vs MOVE X-Archived-At: http://www.w3.org/mid/200512091859.jB9IxhtW005224@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10912 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:00:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=93 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |6 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:03:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknWi-0007II-4k for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:03:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16217 for ; Fri, 9 Dec 2005 14:02:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknW8-00021P-01 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:02:52 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EknVx-0001uv-6i for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:02:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EknSj-00069T-SG for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:02:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9IxJK8005184; Fri, 9 Dec 2005 10:59:19 -0800 Date: Fri, 9 Dec 2005 10:59:19 -0800 Message-Id: <200512091859.jB9IxJK8005184@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EknSj-00069T-SG 4480ec399b9f4c0e6ac9377c2803eba7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 6] Collection Lock vs MOVE with Overwrite X-Archived-At: http://www.w3.org/mid/200512091859.jB9IxJK8005184@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10913 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:02:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=6 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 10:59 ------- Fixed by resolution to bug 93 (nearly a duplicate). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:06:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknZe-0008Uv-TA for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:06:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16586 for ; Fri, 9 Dec 2005 14:05:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknZ0-0003kP-JL for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:05:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknYy-0003iz-So for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:05:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknYo-00054G-Qo for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:05:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J5Zwb005307; Fri, 9 Dec 2005 11:05:35 -0800 Date: Fri, 9 Dec 2005 11:05:35 -0800 Message-Id: <200512091905.jB9J5Zwb005307@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknYo-00054G-Qo cfef1f76503ac8b99dddd379e9baa822 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512091905.jB9J5Zwb005307@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10915 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:05:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:06:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknZe-0008Uz-VV for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:06:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16585 for ; Fri, 9 Dec 2005 14:05:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknYk-0003ho-JT for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:05:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknYf-0003gk-F7 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:05:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknYW-0004wL-SA for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:05:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J5JOk005285; Fri, 9 Dec 2005 11:05:19 -0800 Date: Fri, 9 Dec 2005 11:05:19 -0800 Message-Id: <200512091905.jB9J5JOk005285@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknYW-0004wL-SA 30530b23d506731118fb6e94a2342ef4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512091905.jB9J5JOk005285@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10914 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:05:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:06:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknZe-0008Uv-TA for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:06:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16586 for ; Fri, 9 Dec 2005 14:05:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknZ0-0003kP-JL for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:05:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknYy-0003iz-So for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:05:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknYo-00054G-Qo for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:05:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J5Zwb005307; Fri, 9 Dec 2005 11:05:35 -0800 Date: Fri, 9 Dec 2005 11:05:35 -0800 Message-Id: <200512091905.jB9J5Zwb005307@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknYo-00054G-Qo cfef1f76503ac8b99dddd379e9baa822 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512091905.jB9J5Zwb005307@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10915 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:05:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:06:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EknZe-0008Uz-VV for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:06:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16585 for ; Fri, 9 Dec 2005 14:05:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EknYk-0003ho-JT for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:05:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EknYf-0003gk-F7 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:05:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EknYW-0004wL-SA for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:05:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J5JOk005285; Fri, 9 Dec 2005 11:05:19 -0800 Date: Fri, 9 Dec 2005 11:05:19 -0800 Message-Id: <200512091905.jB9J5JOk005285@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EknYW-0004wL-SA 30530b23d506731118fb6e94a2342ef4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512091905.jB9J5JOk005285@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10914 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:05:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:08:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eknba-0001DP-Kb for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:08:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16779 for ; Fri, 9 Dec 2005 14:07:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eknat-0004Oi-82 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:07:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eknar-0004Np-5t for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:07:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eknah-00044J-DP for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:07:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J6tu9005342; Fri, 9 Dec 2005 11:06:55 -0800 Date: Fri, 9 Dec 2005 11:06:55 -0800 Message-Id: <200512091906.jB9J6tu9005342@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eknah-00044J-DP cb20e5a567b918791f03f21dc152beb2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512091906.jB9J6tu9005342@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10916 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:07:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:08:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eknbe-0001E3-81 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:08:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16791 for ; Fri, 9 Dec 2005 14:07:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eknay-0004TV-Ou for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:07:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eknax-0004Qv-1I for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:07:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eknao-00047s-IT for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:07:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J7AEO005354; Fri, 9 Dec 2005 11:07:10 -0800 Date: Fri, 9 Dec 2005 11:07:10 -0800 Message-Id: <200512091907.jB9J7AEO005354@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eknao-00047s-IT 99a85048e815e66a80042ba304c810c7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200512091907.jB9J7AEO005354@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10917 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:07:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkncG-0001dm-LM for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:09:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16884 for ; Fri, 9 Dec 2005 14:08:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eknbg-0004hu-LV for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:08:36 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eknbe-0004gx-Rx for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:08:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EknYB-0000Ji-Dy for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:08:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J4uEN005265; Fri, 9 Dec 2005 11:04:56 -0800 Date: Fri, 9 Dec 2005 11:04:56 -0800 Message-Id: <200512091904.jB9J4uEN005265@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EknYB-0000Ji-Dy 6cb47f2a94fbdf9d234d7b075e5d1d6c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512091904.jB9J4uEN005265@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10918 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:08:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:10:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekndb-0002mK-00 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:10:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17085 for ; Fri, 9 Dec 2005 14:09:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekncu-0005Ou-6B for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:09:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekncs-0005NQ-8V for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:09:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkncU-0004p1-Ug for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:09:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J8uiF005374; Fri, 9 Dec 2005 11:08:56 -0800 Date: Fri, 9 Dec 2005 11:08:56 -0800 Message-Id: <200512091908.jB9J8uiF005374@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkncU-0004p1-Ug c655b3af2e6bb58996e57e4285143b82 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/200512091908.jB9J8uiF005374@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10919 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:09:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 11:08 ------- done. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:10:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekndf-0002mF-Cv for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:10:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17084 for ; Fri, 9 Dec 2005 14:09:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eknd2-0005RW-8r for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:10:00 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eknd0-0005QJ-L3 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:09:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EknZA-0000u4-SH for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:09:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9J5x5S005323; Fri, 9 Dec 2005 11:05:59 -0800 Date: Fri, 9 Dec 2005 11:05:59 -0800 Message-Id: <200512091905.jB9J5x5S005323@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EknZA-0000u4-SH e707b3b31a315091b4d27f8fac4c765d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512091905.jB9J5x5S005323@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10920 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:10:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:15:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eknik-0006qs-Ey for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:15:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17534 for ; Fri, 9 Dec 2005 14:14:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eknhu-0008BA-Lw for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:15:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eknhs-00082P-44 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:15:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EknhT-0006j1-BU for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:14:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9JEFZX005402; Fri, 9 Dec 2005 11:14:15 -0800 Date: Fri, 9 Dec 2005 11:14:15 -0800 Message-Id: <200512091914.jB9JEFZX005402@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EknhT-0006j1-BU 5f5e305180c58a6b68877ec307a2afd3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 204] New: DAV:creationdate vs client sychronization X-Archived-At: http://www.w3.org/mid/200512091914.jB9JEFZX005402@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10921 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:15:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=204 Summary: DAV:creationdate vs client sychronization Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-08.html#rfc.section.14.1 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org "MAY be protected. Some servers allow creationdate to be changed to reflect the time the document was created if that is more meaningful to the user (rather than the time it was uploaded). Thus, clients SHOULD NOT use this property in synchronization logic (use getetag instead)." I find this confusing. Why would the creation date ever be useful for synchronization? In general, it doesn't change ever (!) once the resource has been created. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:41:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eko7o-0006Nx-Jp for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:41:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20672 for ; Fri, 9 Dec 2005 14:40:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eko6o-0006AU-8a for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:40:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eko6f-0005rQ-8s for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:40:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eko6L-00084G-AV for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:40:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9JeDBb005425; Fri, 9 Dec 2005 11:40:13 -0800 Date: Fri, 9 Dec 2005 11:40:13 -0800 Message-Id: <200512091940.jB9JeDBb005425@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eko6L-00084G-AV fd126f0b61b06185ce7b6ecb4d85b258 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512091940.jB9JeDBb005425@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10922 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:40:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 11:40 ------- Checked, fixed, needs final review. Also made minor change to section into, referencing other places DAV:error elements are defined. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:49:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoF7-0001wX-M0 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:49:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21710 for ; Fri, 9 Dec 2005 14:48:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkoEM-0002Vd-LM for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:48:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkoEF-0002Td-6p for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:48:27 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Eko9s-0001kT-5s for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:48:25 +0000 Received: (qmail invoked by alias); 09 Dec 2005 19:37:11 -0000 Received: from p508FC1A2.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.162] by mail.gmx.net (mp029) with SMTP; 09 Dec 2005 20:37:11 +0100 X-Authenticated: #1915285 Message-ID: <4399DC7A.60209@gmx.de> Date: Fri, 09 Dec 2005 20:35:22 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) 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 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eko9s-0001kT-5s 98ceba2351579516dd1c183ea634ccf4 X-Original-To: w3c-dist-auth@w3.org Subject: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/4399DC7A.60209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10923 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:48:34 +0000 Content-Transfer-Encoding: 7bit ...as of today; as seen at . This review mainly covers minor changes compared to -08 which (hopefully) do not need a BugZilla entry. Please try to fix those before submitting a new draft. 3. Terminology Inconsistent typography (":" vs "-") "A URI mapping can be thought of as a URL pointing to a resource." I'm not sure what this is supposed to mean. Please remove it or clarify. 7.6 Write Locks and Unmapped URLs A successful lock request to an unmapped URL MUST result in the creation of an locked resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource, and the server MUST also use the content- type and content-language information from this request. Making this a MUST creates a conflict with an upcoming TAG finding by Roy Fielding. 8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and RFC2518 Properties Nits: - move it back where it was in RFC2518 - avoid the term RFC2158 properties in the title - XML in example to be fixed, for instance whitespace in D:getlastmodified - intra-doc reference to Section 13 is incorrect Obviously this has been copied verbatim from RFC2518 without any sanity checks. 8.3.1 200 (OK) - The property set or change succeeded. Note that if this appears for one property, it MUST appear for every property in the response, due to the atomicity of PROPPATCH. (2nd sentence) Again, this is correct, but a) doesn't really need to be mentioned, b) but if is mentioned, then using MUST is incorrect here. This is imply an observation based on normative text somewhere else, not a new interop requirement. 8.7 DELETE WebDAV adds some requirements to DELETE handling. Locks rooted on a resource MUST be destroyed in a successful DELETE of that resource. This is still a lame way to introduce DELETE. Please move the second sentence somewhere else, potentially a subsection (see also ). 8.9.5 Status Codes 403 (Forbidden) - The operation is forbidden. A special case for COPY could be that the source and destination resources are the same resource. Confusing. Servers may treat this as a nop, just returning 200. Just be silent about it. 8.10.4 Status Codes 204 (No Content) - The source resource was successfully moved to overwrite pre-existing destination resource. Sentence broken compared to -08. 403 (Forbidden) - In addition to general reasons for forbidding a MOVE operation, it could be that the source and destination resources are the same. And being source and destination identical would be a problem exactly why? 12.1 Response headers Use of the Location header with the Multi-Status response is intentionally undefined. The server MAY always redirect the entire request by responding with a 300 level status response instead of a Multi-Status response. This section doesn't provide any useful information. In particular, the second sentence seems to be completely out of context. 12.2 URL handling When a Multi-Status body is returned in response to a PROPFIND or another request with a single scope (no Destination header), it can contain one or more 'response' element with an 'href' element for the URL of the resource described in that 'response' element. Each of And in the other case this is not true? these response URLs MUST be equal to or inside the Request-URI. The response URLs MAY be absolute or relative references but MUST NOT include "." or ".." as path elements. URLs never are relative references. There is no such thing as an absolute reference. If a response URL is relative reference, it MUST be resolved against the Request-URI. A relative reference MUST be an absolute path (note that clients are not known to support relative paths). May I again recommend to just use the text I proposed earlier? It uses the proper terminology from RFC3986. URLs for collections appearing in the results SHOULD end in a '/' character. And the rule does not apply if it's not a URL, such as a relative reference? If a server allows resource names to include characters that aren't legal in HTTP URL paths, these characters must be URI-escaped on the Again, terminology. It's called "Percent-Encoding", and we should refer to the exact section in RFC3986. wire. For example, it is illegal to use a space character or double- quote in a URI. URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters. 12.3 Handling redirected child resources Redirect responses (300-303, 305 and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in RFC2518 did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 13.9). Servers MAY use this new element or MAY stick with the original syntax. Sounds like "We don't care what servers do". 19.7 Risks Connected with Lock Tokens This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens Section 6.3, in order to guarantee their uniqueness across space and time. The security considerations for UUIDs do not apply because WebDAV does not assume that lock tokens are supposed to be hard to ... Wow! They don't apply? Why can't we just stick with what RFC2518 said, just updating what needs to be updated, and leaving the rest alone? Proposed text: This specification, in Section 6.3, encourages the use of Universal Unique Identifiers (UUIDs) in lock tokens, in order to guarantee their uniqueness across space and time. Version 1 UUIDs, as defined in Section 4 of [RFC4122], may contain a "node" field which "consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE 802 addresses, any available one can be used". Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address. There are several risks associated with exposure of IEEE 802 addresses. Using the IEEE 802 address: o It is possible to track the movement of hardware from subnet to subnet. o It may be possible to identify the manufacturer of the hardware running a WebDAV server. o It may be possible to determine the number of each type of computer running WebDAV. This risk only applies to host address based UUID versions. Section 4 of [RFC4122] describes several other mechanisms for generating UUIDs that do involve the host address and therefore do not suffer from this risk. 22.1 Normative References [2518] still appears under "normative". Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:49:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoFW-00029Q-Sg for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:49:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21849 for ; Fri, 9 Dec 2005 14:48:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkoEy-0002jO-Ip for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:49:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkoEw-0002hY-3c for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:49:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkoEY-0007Pr-NW for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:49:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9Jmk5B005459; Fri, 9 Dec 2005 11:48:46 -0800 Date: Fri, 9 Dec 2005 11:48:46 -0800 Message-Id: <200512091948.jB9Jmk5B005459@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkoEY-0007Pr-NW ea3c98a0bd78ededcfbf63593af85a9d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 16] Trailing slash required in collection names? X-Archived-At: http://www.w3.org/mid/200512091948.jB9Jmk5B005459@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10924 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:49:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 11:48 ------- in latest draft. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:49:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoFj-0002Vf-FU for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:49:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21857 for ; Fri, 9 Dec 2005 14:49:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkoFB-0002pg-Bm for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:49:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkoF9-0002oq-KE for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:49:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkoEq-0002if-Iv for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:49:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9JmkP5005469; Fri, 9 Dec 2005 11:48:46 -0800 Date: Fri, 9 Dec 2005 11:48:46 -0800 Message-Id: <200512091948.jB9JmkP5005469@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkoEq-0002if-Iv eabf3c7864d2c715a059a1a227317949 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 156] HOW_ARE_TRAILING_SLASHES_USED X-Archived-At: http://www.w3.org/mid/200512091948.jB9JmkP5005469@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10925 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:49:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=156 Bug 156 depends on bug 16, which changed state. Bug 16 Summary: Trailing slash required in collection names? http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=16 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 14:58:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoNi-0004oH-VH for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 14:58:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22698 for ; Fri, 9 Dec 2005 14:57:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkoMu-0005bW-Uu for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 19:57:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkoMs-0005ai-EQ for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 19:57:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkoJq-0006P2-1K for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 19:57:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9JsCGR005497; Fri, 9 Dec 2005 11:54:12 -0800 Date: Fri, 9 Dec 2005 11:54:12 -0800 Message-Id: <200512091954.jB9JsCGR005497@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkoJq-0006P2-1K 8b7265630bab558a81c4399d14aa8615 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 26] URL syntax in PROPFIND X-Archived-At: http://www.w3.org/mid/200512091954.jB9JsCGR005497@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10926 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 19:57:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 11:54 ------- text no longer appears in current draft, so this is a non-issue. please reopen or submit new bug report if similar issue comes up again... ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 15:09:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkoYj-0008Qo-2t for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 15:09:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23985 for ; Fri, 9 Dec 2005 15:08:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkoXq-0001wk-S0 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 20:08:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkoXm-0001vt-3L for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 20:08:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkoXf-0007PC-A1 for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 20:08:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9K8Usl005531; Fri, 9 Dec 2005 12:08:30 -0800 Date: Fri, 9 Dec 2005 12:08:30 -0800 Message-Id: <200512092008.jB9K8Usl005531@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkoXf-0007PC-A1 2897c61b9c18dd4171b52620b1ba6655 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200512092008.jB9K8Usl005531@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10927 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 20:08:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-09 12:08 ------- updated text to appear in -09 draft. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 16:20:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekpf3-000594-GB for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 16:20:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06743 for ; Fri, 9 Dec 2005 16:19:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekpde-0005UA-0D for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 21:18:46 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkpdT-0005SC-DN for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 21:18:35 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekpbs-0002V3-R4 for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 21:18:34 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jB9LGS4j007931; Fri, 9 Dec 2005 13:16:32 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 482914AE; Fri, 9 Dec 2005 13:16:28 -0800 (PST) In-Reply-To: <43995379.8050501@gmx.de> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> <43989C90.6070103@gmx.de> <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> <43995379.8050501@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net> Cc: Jim Whitehead , Lisa Dusseault , WebDAV Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Fri, 9 Dec 2005 13:16:27 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekpbs-0002V3-R4 bd34c40ab0c7f1d3eac529484e9433ca X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10928 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 21:18:46 +0000 Content-Transfer-Encoding: quoted-printable Right. I'd change it so that instead of using a weak etag, append =20= the string "-potentially-spaztic" or something to the ETag during the =20= first second and use the same ETag without the prefix after the first =20= second. Same result as the current implementation, but without =20 implying the semantics of a weak ETag. -wsv On Dec 9, 2005, at 1:50 AM, Julian Reschke wrote: > > Wilfredo S=E1nchez Vega wrote: >> On Dec 8, 2005, at 12:50 PM, Julian Reschke wrote: >>> But with the current algorithm, the server can't return a strong =20 >>> ETag, unless it blocks updates of that content for one second. =20 >>> That may be unacceptable for some resources. >> Why couldn't it? Just append a suffix or prefix? What HTTPd does > > But where would it get the suffix from? If it had any way to store =20 > it, we wouldn't have the problem in the first place... > >> right now is use the same ETag string but prefixes it with 'W/' to =20= >> make it weak. This accomplishes the goal of making the first-=20 >> second etag different, but I think it should do that without =20 >> making the tag weak, which implies something that isn't the case. > > It also accomplishes that clients will not be "forced" to sync =20 > multiple times within a second. > > Consider a resource that changes 10 times per second, then is =20 > stable. A hypothetical client that does conditional GET requests =20 > will get an arbitrary version of the resource from within the first =20= > second, and then later the stable one. Seems to me that this is a =20 > good trade-off somehow. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 16:35:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkptO-00055Q-FB for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 16:35:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12835 for ; Fri, 9 Dec 2005 16:34:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekpsi-0003NH-HV for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 21:34:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekpsg-0003MB-SD for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 21:34:19 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EkpsO-0002a7-1Y for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 21:34:17 +0000 Received: (qmail invoked by alias); 09 Dec 2005 21:33:48 -0000 Received: from p508FC1A2.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.162] by mail.gmx.net (mp010) with SMTP; 09 Dec 2005 22:33:48 +0100 X-Authenticated: #1915285 Message-ID: <4399F7C6.2020700@gmx.de> Date: Fri, 09 Dec 2005 22:31:50 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Jim Whitehead , Lisa Dusseault , WebDAV References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> <43989C90.6070103@gmx.de> <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> <43995379.8050501@gmx.de> <62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net> In-Reply-To: <62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkpsO-0002a7-1Y 0f40b70a35d8408105188f4b9d1565f5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/4399F7C6.2020700@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10929 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 21:34:20 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA12835 Wilfredo S=E1nchez Vega wrote: > Right. I'd change it so that instead of using a weak etag, append th= e=20 > string "-potentially-spaztic" or something to the ETag during the first= =20 > second and use the same ETag without the prefix after the first second.= =20 > Same result as the current implementation, but without implying the=20 > semantics of a weak ETag. Hm, no. A strong ETag allows you to do GET with Range headers, while a weak ETag=20 doesn't. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 09 16:42:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekq0v-0001eu-AW for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 16:42:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15218 for ; Fri, 9 Dec 2005 16:41:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekq0H-0007aV-4A for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 21:42:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekq05-0007Xs-UD for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 21:41:58 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekpzw-0005hM-G7 for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 21:41:57 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jB9LfIQi011851; Fri, 9 Dec 2005 13:41:18 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id C99514B8; Fri, 9 Dec 2005 13:41:18 -0800 (PST) In-Reply-To: <4399F7C6.2020700@gmx.de> References: <438CC421.3020600@gmx.de> <44f343732127f2b6a16a63e407637eae@osafoundation.org> <65AD336B-2D70-41C8-ABA0-BF20D4EBD19A@cs.ucsc.edu> <91C56E5D-CE4D-4B38-AE79-763347703920@wsanchez.net> <43982EE8.1060103@gmx.de> <9145C457-26D2-4331-AE44-277ABB4C9BB0@wsanchez.net> <43989C90.6070103@gmx.de> <78B9630F-1BD1-4301-B50B-2CA249CFCD90@wsanchez.net> <43995379.8050501@gmx.de> <62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net> <4399F7C6.2020700@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A5692B0-16F3-493A-9892-7E7937B65F24@wsanchez.net> Cc: Jim Whitehead , Lisa Dusseault , WebDAV Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Fri, 9 Dec 2005 13:41:18 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (maggie.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekpzw-0005hM-G7 c47a9828e491d0fee6f8edd5dc789fc3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Fwd: Re: PUT vs strong ETags] X-Archived-At: http://www.w3.org/mid/3A5692B0-16F3-493A-9892-7E7937B65F24@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10930 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 21:42:09 +0000 Content-Transfer-Encoding: 7bit Ah, that's what I was looking for. Thanks. -wsv On Dec 9, 2005, at 1:31 PM, Julian Reschke wrote: > A strong ETag allows you to do GET with Range headers, while a weak > ETag doesn't. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 17:49:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekr3R-0007pw-4K for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 17:49:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22985 for ; Fri, 9 Dec 2005 17:48:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekr20-0004nK-BC for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 22:48:00 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekr1r-0004kk-DJ for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 22:47:51 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekr0D-0000PQ-7w for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 22:47:50 +0000 Received: from [128.114.60.145] (dhcp-60-145.cse.ucsc.edu [128.114.60.145]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jB9Mk2PV026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Dec 2005 14:46:03 -0800 (PST) Message-ID: <439A092F.6090806@cse.ucsc.edu> Date: Fri, 09 Dec 2005 14:46:07 -0800 From: Elias Sinderson Reply-To: WebDAV User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV CC: Julian Reschke References: <4399DC7A.60209@gmx.de> In-Reply-To: <4399DC7A.60209@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekr0D-0000PQ-7w 2475bf7a36aafab6274a6c892200e2d6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/439A092F.6090806@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10931 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 22:48:00 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > 3. Terminology > Inconsistent typography (":" vs "-") Fixed. > "A URI mapping can be thought of as a URL pointing to a resource." > I'm not sure what this is supposed to mean. Please remove it or clarify. Removed. > 7.6 Write Locks and Unmapped URLs > > A successful lock request to an unmapped URL MUST result in the > creation of an locked resource with empty content. Subsequently, a > successful PUT request (with the correct lock token) provides the > content for the resource, and the server MUST also use the content- > type and content-language information from this request. > > Making this a MUST creates a conflict with an upcoming TAG finding by > Roy Fielding. Discussion needed; created new bugzilla issue. > 8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and > RFC2518 Properties > > Nits: > - move it back where it was in RFC2518 > - avoid the term RFC2158 properties in the title Renamed; brief explanatory note added. > - XML in example to be fixed, for instance whitespace in > D:getlastmodified Fixed the example. However, since DAV:get* properties are based upon definitions made in rfc2616, LWS may be found in some implementations -- explanatory text added to section 14. > - intra-doc reference to Section 13 is incorrect Fixed. > 8.3.1 [...] (2nd sentence) Again, this is correct, but > a) doesn't really need to be mentioned, > b) but if is mentioned, then using MUST is incorrect here. [...] 2nd sentence left in, with MUST removed. > 8.7 DELETE [...] This is still a lame way to introduce DELETE. [...] > 8.9.5 Status Codes [...] 403 (Forbidden) [...] Confusing. Servers may > treat this as a nop, just returning 200. Just be silent about it. Discussed this but left the text in, as the semantics were defined in 2518 (see similar comment below). > 8.10.4 Status Codes > 204 (No Content) - [...] Sentence broken [...] Rewrote text to clarify 204 and 201. > 403 (Forbidden) [...] And being source and destination identical > would be a problem exactly why? Semantics defined in 2518, left alone as a change could compromise resource identity (e.g. creation date may change, corruption of version history, etc.). > 12.1 Response headers [...] This section doesn't provide any useful > information. In particular, the second sentence seems to be completely > out of context. Rewrote this section (originally added following discussion of issue 47). Second sentence has been removed. > 12.2 URL handling [...] Rewrote most of this section, incorporating some of your proposed text, and paying attention to RFC3986 language -- please review. > 12.3 Handling redirected child resources [...] Sounds like "We don't > care what servers do". After some discussion, we now care and have rewritten the last sentence. > 19.7 Risks Connected with Lock Tokens [...] Proposed text inserted with a couple of tweaks (title of RFC, version / variant language, and minor wordsmithing introducing the list). > 22.1 Normative References [...] Reference to 2518 moved to informative references. Cheers, Elias From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:19:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkrWp-0002p0-7S for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:19:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25935 for ; Fri, 9 Dec 2005 18:18:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkrVy-0004uK-Nn for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:18:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkrVk-0004md-WB for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:18:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkrVN-0001yL-OV for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:18:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NHxv5005767; Fri, 9 Dec 2005 15:17:59 -0800 Date: Fri, 9 Dec 2005 15:17:59 -0800 Message-Id: <200512092317.jB9NHxv5005767@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkrVN-0001yL-OV 78635df652811b7866bbc93e8ae959e5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 32] DAV:displayname handling X-Archived-At: http://www.w3.org/mid/200512092317.jB9NHxv5005767@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10932 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:18:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=32 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:17 ------- All discussion of remote COPY/MOVE have been removed from the specification. Since this report was entered, the specification text has changed. There is now a heading for each property defining whether it is protected. The protected status of this property is now "SHOULD NOT be protected." Two thoughts here. One is to describe the current state of the world (mixed -- some servers allow writing to displayname, some servers do not), inwhich case this is "Possibly" protected. The other thought is to move implementations in the direction of the originally desired semantics, which is that clients can reliably write the value of this property. The current text is of this camp, moving servers towards allowing this property to be written. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:32:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekriw-00068J-FW for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:32:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26902 for ; Fri, 9 Dec 2005 18:31:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkriE-0002Zb-W4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:31:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekri4-0002X3-Vu for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:31:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkrhU-0002z9-HY for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:31:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NUnBE005791; Fri, 9 Dec 2005 15:30:49 -0800 Date: Fri, 9 Dec 2005 15:30:49 -0800 Message-Id: <200512092330.jB9NUnBE005791@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkrhU-0002z9-HY c33fb635a128e82a098a52cb6d89ee48 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200512092330.jB9NUnBE005791@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10933 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:31:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:30 ------- The specification has been changed to make use of application/xml a SHOULD, and all examples have been modified to use application/xml (using the STRONGLY RECOMMENDED charset parameter, of course). Applications are required to accept both text/xml and application/xml. Use of text/xml is explicitly deprecated. Moved the requirement for use of application/xml to the XML Usage section. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:35:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkrmM-00074G-5g for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:35:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27262 for ; Fri, 9 Dec 2005 18:34:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkrlX-0004Xq-W2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:35:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkrlW-00046A-7r for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:35:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekrl2-0006kD-Gs for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:35:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NYVe1005823; Fri, 9 Dec 2005 15:34:31 -0800 Date: Fri, 9 Dec 2005 15:34:31 -0800 Message-Id: <200512092334.jB9NYVe1005823@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekrl2-0006kD-Gs 33e9e12b7f5183fa3c8551711dbc24fc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512092334.jB9NYVe1005823@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10934 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:35:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:34 ------- Jim and Lisa believe this to be fixed. Several of these issues were raised in Julian's email: http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1074.html Replies to Julian in: http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1082.html ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:37:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekrnz-0007o2-5P for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:37:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27665 for ; Fri, 9 Dec 2005 18:36:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkrnF-0005Mq-UQ for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:36:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkrnD-0005Lm-6s for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:36:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekrn5-0007oX-UL for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:36:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9Nadml005845; Fri, 9 Dec 2005 15:36:39 -0800 Date: Fri, 9 Dec 2005 15:36:39 -0800 Message-Id: <200512092336.jB9Nadml005845@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekrn5-0007oX-UL 084e9c1d28b5583239c2e9e1feb7967c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512092336.jB9Nadml005845@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10935 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:36:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:36 ------- Julian is requested to review the latest text on this issue, and see if all issues have been resolved. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:39:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkrpM-0008RD-3o for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:39:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27758 for ; Fri, 9 Dec 2005 18:38:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekroi-0005gf-A8 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:38:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekrog-0005fw-Nq for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:38:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekrns-0005nj-NS for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:38:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NbSJ9005872; Fri, 9 Dec 2005 15:37:28 -0800 Date: Fri, 9 Dec 2005 15:37:28 -0800 Message-Id: <200512092337.jB9NbSJ9005872@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekrns-0005nj-NS 3b7daff63c7f4dc4d5ee39cabfabf12e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200512092337.jB9NbSJ9005872@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10936 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:38:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |ejw@cs.ucsc.edu Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:39:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekrpo-0008T3-NX for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:39:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27780 for ; Fri, 9 Dec 2005 18:38:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekrp8-0005pA-IP for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:38:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekrp7-0005oQ-10 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:38:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekroy-0000FA-Ul for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:38:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NcaMI005892; Fri, 9 Dec 2005 15:38:36 -0800 Date: Fri, 9 Dec 2005 15:38:36 -0800 Message-Id: <200512092338.jB9NcaMI005892@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekroy-0000FA-Ul fbb74350b9c730bfd10638cec3fafbfa X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512092338.jB9NcaMI005892@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10937 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:38:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:38 ------- Are waiting on comments from Julian on this issue. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:40:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekrqx-0000Sm-RP for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:40:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27891 for ; Fri, 9 Dec 2005 18:39:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkrqG-00069X-0k for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:39:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkrqE-00068d-97 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:39:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkrpP-0006We-Vj for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:39:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9Nd3gn005908; Fri, 9 Dec 2005 15:39:03 -0800 Date: Fri, 9 Dec 2005 15:39:03 -0800 Message-Id: <200512092339.jB9Nd3gn005908@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkrpP-0006We-Vj e0de3c0b39cb03029c6de0eb16e0eaca X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 51] Property behaviour upon COPY vs "remote COPY" X-Archived-At: http://www.w3.org/mid/200512092339.jB9Nd3gn005908@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10938 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:39:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=51 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-09 15:39 ------- Next version won't discuss remote COPY or MOVE except extremely briefly in noting what to do with a remote Destination URL if the server can't handle it. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekrr0-0000Sv-6R for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27894 for ; Fri, 9 Dec 2005 18:39:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkrqL-0006E6-B9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:40:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkrqI-00069s-Nv for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:39:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekrq2-0002xa-GN for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:39:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NdRtC005920; Fri, 9 Dec 2005 15:39:27 -0800 Date: Fri, 9 Dec 2005 15:39:27 -0800 Message-Id: <200512092339.jB9NdRtC005920@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekrq2-0002xa-GN f64dc191ddb38c2e15db224b9f37d70d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512092339.jB9NdRtC005920@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10939 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:40:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:39 ------- Are waiting on feedback from Julian on this issue. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:57:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eks7Q-00059U-EV for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:57:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00486 for ; Fri, 9 Dec 2005 18:56:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eks6U-000517-4U for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:56:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eks6J-0004y5-GV for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:56:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eks6B-0008OG-JF for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:56:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NuNGL005947; Fri, 9 Dec 2005 15:56:23 -0800 Date: Fri, 9 Dec 2005 15:56:23 -0800 Message-Id: <200512092356.jB9NuNGL005947@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eks6B-0008OG-JF 3cd4d580fe924a6a0c27d74687d0b447 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512092356.jB9NuNGL005947@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10940 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:56:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ------- Additional Comments From lisa@osafoundation.org 2005-12-09 15:56 ------- Added the phrase "if not recognized" which is similar to other text sections ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 18:57:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eks7R-00059i-28 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:57:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00487 for ; Fri, 9 Dec 2005 18:56:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eks6c-00052y-Dh for w3c-dist-auth-dist@listhub.w3.org; Fri, 09 Dec 2005 23:56:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eks6J-0004yV-Q1 for w3c-dist-auth@listhub.w3.org; Fri, 09 Dec 2005 23:56:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eks6C-0008OZ-SW for w3c-dist-auth@w3.org; Fri, 09 Dec 2005 23:56:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jB9NuOQb005966; Fri, 9 Dec 2005 15:56:24 -0800 Date: Fri, 9 Dec 2005 15:56:24 -0800 Message-Id: <200512092356.jB9NuOQb005966@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eks6C-0008OZ-SW c382f5e7bd5c0f95f7cf9b0f7e27ae77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] "mandatory" properties X-Archived-At: http://www.w3.org/mid/200512092356.jB9NuOQb005966@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10941 X-Loop: w3c-dist-auth@w3.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, 09 Dec 2005 23:56:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 15:56 ------- It's unclear what the correct semantics are here. The latest draft takes a whack at this in the definition of creationdate -- feedback is most welcome. The general idea is that servers that cannot persistently store creationdate should just not report this property at all (i.e., report it "Not Found"). Some other possibilities are: * report an empty XML element (fear that clients won't handle this well) * use an arbitrary time in the past (magic number, such as January 1, 1900) as a convention * report the current time The last two are perceived to likely work well with clients that, despite the warnings in the specification, still try to use creationdate for synchronization. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:08:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksHd-0000qa-J7 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:08:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04074 for ; Fri, 9 Dec 2005 19:07:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksH3-0001a4-Eq for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:07:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EksH1-0001Z2-R4 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:07:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EksGv-0005Zt-0R for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:07:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA07RjI006031; Fri, 9 Dec 2005 16:07:27 -0800 Date: Fri, 9 Dec 2005 16:07:27 -0800 Message-Id: <200512100007.jBA07RjI006031@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EksGv-0005Zt-0R f7f1ea04b6362d78446331ce86f9c119 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512100007.jBA07RjI006031@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10943 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:07:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:18:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksR8-0004RF-C5 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:18:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07028 for ; Fri, 9 Dec 2005 19:16:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksQK-0005uq-TZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:17:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EksQI-0005tk-AN for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:17:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EksQ9-0002UG-I5 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:17:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0Gqir006057; Fri, 9 Dec 2005 16:16:52 -0800 Date: Fri, 9 Dec 2005 16:16:52 -0800 Message-Id: <200512100016.jBA0Gqir006057@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EksQ9-0002UG-I5 1b7c8e6e09f04175d9c10def47a0887e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 58] MOVE status 403 description X-Archived-At: http://www.w3.org/mid/200512100016.jBA0Gqir006057@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10944 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:17:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=58 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:16 ------- The specification text now reads that "Among many possible reasons for forbidding a MOVE operation, this status code is recommended for use when the source and destination resources are the same." This only addresses the specific concern with MOVE. In an ideal world where the WG wasn't being threatened with imminent closure, it would be best to define precondition and postcondition codes for all possible error conditions possible. Jim and Lisa believe the consensus from a recent teleconference was *not* to do this in bis, at this time. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:24:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksX3-00072F-KF for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:24:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09208 for ; Fri, 9 Dec 2005 19:23:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksWD-0008Bp-09 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:23:17 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EksW8-00089v-Ts for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:23:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EksVi-0000Xe-6j for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:23:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0MiEV006095; Fri, 9 Dec 2005 16:22:44 -0800 Date: Fri, 9 Dec 2005 16:22:44 -0800 Message-Id: <200512100022.jBA0MiEV006095@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EksVi-0000Xe-6j 1d733190c0b9d06909849017d7390a84 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512100022.jBA0MiEV006095@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10945 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:23:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 Bug 18 depends on bug 60, which changed state. Bug 60 Summary: If header evaluation when? http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:24:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksX4-00072b-SP for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:24:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09217 for ; Fri, 9 Dec 2005 19:23:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksWM-0008E5-12 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:23:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EksWC-0008Ao-4D for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:23:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EksVi-0000XQ-4J for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:23:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0Miqs006081; Fri, 9 Dec 2005 16:22:44 -0800 Date: Fri, 9 Dec 2005 16:22:44 -0800 Message-Id: <200512100022.jBA0Miqs006081@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EksVi-0000XQ-4J 18ba55fd6cdbc91e4ac4b51f9174bbe4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] If header evaluation when? X-Archived-At: http://www.w3.org/mid/200512100022.jBA0Miqs006081@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10946 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:23:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-09 16:22 ------- Jim and I tried to clarify the paragraph as a whole. suggested: Note that use of Lock-Token header to provide the lock token is not consistent with other state-changing methods which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally when the If header is present it has its normal meaning as a conditional header. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:31:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eksdz-0001I5-7O for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:31:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11644 for ; Fri, 9 Dec 2005 19:30:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eksd8-0006DE-28 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:30:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eksd6-0006AT-EF for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:30:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekscx-0007Gf-S8 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:30:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0UBi1006118; Fri, 9 Dec 2005 16:30:11 -0800 Date: Fri, 9 Dec 2005 16:30:11 -0800 Message-Id: <200512100030.jBA0UBi1006118@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekscx-0007Gf-S8 ad7897d6ae5ebe1bf13bab6200d6d1ba X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200512100030.jBA0UBi1006118@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10947 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:30:26 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-09 16:30 ------- Jim & I worked on this and suggest: Purpose: Identifies the content of the element as a URI or a relative reference. There may be limits on the value of 'href' depending on the context of its use. Refer to the specification text where 'href' is used to see what limitations apply in each case. Value: URI (See section 3 of [RFC3986]) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:32:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksHM-0000mB-1g for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:07:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03968 for ; Fri, 9 Dec 2005 19:06:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksGZ-0001Pi-3u for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:07:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EksGX-0001OV-Bg for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:07:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EksGO-0005LW-7f for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:07:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA06tKN006010; Fri, 9 Dec 2005 16:06:55 -0800 Date: Fri, 9 Dec 2005 16:06:55 -0800 Message-Id: <200512100006.jBA06tKN006010@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EksGO-0005LW-7f 41745700e952380345e010762787462d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512100006.jBA06tKN006010@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10942 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:07:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:06 ------- Copied over two paragraphs from RFC 3253 into Section 1.6 (Precondition/Postcondition XML elements). This has the effect of allowing the desired extensibility of responsedescription. Also changed the use of the error reporting XML elements to MUST from RECOMMENDED, since servers will be explicitly reporting the "bis" compliance level in the DAV header. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:36:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksjJ-0003hj-Jz for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:36:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13571 for ; Fri, 9 Dec 2005 19:35:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EksiY-0000OA-1b for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:36:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EksiU-0000MU-Bz for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:35:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EksiL-00010k-ON for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:35:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0Zmdo006141; Fri, 9 Dec 2005 16:35:48 -0800 Date: Fri, 9 Dec 2005 16:35:48 -0800 Message-Id: <200512100035.jBA0Zmdo006141@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EksiL-00010k-ON a1d1afac55edbdef762b43afacbf9d33 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 204] DAV:creationdate vs client sychronization X-Archived-At: http://www.w3.org/mid/200512100035.jBA0Zmdo006141@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10948 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:36:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=204 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:35 ------- One possible scenario for performing synchronization would be for a client to perform a search looking for all resources with more recent creationdate times than the last time the client had performed the search. This would allow the client to discover all new resources since the last synch time. They would, of course, have to perform a separate request looking for those resources that they already knew about that had changed since the last synch. This has the benefit of allowing lazy update of already known resources, since a local list of known resources could be kept up to date, while the actual contents of known resources would only be updated as needed. So, the previous scenario shows that there is a non-braindead synch scenario that might consider using creationdate as part of its synch strategy. As a result, adding some text into the specification noting that this is a bad idea seems useful. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:39:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekslr-0004Yb-59 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:39:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14204 for ; Fri, 9 Dec 2005 19:38:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eksl9-0001JT-7H for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:38:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eksl5-0001IJ-Re for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:38:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekskz-0001SC-09 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:38:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0cWfZ006166; Fri, 9 Dec 2005 16:38:32 -0800 Date: Fri, 9 Dec 2005 16:38:32 -0800 Message-Id: <200512100038.jBA0cWfZ006166@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekskz-0001SC-09 8d3373c28813f304abd46a4262dd8b58 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 201] LWS allowed in Coded-URL X-Archived-At: http://www.w3.org/mid/200512100038.jBA0cWfZ006166@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10949 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:38:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:38 ------- This has been addressed in two places: The definition of coded-URL (section 9.1) The timetype ABNF definition (section 9.8) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:54:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekt0e-0001Mu-PG for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:54:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17070 for ; Fri, 9 Dec 2005 19:53:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekszo-00075T-SN for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:53:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekszn-00074n-Fp for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:53:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekszf-0000IY-8Q for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:53:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0rgfb006193; Fri, 9 Dec 2005 16:53:42 -0800 Date: Fri, 9 Dec 2005 16:53:42 -0800 Message-Id: <200512100053.jBA0rgfb006193@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekszf-0000IY-8Q bc3e41b7342b733797cad127109858cd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 203] DAV:lockdiscovery in multistatus (8.11.8) X-Archived-At: http://www.w3.org/mid/200512100053.jBA0rgfb006193@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10950 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:53:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=203 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:53 ------- Good catch. Entered suggested specification text in section "Depth and Locking" to the effect of: * Reporting of lockdiscovery is not needed (we're actually silent on this -- no requirement exists to report this) * Servers MUST report at least one URL that caused the problem, and then report the request URI with a status of 424 Failed Dependency. The example was updated to reflect these new semantics. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:57:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekt2s-00024s-VB for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:57:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17475 for ; Fri, 9 Dec 2005 19:56:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekt2B-0008DW-9y for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:56:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekt27-0008Cj-W9 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:56:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekt1K-00068h-F8 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:56:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0tQaF006221; Fri, 9 Dec 2005 16:55:26 -0800 Date: Fri, 9 Dec 2005 16:55:26 -0800 Message-Id: <200512100055.jBA0tQaF006221@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekt1K-00068h-F8 05ee89c3041b1100f46bb7f0e507367a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512100055.jBA0tQaF006221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10951 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:56:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:58:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekt41-0002QD-PG for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:58:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17631 for ; Fri, 9 Dec 2005 19:57:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekt39-0008UO-5x for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:57:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekt37-0008TP-EV for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:57:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekt2y-0001yI-Iy for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:57:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0v8M3006247; Fri, 9 Dec 2005 16:57:08 -0800 Date: Fri, 9 Dec 2005 16:57:08 -0800 Message-Id: <200512100057.jBA0v8M3006247@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekt2y-0001yI-Iy de205708473b34ff80cb24998a546fc7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512100057.jBA0v8M3006247@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10952 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:57:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 16:57 ------- Jim and Lisa disagree. There are many minor differences in semantics between 2518 and 2518-bis (for example, error handling). It seems clear we're going to recycle at proposed, and so it is important that client (implementors) can discover which version of the specification is supported. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 19:59:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekt5I-0002fk-Ua for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:59:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17821 for ; Fri, 9 Dec 2005 19:58:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekt4b-0000Xd-JF for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 00:58:49 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekt4Y-0000WW-M6 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 00:58:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekt4O-0002o3-6Z for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 00:58:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA0wOAN006274; Fri, 9 Dec 2005 16:58:24 -0800 Date: Fri, 9 Dec 2005 16:58:24 -0800 Message-Id: <200512100058.jBA0wOAN006274@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekt4O-0002o3-6Z 1dd3294c0d0115f26a3b7048a6d4aa26 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512100058.jBA0wOAN006274@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10953 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 00:58:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:02:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekt8L-0004TE-0t for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:02:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18243 for ; Fri, 9 Dec 2005 20:01:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekt7c-00039V-IH for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:01:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekt7a-00038R-78 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:01:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekt7S-00046B-Ev for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:01:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA11jNg006309; Fri, 9 Dec 2005 17:01:45 -0800 Date: Fri, 9 Dec 2005 17:01:45 -0800 Message-Id: <200512100101.jBA11jNg006309@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekt7S-00046B-Ev d7bb3f42f3a42d80224a649d5c74c307 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 199] Front matter editorial nits X-Archived-At: http://www.w3.org/mid/200512100101.jBA11jNg006309@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10954 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:01:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=199 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:01 ------- Accepted both suggested changes. Were not able to find the location of "this draft". ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:06:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktBw-0007tJ-Aj for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:06:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18697 for ; Fri, 9 Dec 2005 20:05:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktBD-0004zs-Ba for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:05:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EktBB-0004yq-ML for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:05:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EktB2-0005Y0-QH for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:05:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA15QNU006329; Fri, 9 Dec 2005 17:05:26 -0800 Date: Fri, 9 Dec 2005 17:05:26 -0800 Message-Id: <200512100105.jBA15QNU006329@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EktB2-0005Y0-QH a24748423c9218712d361c7c7956cd78 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 189] "RFC2518bis" in spec text X-Archived-At: http://www.w3.org/mid/200512100105.jBA15QNU006329@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10955 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:05:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=189 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:05 ------- Performed an additional search through the document, on keyword 'bis', and did not find any additional uses of "RFC2518bis" in the text. Additionally, changed most uses of "RFC2518" in the text to be 'xrefs' (citations) instead of stating "RFC2518". Julian is encouraged to double-check this change in the latest draft. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:20:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktPC-0005y2-Sq for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:20:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20372 for ; Fri, 9 Dec 2005 20:19:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktOL-0003mo-OP for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:19:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktOE-0003k4-9k for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:19:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktNl-0002xH-QT for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:19:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1Iak4006359; Fri, 9 Dec 2005 17:18:36 -0800 Date: Fri, 9 Dec 2005 17:18:36 -0800 Message-Id: <200512100118.jBA1Iak4006359@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktNl-0002xH-QT 88adbd6013813eb0922e33b208457be8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200512100118.jBA1Iak4006359@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10956 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:19:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-12-09 17:18 ------- The 'opaquelocktoken' URI scheme was defined in RFC2518 (and registered by IANA) in order to create syntactically correct and easy-to-generate URIs out of UUIDs, intended to be used as lock tokens and to be unique across all resources for all time. An opaquelocktoken URI is constructed by concatenating the 'opaquelocktoken' scheme with a UUID, along with an optional extension. Servers can create new UUIDs for each new lock token. If a server wishes to reuse UUIDs the server MUST add an extension and the algorithm generating the extension MUST guarantee that the same extension will never be used twice with the associated UUID. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:21:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktQR-0006TX-9q for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:21:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20514 for ; Fri, 9 Dec 2005 20:20:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktPf-0004pB-PF for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:20:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktPe-0004oV-Co for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:20:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktPB-0003iB-OT for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:20:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1K4gn006384; Fri, 9 Dec 2005 17:20:04 -0800 Date: Fri, 9 Dec 2005 17:20:04 -0800 Message-Id: <200512100120.jBA1K4gn006384@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktPB-0003iB-OT 36378891b2bc01faebd0509782fd1616 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 186] opaquelocktoken appendix X-Archived-At: http://www.w3.org/mid/200512100120.jBA1K4gn006384@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10957 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:20:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=186 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:23:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktSU-00072u-LB for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:23:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20770 for ; Fri, 9 Dec 2005 20:22:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktRi-0005MD-OQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:22:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktRh-0005LP-2w for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:22:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktQq-0004WH-NF for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:22:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1Lm8C006408; Fri, 9 Dec 2005 17:21:48 -0800 Date: Fri, 9 Dec 2005 17:21:48 -0800 Message-Id: <200512100121.jBA1Lm8C006408@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktQq-0004WH-NF f360dd8dc9c394edf8227bc2dbdb2aac X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 183] Outdated references X-Archived-At: http://www.w3.org/mid/200512100121.jBA1Lm8C006408@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10958 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:22:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=183 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:21 ------- References have been updated. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:24:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktTY-0007O5-MW for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:24:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20896 for ; Fri, 9 Dec 2005 20:23:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktSs-0005al-Ae for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:23:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktSq-0005a1-MG for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:23:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktSH-0005MW-MT for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:23:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1NHQJ006433; Fri, 9 Dec 2005 17:23:17 -0800 Date: Fri, 9 Dec 2005 17:23:17 -0800 Message-Id: <200512100123.jBA1NHQJ006433@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktSH-0005MW-MT 0882deeb1d9d1a4bb55a51b44c679143 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 87] broken XML source of spec X-Archived-At: http://www.w3.org/mid/200512100123.jBA1NHQJ006433@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10959 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:23:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=87 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:23 ------- Performed a search through the document, and did not find any current lists of type "symbol". All are "symbols" (with 's'). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:27:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktWV-0008Ib-2z for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:27:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21207 for ; Fri, 9 Dec 2005 20:26:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktVr-0006ma-DF for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:26:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EktVp-0006lo-Rd for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:26:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EktVY-0006BI-Cg for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:26:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1QYoi006464; Fri, 9 Dec 2005 17:26:34 -0800 Date: Fri, 9 Dec 2005 17:26:34 -0800 Message-Id: <200512100126.jBA1QYoi006464@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EktVY-0006BI-Cg d5bd5873df9c0b9616e9a22f1bdad9d7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 102] lock tokens in examples X-Archived-At: http://www.w3.org/mid/200512100126.jBA1QYoi006464@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10960 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:26:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:26 ------- Did a search through the document, looking for "; Fri, 9 Dec 2005 20:26:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktW1-0006tF-EA for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:27:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktVz-0006nl-Qk for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:27:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktVr-0007AW-V3 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:27:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1Qx6I006486; Fri, 9 Dec 2005 17:26:59 -0800 Date: Fri, 9 Dec 2005 17:26:59 -0800 Message-Id: <200512100126.jBA1Qx6I006486@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktVr-0007AW-V3 91259a9ed32274a190c9f3fa36d3f178 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 190] HTTP examples using RFC2629 markup X-Archived-At: http://www.w3.org/mid/200512100126.jBA1Qx6I006486@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10961 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:27:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=190 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:30:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktZ8-0001r7-IU for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:30:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21492 for ; Fri, 9 Dec 2005 20:29:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktYN-0007XP-SI for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:29:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EktYM-0007WF-7o for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:29:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EktYE-0007Pj-0l for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:29:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1TJcJ006507; Fri, 9 Dec 2005 17:29:19 -0800 Date: Fri, 9 Dec 2005 17:29:19 -0800 Message-Id: <200512100129.jBA1TJcJ006507@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EktYE-0007Pj-0l 2a320a3826e404846457bf04a7e1640b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 191] LOCK_ISSUES_ACCESS_RIGHTS X-Archived-At: http://www.w3.org/mid/200512100129.jBA1TJcJ006507@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10962 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:29:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=191 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-09 17:29 ------- We discussed this language on the list even -- it now uses 'submitted' instead of 'having' along with other changes. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:31:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EktaK-0003CU-RE for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:31:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21569 for ; Fri, 9 Dec 2005 20:30:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktZe-0001cU-LO for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:30:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EktZc-0001bP-Ul for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:30:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EktZV-0004hz-ED for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:30:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1UhRC006527; Fri, 9 Dec 2005 17:30:43 -0800 Date: Fri, 9 Dec 2005 17:30:43 -0800 Message-Id: <200512100130.jBA1UhRC006527@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EktZV-0004hz-ED 5b2ed4a49d398dfdce5eaa0dba046d71 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512100130.jBA1UhRC006527@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10963 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:30:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Round-tripping namespace |Round-tripping various |decls in properties |information in properties ------- Additional Comments From lisa@osafoundation.org 2005-12-09 17:30 ------- Updating the summary of the bug to reflect extended discussion. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:32:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ektao-0003Gm-43 for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:32:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21617 for ; Fri, 9 Dec 2005 20:31:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekta6-0001oG-E7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:31:22 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekta4-0001nF-Mg for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:31:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EktZp-0004nA-IA for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:31:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1V5Kx006547; Fri, 9 Dec 2005 17:31:05 -0800 Date: Fri, 9 Dec 2005 17:31:05 -0800 Message-Id: <200512100131.jBA1V5Kx006547@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EktZp-0004nA-IA e0ed03d4c018c9010b14766ef7ed1805 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 146] PROP_ROUNDTRIP X-Archived-At: http://www.w3.org/mid/200512100131.jBA1V5Kx006547@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10964 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:31:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=146 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |10 Status|NEW |RESOLVED Resolution| |DUPLICATE Bug 146 depends on bug 10, which changed state. Bug 10 Summary: Round-tripping various information in properties http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Status|ASSIGNED |NEW Status|NEW |ASSIGNED Status|ASSIGNED |RESOLVED Resolution| |FIXED Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:31 ------- *** This bug has been marked as a duplicate of 10 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 09 20:32:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ektb7-0003Sp-Bb for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 20:32:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21692 for ; Fri, 9 Dec 2005 20:31:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EktaY-00023l-G7 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 01:31:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EktaW-00022b-Tt for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 01:31:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EktZr-0008Sp-Gx for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 01:31:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA1V5Bh006557; Fri, 9 Dec 2005 17:31:05 -0800 Date: Fri, 9 Dec 2005 17:31:05 -0800 Message-Id: <200512100131.jBA1V5Bh006557@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EktZr-0008Sp-Gx e37ea5297a005f745f6854fe28f0a295 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512100131.jBA1V5Bh006557@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10965 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 01:31:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |146 nThis| | CC| |elias@cse.ucsc.edu ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 17:31 ------- *** Bug 146 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From ccfruxfe@hotmail.com Fri Dec 09 21:42:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekugn-0005cI-MP for webdav-archive@megatron.ietf.org; Fri, 09 Dec 2005 21:42:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29528 for ; Fri, 9 Dec 2005 21:41:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekugy-0004on-3F for webdav-archive@ietf.org; Fri, 09 Dec 2005 21:42:32 -0500 Received: from aannecy-251-1-10-151.w83-113.abo.wanadoo.fr ([83.113.40.151]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ekugd-0003Fx-D8 for webdav-archive@ietf.org; Fri, 09 Dec 2005 21:42:11 -0500 FCC: mailbox://ccfruxfe@hotmail.com/Sent X-Identity-Key: id1 Date: Sat, 10 Dec 2005 08:41:06 +0600 From: Elisabeth Shultz X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav-archive@ietf.org Subject: Re [7] Content-Type: multipart/related; boundary="------------020606060003030905010001" Message-Id: X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb This is a multi-part message in MIME format. --------------020606060003030905010001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I must go Chinesse New Year in 1858 let's keep the ball rolling!

Gundam Wing Health

--------------020606060003030905010001 Content-Type: image/gif; name="guidance.GIF" Content-ID: Content-Disposition: inline; filename="guidance.GIF" Content-Transfer-Encoding: base64 R0lGODlhOAJvAvVkAAkJAMDAwMDcwKbK8EAgAABAACBAAKBAAABgACBgACAgQEAgQOAgQABAQCBAQEBAQGBAQOBAQABgQCBgQEBgQGBgQOBgQACAQCCAQECAQGCAQICAQACgQCCgQECgQGCgQCDAQEDAQGDAQGBg gIBggOBggECAgGCAgICAgKCAgOCAgGCggICggKCggMCggOCggEDAgGDAgIDAgKDAgMDAgKDggKCgwMCg wOCgwKDAwP/78KCgpP8AAAAA/////wAAACH5BAQAAAAALAAAAAAsAmICAAb/QJ9wSCwaj8ikcslsOp/Q qHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGS k5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2gwe3YDy8vb69Rb+/Q8LFvMG+SMbIwEfF RsbHQtHU0kkH2Nna2k3b2Efe3ODh5ELkuT7hztXJ68PM1VTP0O9E7PXw7cT619v01kwATlumBJ89fksE DlzXRp9BHwj38ZCocF/BiBb/TRxYESNEgfw8FhFnLpsSkiRHmuy2kkjLdClLoruosNlBaxhD2nTicCfF /43QNAYUWdHlt1wtCdLU+PAmR2ZPE/pEKHKMzpo+7eVTNjTrNHdg4SUBSlHskpgxh7xU+81IWiRv28qU q5anV5AdseItGhZqPrLEhHYtCnicuZIc5ymbqrRvT6BVP+4FHDkMVcZ8C+cs7I6zXs+YOX81e1M0W7pz 3a5NrRJ1P9eHjb6cOZhrWcG3SzfZDFJyTdxS855tOxMdzqqXFQNvdjU45dBskj/P3Dmo3d+kl3sdrTv7 ONdoV5+mDRP2d9rFVdMlT5Ms5NzaP9deDHBjRM3bqwdjsjL95LFURXHVRAO2511lu0DXnTP6BfZEgMBl R1SEvg0H3lpvsTaeEymx1/8aOh4CWF+D8eHHF3wSJkYZhSKuyJ9JIS64X0hSFFhgiwfmZ9VO9+UnGo1Q AFmaafVM6F2FJ63WYYblrSfeeWxZ+CSOC21F33HytUekQz9pdaSBDkppnowODmiahMDceGWOJ4rxGGjU NXjmmtwN2SJkPkZYWXio+QPXkmN+KNOLgdKZVVMqolgZor6912WdiQVp05yyTRmVdWbqiGSkai7GED0N RUMng2tSWuqVW06aJ5ptatikemP66WqS6ogpYGOJogofgowWaaWJpuoW7HiBEpYbNc7d9qZUnyITKpZZ klrdsGL9SNSytg3JKKze/DmlrK+yRFyhc8Wo36HXqor/q5Z3htklsLceQ225Id61YDxUIoktgM0e9Ox0 AI8Fpjw+pgutwGYhyFqG4H6InqWVRkkoufcCm+rBmw52saN2whvvvJV62NGXKs6J67qgpuxsdKG5t+qo Uxi8MYpedrdtxE162HDIOE/sEn85P8gjU+1G2uh1mXHJlMeStvraWoThS2JXSzGrsr8sT+ZynDDXqKPB ZNZ8LIIoxfUtht/2nM5ZxCItNs27qut0xil2xrR1LHIYbpVhslP1bgXP/Yd0WxM5cMxfB144wjLevHfQ gnpLHsMPx+qW2od33TiPvCr+dtgeRS342nWV9zmeyF7ktuaIEB42pHmvni+ZoU+9/yfasJl9oXlOWv4z z/Mlq6eCwdP+N9wfsX7N70mhbLRkzSZ9pqYZrWy9GmayaDL1mffllPa2R8Zn7uTrLF6fT653nrnPB+d9 +0cDDifenn4pPbVygTiTqPneRzPY8gvY68rwJmvVh1IKUx5pAMi3I20rLTvbG+V2FznZGGV97EvgvkCn sA26q1/wg54Cv3OYlaRuVMJwV6dI1jXppOEeGtue81DlOOXcCU7KSWHIwNUtbpXvHOIAYg97SC/YnNA5 6GqMDmNoMa7dI4k2fFrz+NfCJVaPgZICYQN1wcUuPoJ9XgyjGMdIxjKa8YxoTKMa18jGNrrxjXCMoxzn SMc62v/xjnjMox73yMc++vGPgAykIAdJyEIa8pCITKQiF8nIRjrykZCMpCQnSclKWvKSmMykJjfJyU56 8pOgDKUoR0nKUppSkzrAgQ5OycpEqkAYFlCBKltJyz6+IAIMMEYESoCDWvqSjzp4gQoi8AsVrPKXyMwj DlSQS15EoJfJjKYdcVCCXjxTmqYk4p/YqINX8qIEx8RmKPNnLoqFsZu9gKY4P0nOJMFRB8TkwQvWyc7i 2LOdGhrXOavJA3DSk5P41CdMEDPQgpoTFi/ghQX+uUkiCvSh9wQjLXDACxUwNJMCNaj+6HVBM1KUB+q8 KCUDulGNQsmM3gynHajYKCtWCHX/6zrHDseHO+LkTJupASNOeQhBIN4UKd0SouR2p6ShNqxWQnSoT7NA UoJC1KkSrQUxLaoH5uwFa3zDiUQ+eJpBWdCrX+2qWE0nsbIGajbo6xNcxnrP1ri1rCfFHFzfStawwhWt patrVF/U0bJtCKpn/KhKV4ql7/VtRNyZlLfGWtfGNlZJbf0dWElHQro+jrIjYStjHYshWvWufK+xK2fV k9nY6LWUU61qYbcKkcQi1i+0YixaJ9c7cIgVRHaNEe/Q81hCVXaz/TGtbWfj2FnJNq1z9SpuSctKijJA taj73t3e99vZirYl6bttXENbXbDqFLTXtSnQiHu+9NX2q7oV/+9iW8mLwdLBqtNJXuxEGFvOkpM92CUX jELEpMmGVX/q5a5l7QvUbijXv6Qrb2QtWM6jNHivmyRmSOsQRZc+6h8Tg2wE9arfDUPut3SNKGbX67Cd eph54i1qcX9qVCk+mJYWAGke1OWUE/HGt6E174JzzL4JkrhyIwYxcJFLMQAjxb877qqOV2y6sx6UQ7Wa Aj7P+Eqq3oFz0W3tfv7XKkv1B7xMRq9t/zpgzcqVuQPGnXCXl0+1bpasCkYwnOvrhSdvk6BU5oGVCbs1 1joqvrAVcHUp+Oa3pmfN5r3zmsNcaDWLedF5LRttccph/N6XuYcW7RbsbBg8o1TPMz5glv+9JGoMW4jO GtY0ZVVcUDkXl7iqwXGakVvaMXtXfbNO8mNpLdlCM3XSD2u1WUUM2DZzmhJVDvWo6Vsl+FIXzSB2NHDD e1snA7nXyYX2kCetEjZ7Gtbhvfa2qV1mLeDapBoOYkmfatJTJJvPipGafaC4nSgT675APaqshFq6/t7b YZdzcUT36w9+c6vfS+VolLmhjqSa+MRUIGqxO9pudrPbFO8W6STRV3FLS2yI6/bTsSuRcY1H0knFvtDH Pd5uipei5CZ/JMrRrfKUb/TLE385qGN+cmDbU9h4xvcFhe5pUsCc554cuRiPjnRM/ryOTG/6Jf3NxqhL /eqqsDrWt67/8z1z/esY3zkeHG5kEQ+c0j+lqc9PvER8WHge7+AeIzn+BKVHnOplsLsVtC4H69a61fkz c7R3LG1L2Yu1l0K8CkeXSLpDGQ1TtgKEEc4GvsfB75IF94LTOzkEY57RUzGs4pldJ7nP/el1n7zkVc/X KOg9C5aHw+dNC25VYzo2u81tsXpTveuRXsuJt+SUAXXzyhHbr+STXJQ+Gy7kG5nmZYj9G2a/aohB7MC+ zq+46bN4A4q+9Ixv/NPHX/wCd3zlg6p5tzVqfn2qd1ztD7n5xSB9N1Df+HSO7XnRrH35AT/4incoW6ZJ DhY5dGdx5JdzRWdzUBVsf4WACvgF9dcG//cHcELWYtmHb9e3VYBmagDoIgQ4fwOVUTanbujXctkGgQvz cyp4cWEwgWxQgbBygSS0fyHmYBCWRNw3ev/Xg1M3fy54fusnhOrXVyHnVi14hCgIBjC4BjKIWT0lUcGV gZG1gR8oOt/XgyCzSHh1fkl4giQ4bER4hF84hmTQhHkHf5qWaZ5XZAEGdHd1af53NVj1gaNUU8dXUhKE fxFYLmSWUX4FOYAYfwvoBWhIBl+2fbSniIxGhdDWf3MYaMEngDwIdrVwiGMQeZN1bXEma4/Ia40IgIl3 F68lipY4C5iIiDrWWZfFYkbFeXhIdHYjOonTI1t4imHndbi4i5uQiv+8+IuG4IvAiEZoBwWxsm8sV4BG J3bDuEeaGHCKFmsR6H6sJwnC2Ixl9IwuJ42dtoRD2HXYyEfDl4jPp4BNdY7Ft3x8yAjXGI5iFFBgSIYs x35eCGD0GISI0I7u6EUPp4TwZz6B+FRlGIb5yIz7WEe5B1HqlnzSKJD+KH9W+Af6eJC6wJD4qIzbyIAj +JB9qAgTSZG2YJEcuZHcaISApYYoqYSL8JEgSQu7lV9tVnQieZLpiBjM1wgs2ZINNY+WkJM6iVE8SXIG +ZPYVIRCqYtEmZR44JNK2ZRawJROqQp4l0dQGZWnQJB/VJVWSQozJ0hauZWiMHM4KGxLAngR2Qr/XwmW oCCWYwmBUwiHlziUajlGbKmRLjiVaCmXcxlGddlxJmiWcEkLabmXnNCXFzmSXDSYhLkJg2iX5deRqKiX i9lFZdlyZamBXqSYk8lFr7cKmrmZs4B6ZfSZoCkLeBmXSFmaqlkFpLmaSdmarvmTsGmMGVYolGZwGHhv O/N2BuFSLFUycWdhZUEWZ0lGfPJhJSkFxQgGnZkGs5l64nJqsiV4n8ht2UY3dINlsKWDvZc4vVec76iH +Hidj1eIzFmNbvCc0emJ2nZa3kVix9V5dmMnPKidoxd6lTiKtqdGhomexiia7iaZc0B1XsZfANl6JTmF 9cJsBHJA9TOJgGYf/1kYgPuZRihXDkRHjWc2ju10k80Hk4Ggnj4jnTT4arb5ktpVEAxKX9tBY6LHHM8W Qq7Gnw74hSk5jeO3coRomScICCJ6EjM6o0tWbrbXf4UybxLKolgIoX2WF9NTb3PUn+Y4kkSVVlSqhyso CD/KZtZ3jAZqaT2GohyloiKEpPnpogHYFJryEP5ZkTWKmI7ZU9uEgH9pk1jqB1tqa13KefAZpExmpBnE KZfSoquVpg0ao97RprcgpUuogtEYjzgKqSEqoLJXoefzp4QmaP/1hnjzGGdaqKMoDfMTFIuTV3HUmGZY hhlphkLYqhJJqdNnb+2JlXB5fbmXoozjqb1Xh/+M4Rccgy5aGH7E2IWD6KhmM1QTF4h+GJh6kKd/J6Q1 l2rtOas2SKaDWmqBZp/1WZ+HinjgGZtY4KzYFmZoo3tfup5IZk4u833aeq0mYj29WqYA8a3gunew6oSz FYu3uWGymptFxC6jYUO+uS744jdahhD0Wq9UIK4Ky4sM27C4+LAQ6wfN6XoQBnFHObG1ULH/CZ3mCaQr ea8ae5WKKmVRpXccCwcSO7J6IIuPg5GSRltx9ZIJyHAQaVxysLIsO3bLlaqOmpHjOZAqSatvQFELtbOw cJNCW4jReqeO+bSQ6QY6wAPPhbSv0KFl95B1CrQiZz5Qe3HL+QbtZbVSeaX/Dem0l2aUtWq2rZqyXyBh ZJsKS7uRcJpcqEqSNCeP4um0OcsDERC3cpuvxGanfwiQ2udzZIa30EeWCUsGUytjgGtGbusKr/S3kcuX 5IlGj5ual+uSjasLHzVhnbua3iS6o1uaMQa5p1uYQMihk1sLOpC6nLu6kwCzTfWxceRNFuBetFu78he1 d/RResa7vftF6aiMrytG8NQLxlS8vku4yFuya4QD8dRPpuu8iaCh0WtI1NsLDNC82LsI2rujhoROvhAB skS84Uuxm6eNhERNzSQMDBABEaC+61sHcrhrmQtMy0QN83S/fJC/eEhIwVS9vMAAsaQCKvACOHC9ANyM /ziQus6Uvg+slN3rTC9gvxW8j8tbURq8wfvoTcMLwk3ZweBLwkmJA83kwPgaREUkuMX4peWwNC0jagQy nz44sMGpRO0gNS9VoXyJscMhYAWKu6HwUfU7oKAIicf1qIvIhtt5VVglxaHaZ1lYqiqEeHjynclbChXr pb4GvJ/wuP7Udwy5idV6oNCIXSLyotgKfvjBrVYsNhDiWn9Wip97tdLLrDbrZEbsCcubxErMX+b6aIab f23Mq2/8f4cnX1dDiV8xNNQlyX7Kj2Bajoobhn3MtnvYxXkQYwzwwZDnO2jMiZ6FyDuoxTYco2bqGNgR sFo1yfXmyaOgfuRHiCp3ZP9zS7STELr4a05MnH66Ba0ShRn3yZ2J7IGQfLAw+mwescesAHIGeLOxpsts O56VEGOzG4PAjHbLaY99msruSjT5+anLVnrDKc70Oa6Sy5Pby35ea81f27WbIFh2oK/CfKC8E8YbaMym qKvJHMWaQcfyos6Jyka2bLa5/M4/+8ePoM130InKRWiE7IhUY1iUrC9tQqjnzMgks8z8AM2rkNBPu9C4 PLeZMLYRrca3Zp1sOMPT6oENlNFKuj0P+nvuIdNXLIkI7c5/GYQpxoJDC6KY8Lh5IK0tXWZQvGL9vMic g9Ejc4VznMV0yK2GlcdIS1GWy7PWWcrkFmQS/Tf+HBX/Yw0p7aqfn+PIPO1sYYy9FFUCAaxNC0d2rqJU HvabcCejLUVDN7TOXJVD8IPVO6uzKFxKhF3Yo3TYiH0F9EwHtDyp27zYh4C1vwyOkm283ehHin3ZFmsY GQqTHvoqgUe4xibSzSqynA0IoIWqNzqGaoi3GsqsOInaqc2+ncba13yhDF2tyEbbtR3Xt7238/yAumyZ h3sJm/3bCGqSgMmqREZwd0p9kJDcyj3EpI3bw32Pt/vOvR3Z1f0HjU2CATm4eyiGpY3cvv3dW0fd6i1J 7N3ekPTe8O1I8j3fjFTf9i3EyblG+A3f7jtmj52L9o0L1RjgqdDf6k2zutm6LpuY/+k94LKnMz2qqmGE 4N/tpcLNqkv34BBufwZq3A2Ic2Nk4dU9k81NkAaOCSRe4kKdrJxc4Rze4R5+uFhqu/9tCysu44CU4zqu 2THe4+vE40C+R0I+5FT540YeTQxbYSkUb090ymeXtTAtUxhUYmqHjKbtjCeGslneCRJbizwNfE+taKAo XImIXkvMa5o32qHYSP/N5TDu3VlzPDjNrvDZ1abKxHqeqbuWaWxcyW4OoKs6R19uY3oxgGUKO5uo1Jva voL+bbzN1Cl+qi1O2pl83JM+CYX+pO/6Qc38NJoKhQIsh0Pa5zQo2H8kzdedb4sYdF3OCZtO54MKFV1W 6nn+2v8TrWtJ7WrZBZTo97N1munWiORuYuijGqxkE4XQ6Iq6WaQaaG1r5es0qZGw/eioqWyy/hTvKjjH +Xdnc66DxuqhDmkbV7O57epxju2YgoWdPifr+Gr7aeuNTszR7nSoB6Jj2bav3ovEbhlYYYq/l+iKjues Rq7HGI3BDMT2DihiiJnN3UWxvjKBM8mZ/YQGz6eWlfCNJuyGxPGhEPFXJD3vUxFnnvFEymizJ91h3UrW rkZLHg9RBDs+jGI0+1n47GJWXrj6tu+n5/Ef3+9J7ktFHvRQB/RE3wVhu9+87OByfvSjvL8Up5KjafRO b24t706yveFNX/VpqKOYjIM7ipH/igsLQy/ZSiWpdJq3kbn1XJ+JCZjdFP4KZb/Yt3tTcC/1ck/1bb96 E56M5571qDD3iF33u6y3a7/3l4eMPUPZ+g74Acr2iB8JPl8Igh/5IOv4Am75rDv5lK/3ms9Jlf/5ZBT6 hX2WBn72Xu75op96F8vzUc+3Eaelqr/6fHVQp3/1dyf7kE/7WGC76C6LbbmO4dH3+v6PkM37aeD7au+X TdazWLnd4h73fUD6IAz9dw/pz6/4zo330z/7yN+NQvvTwp39wR2nIu6j3v/9Ob/9Zwu134j23M/5UkD9 Fcxx+X7/f0/+7Y9zIr70dwAEKp7KVzQekUnlktl0PqFR6ZRa/7VesVntltv1Kg8HZLhIJpfFZ19YfXaL 0Ww0GD6um+/pvHpd//6RhIgACQsNDxETFRcZGx0X+R4bBSUrLS8xMzU3OSGNIjv/KENJS01PUVNVmdj8 VrNGX2VnaWttb3G9YnN5e31/gYMZd4WLjY+Rk3uJN1ud25zj8J7lqFs/r7Gts4+236ideMTHfcbJi86R eJTM29eP3M2b3tXljdrR48/d7+XllFmBmsPoH52CSwQCE/Li1MFIB9d80iYxTjdX3MpY3JPEoZ+CEOvR yyey3BJxJk+OTJIu3UqS/VLegwdTpsqVEwEiTJiQEB462Jrw9BWBB46GDzl67IYzYsWlGv8vapQ6laJT q+xilsta0uVLm1/BtqSJdatIeizhlaWa02Kfn5D0vIUitJc4HUfh5E2qV6crp3wlOlzrdirgPhf9piWJ lqzXlmIfbx3pWKtZlF4rqxvM1q1AaNAIz/mcWJpBg3lC+9RGmpQOyZ3+sT7c1PTejGCsenzIJ3ZtpmRh nr3sOCvk4q/tac6M7jITxr85d07sBujsN7MJ75SN8br1vKq7pxJiAVW17SA3e0dYmjb23+Z9X+0avKZy scvxj81f8/47e5jvU4yrMaJrayAD2etOwe9Oaw+q6hYcKMJUXCuqvGiCEgq9Z9YrTTfEPtxwN9n2UQlA sCYLsLLkbtr/b0B5AHyNJq9kSwY0O4CacEGMREsjQwazA3JH9EIZLxX4fmRNxLhwm+hDO570bMRwTvKv Snb0m1FGclQ8SzKzrgRuHhlrRAYcHIOUUEggdZIvKTXhTDM0VXAQx6gLDePIPdv4JA3EJ9fqjU/o5rNy HcqyXC7AfZATcCbFYsQs0aqi201OHRmMjU0IQbkR0zjDK0UHBngg70jqbnuKyCVTVQrKwaakbSMExwQz UnwcdZGlL+NRLteQqJS0wAN7PBDD8FQ7zE8koQqR0ziVRUUHoiK461S/onJTW5BcRfMqiLh9j66wGgVW v/5igmy++tJqrtb4hj1k3Hit0MECu1YB/xe19FildTpA95TvM0LdRZE5c8ld7DjLEB6wXTGde41IerfY l+IuprVTFW/2+OYjDqU5U1lsQ+ZxZJC3oeKllSPTZ9cq+UmxZX1ahHTRmAm+uOKJdaaiTh4YuLPnoYku 2uhTdChBnGqPbtrpp6E2RAchxCnB2qixzlrrrZGYepwIhOZa7LHJpliHF4haOuyy2W7b7V90wEGFtKte ++278c6bk7NV6LuECEg1J4IXrtbb8MMRH0afCFTAofDEIY9cci5esKBvFV7Awe7JOe/c889BD1300Ukv 3fTTUU9d9dVZb93112GPXfbZaa/d9ttxz1333Xnv3fffgQ9e+OGJL//e+OORT1755Zlv3vnnoY9e+ump r97667HPXvvtue/e++/BD1/88ckv3/zz0U9f/fXZb9/9929PiVebg8M5JIVdklnFFe9ncUV+5vc//wlw YfbDFQFfVkBcbelWC+xV/+CHDPmxrH4TpFn/XlYP/SHngQjEIIwoiECWddBlFTTUA0l4QQYOx4EdJGAE jTHB/GnlVzSM2MP41498ROE4OuQh/jRoQyoFUYgzRFFZbLVDlCwRKzd01MJgKAwZBhGJRDSiD1k0xSFS UVhWLKISZeTFdEmqijhUIhbJGCMmNpGLRAxjFF+hRTS+MYwBhBkaoWDHLprxizZ8ow8BWcf9fXH/gH0E pBcPKUYLqhGOuJDjGe2XSD760UpgvOAkFzlIJKrwkia0Fc4iecYK2uw/jOxKzEo4ykYC45GEHKAgZzjF TL4yhC68oghPeEBPesmWuhQl/TZYSTaesoWF/N8qf9FKBgJxmHjcYSubaUkplPFhf/wlo6ZJTXfBMpqS DCQdrYlMUvSwj4/UJiLlWMo81nKPidTjOmOZRkXO05C/9GY9i7grRIozFYwy1BPHyMxmjhFS9lyjEMN5 TXbCs40FMw7CsHnQSRpUoedKKD85YUAX2hKfHlRoLgt5yYuek5IcTaUITXjLFwZzgy1FqSt5mcV2YhQT tLQpB5/gPz1ylD4T/5XoTkPZyZMeU6VEZalHOYnCEdZvnzR16lOhGlWpTpWqVbXqVbGaVa1ulatd9epX wRpWsR5NAAJ43FjRWgkdWEsHNKCBAIxg1rTOlRECcGtc31oEu9LgrFgwWSKsARspmSEgZbrCvOh6jL0e gQZ45SsXeGPYP9yoGdiymFwmK9nEFkMHZTVCW48gV8jqxgqalQtiq2Da6vgrQ5vFm2eL0NnPPrYIjdVr XktrWSqg9rSqjQJvV8uU87j2bW3FLWhjS1vk+sCtcM3tm66hqWl4rCKd2lc2zAOyBIHjY5QN1DRCVt1N YXe6emDSds9LXGk1N7nWsqt7neuD9x5Wt6mRkP+x1uQjKGlKTT76VGrWBK1XPetS4MWUf7/DpB05SL2m 6Gx8cWtX58KWuX39bX2rIS4C88S6Av6vpzCsJBCDKsBoiiyJBdxgVSzXrrd1boTj+1xvEVa4HQuVt1YT qiEhi03HItlfSvzfkRHrwPxVsSwi/FgJ+6CtL46xjIls3R7XF7PEinKKAYziOaWqwFr+MGm7jOMjp2K+ SzZzXttqYSmcmLVpOu+mxGzfOU2oKYT98pu8HGQ9XznMdfbtmNWa1zM39sxd+Gtk2RwtRTfrT+wZ8moQ hLKULYU70TCvh8B7MvJySLoJ/jOgH+HWtYrarY1tbpMV8Wm4gDp5Ejaucd//Kur5GoLGpgAuq29n3L3u Nda9VvNoVZ1qnuG6d80t9bGP/WRiL1u+yHY2e5kdbSY/29m/lvaRqY3sa0t712v19q63HW1UJ0HU4Y62 hM26VnCbW9xlRbdo2R3vWYzgAfW29wMUoAAABCAAZeX3vwUAcHf3GwUoIEHBEY5weV91Bw13+MMr8G+J T5ziAkDBwzG+g4Vbtd8Bn7jHKR7yjwfc3SVXthdmuvHp/VrkLef3I0KZQ4Z+0Jq+BKbKC9FZGeQA3pzt eMkB7nKhm7zkf+BSfjpZMFIOUlG8+ifOlSAACUyd6lWXAAZkEHUTWF0CKyjc1rmeBKlznesZ0CvZJeAD /7J7QQdCd3gAGg73uE98B3AXutH9A8mhnpKYxrQoFCcDdbGbAOxXJ3wGqp71I8iA6hhgwQowMHUMxJcF hZdABkwweMRLnvCEp3rm5WuCyDc+84XHAOHZ7vaMv331dXe5tadQooMh1O8y32Wtkhj4SQm+CGBXvHwb f4QcUD0Hn928BGLMgqmbvQmb/z2TEQ96Iwxf8me/POyp0HaXt577c2/5ya8ge65sMo39qYJMF1lQ3iPB 90co/GdHv4KuUZ35RWC8BKS/hPb7wAQsAH7+i2AFqG4FBCDyMAD7ss/uJM715K77Vk/oAgDlji6nusT2 HCabCkj3NHD9em/qfk8HRv+v/pRv6pRNAEnQCO4PAJOg/XQA/4rABVfQ6iaPEATAAW3wATFOAV+uC2KO 71pEp2rvftQP/VKO3cDOBGRABlhg9GawA6furO5PAn4vBZ3gCGUg+oogB4ovCXTg+JoQEBrwBsUwDFfv C3qwhvjDOM6wp3SPCDnQ/dDO646g6pQgCqdw6lSQ/bguD5Fg7K4O/LaADMVwEFsP74JwS9gQlygwoGIq ETnQCpdw+Qrn+OqQ6u4QBj9LBq4G7E4v8kCPwo6gC6vuAAmBEE2x+wDhDBdF/YLpj5LjFRPoDY1g/wpw 6rbQCZEvCUxQAm6RCkMrF50w66QO9E5PCUxwFzMAAaf/4OK6z9ucEegkjuQcMAIJweYMSmHAKQg9aumK 0Ag9cBa/URN9gPokwP+QYPQk4Gp8EQWBkf++Ue0yrwVV0ASLbwS7DhCYsfUCIOH4sR8TbhoLIagaiKcc cRGDRRbBUQqNwARZoAXhCgQlr3DIUf7YERMDsB33b/os0gcYciEt8Q+msd4q4AFG8t5M8t4E8eGoMRUt UC1a0RUvygKFECF9YPMo0gfuDwMEcMLo7yHJMRmPwASlTweoz7kgUiGnzxODcvlCsepukQumsQJGAAVG oCqt8iqvciRT8uFQ7lHUxVdchuk6aiaHAyH9sOoyjxxPUK/Q0epMYBPRrurKKi7R/9L6rE7t1q4Luo/f 8nEH/JEfW+AGuzINP8kaN/Bm7slgGoYDBaDzHNMcI7EcuyYHVgDxTo8FnqzyHHMzCa+sOPMzzbExOZP/ PtMLbJDfXO8Uc7DhJDANuVFY3BAsbyYbu5Emh8XiCu40tzLjFhAH/bLftqBEEmgNiTBdWHEDfdA2n0b1 chACQ8776A4FJE4LNiosca/vQgg5yVI5n2YHTK4kS/IknTPkUKACwvPeFIABdzA4uXN54M4Zta/iBm48 JQ4+vw0a/609y0c6C4c+/dPfQq6s4pPflFE/qScAHsc/IdDdBjTkOisaDTR8Gg4+fWBBie5CBVRAha7t AHQlI/+0e+ruwdKN6H6OQe3zROETQxmU6Ar0Q5uHQ0s03VDU25jM2+yu7upuRK9mRu/CPgHRRadHOitO zdrO+3wgR4vU20IUQRG0Cc6qRYE0edSzPrkQ5Owu3eAuBXLzBiKwRyu0Sy3srDw0SqlHQ4fURgmU3wJu BBSgANJNvpgsCzvAAzBgAh4ABY4AOJ0RTruGTK8nMN/u4/pt4lDAAQrgAi5AAhJ1rXgu4NZqTj0gUjsA BDxAA0ZgJdXNrE7uR/1UebQPOlFT7lCzTRNVAiZg6iYgUeFNByJVUue0A2C1A2JAA1rgLuQq4JRA4zpV eggUR1USRwMgBQCgVGUQUS/gBOL/SwdgVVI9AFKbtVk5oAZGwL2eFEp3FXh8dTVRswDIDlEb7wIQ4FZ3 wANyoFlZQAaadVJbNQTYFQbw9MFiq0bb7lqf51Obk98AgC5T9QImAAP8VQLg7gE6YAVmoFkFIF2VFVJD oFk7KwbwtAgQ9Nt0lV6ZJ0cfzt8E4AEK4AS4Fe1K1ViNVQDmdAXQ1QMStgN84FUFAARCQPHMFUxHtEkp 1j3DUOLyte1aMC4TFQEMgAJOoC/9sgIooF9hVVkX9mA7wFYX1gNioALiVN3gbmY9NeACFe6mDgEcgN8o gOsSdWNvYK36zS+rEgVSgEAhFgUmgANE4GBbtgjmlF2btQLu/2LipFZKq1YHHqDqEMA7daBjp25jERQF ACA39RE1UeAh0bYDQkCv2NVZPWAGgBPk6vZ4UHMHHkwBuA4BtG/qDMByUUABpBMF7G0q+XEHprLhNLXf 2i4D5M8DQiBpIRVWY0Dj5nZiJ1d4BhVJMTdzJ6AGO1cHRNd0HSDfTvLeTlclM/VIJwAEQCBlW3VZHRZi x/R2f4cZX04BEAAB9PZqATcAHmAH8I149Q0AyHd8H4B8z5d8K0A9H+wuUKADAoBSO+BgWxUGLBdsqTd4 2netsDcuDQBB09MvwxcA0rcCypd8ERiBx1cBHuBBmZRJEyBSdWAFYnVORYBJOTV/a2dQzf+qArQX7UZg AA6u4egNAEaAfE8YgSvAHxN4fAkY5MwKQSuABcqVAypYViPWWjV4dVyvBuOyAA43PaWy3tA3gRM4h9cq hY1YcAFAAWpwUCPwBJaVAF+1AyZAvqZ3h23Hgfv2g62uABpOAVpgcM8334x4iZ8xfc+YfAXAhBswcDnA 6yrYXx2ARrU4d+7XBwwA7cDYdNnUhdGXTddYAZxxB9aYgEVXgeFOSC0OA6oYVm24gXX4jksnAL52BOKS BcB3JM2XjdXtkCPWBwz4jCO2BgeXfBvu4uC4Ay7ABzCAAxD0AvCXkjf45RAgAFqAW7NXAhDg4iigAhTA AUYZleU1ANb/+AGYzJjPWAFqNOASeGxVWZQ9wJVlmWAFoABwlpZpx1EBwABYYAJ0gAU6lgIy9gTMmIAR OIcrFJR1wJCXWV7b2IgrYIQt1wEwAEEPcAV2IAPyWJtlB2x7twCylwJ0YAIMwOJ2gHiX2RkB+Zl9oKHT WUmXuSrX93ARgAX67QLqVAc0t+f8mXXeUwEm4AR0gAK4lQUqwAZqkIHV94y/F3wPmXyZGJT3MabLc333 8QAx4AIaMlUP16M/OnX+LR0LoAAI2gB0QG7vdKZjuqlb2qmdegfWNwV04KDBeQcQFQOweT2DOnXm1QEo AAXCVQBYwKQN94SVGKrVeq1VGABWeAfK/xZgLyADQPZw27mrV2etsHkHHOAEEIAC9rGdpZqtY1oBRsCd CbuFH+CwLZcCkjEAdhpRsZlq8fp02lkHRgABCiBrJwCMC0DuqHJ8L26Y11qADTuxpzJ9qfLipFN7szpk zaruKrt0HNUBrlazA46kC06NZVSN1fpSWZqwoVgqCfh0M1ajQfYCGngfuXq2PydEr5aXedlN9/Fz0dcZ lZmtvY2wG9h06w6BLxV8AyBR8Xlni9RyM9i5DcfbKiBzHUAAwFPfptVGE1sAglutEe6wnRkAwLfeLPd/ TzXyELVG7W6S1XtsIrZ/qU57cZSIEfghfcC3XXqeTbgk3bo8G86Ej/95BOBbv4E3gf1bqo119JR7rXDU wA+ca16O7Kh7JI04PcvTiIfXiEmyiQeXgdcXAshXByb6fqU6lWl8hSPug0+Vc7E4RCs0xSWHQMkOnEmS BMwTqmGccBXAmBNadA07BUBXcJl6KsHWutf4cyHgTq9Z3aiulUNVr5QccjpLB1KA7E4A7qJcu6d1Wmva dO9US/2ybPXNL8HX26pykBN4JOtuaxX1zB/MV1F8zZ8m3fKW63BZqiG6qZEZs9dKcEmy3kCXgfFtjMsz Ygturektlfm1yKfuBooAfKUTqBn9bQh0j78YeP1SAUjbqRuYJAMXqlf4y/tcJBlbZumNJFdYOnn/mQI0 gOqQ2eJ8tNXzJkRhveqwGacT+07BdirTOsjTLZEJmNPrbQTWNzXLmCTL9rNZ4NinDgDaLuKgk9nxhkD9 lurq+LCzm63505iZbKYX+FIvnak/l4GJlyQJV5nrrQUCoABM/dzLagQA9e0Wnd11xt3IjpxVuYQT24WZ jLgN2LC/fIm900olzuCiPN/qrgAagOSLuqjvPUWB0+HbZlAjvp1ret+0FOFaAAXGGKrxre0w3NsxG6JV N6nzLd809aYxHaeRuuQKWnp7FGxZneW1xpIDgOw0QAcCM30n1kvtW631LdO9PcbXOIcrPbZMHOAJeIUD oI7bfK2uGL7j099k/8vpyWaoHVsDTuAEyr1I1zc9TzTr17rebrqp7xdvrR3dTdw8TRfDc8ABslegtfex CZn1IBzuEbztbjka5bbqZfo5J/2QF3uFN5981RnQfRzX3drsHeDgJYACjvQBkHheG17yo+PfNBc+Cbrg rj2xz5i4nTqHFQACYNrbRPd7Cfh7A8AADn4CVP9LQw72x4bkPtiLe1d0UQACPh/31bqBBfQ+y2okgdmw iV+gTd1Oi6A88ZP5xUZN3/1vI/y+rX+Z17oGHY4qzxN0m9i/r9lUUXUC6jgAAjgHzR8IfMIhsWg8IpPK JbPpNAoCAoCkai3oFI8HoOv9gsNirjj88Ol8gv8dClXZKnZd7WgXQEgmE+tDIIgHBN4E2D0ZHiImKi4y Njo+QkZKTlJWWl4SBRJYcQY8oGyRlY2KVZCCAe6o7qSQgHZ9VqjmcFqR+BCirKoGYPr+AgcLDxMXGx9b BkLUVrGgBCicSoONTFt3gaqiMEsICHnuoPmEI5ebn6Onq6+zKwYGcFMIoChEX39VVCjo2O2MCLTghWJE ChT3vox4YIeCBAQTEEDEoINQgInv2mHMqHEjx44ehwQSwA1LPTgHAdDTNULfmwf5KLhMeDLmiBY6CjDL gOudgIkffwINKnQo0SRSAuDkBNETPTA7dECd9qDaCC1d8qGchsLPny8D2dz/qYXAwU5C3oqiTat2Ldtf Fhdw2iNBwxqr0UZAFSKH1CcID0hU8KSghZvBe8vsgzrRq64AFRpWwSPh1riQbS9jzqx5s5CJO7gh8KFF FArF/E7O1NFTtZc2bW7GdZiGXyBynG/jzq07XRQBSWvZCPRmjuJxYnZ80hV4BIRon9i4TlgvgBjT1Luw 2SHLAAs8kifw43V2N/ny5s9DsviAG/gKbrI+I3Qvjil710ovbpFPFwofBgKw8JBkEHjWC3oHIpiggkUI coFYEuSQi0HXKFDBAg8QVpEOAHzimEvv3UMIWP9NsAMCOjDkTU8Lstiii7dB5ZtcEpwAFXiEmIIaNqfp /4iQLk8ZQEECBQiAAJEGFPeikksyOVQg20iAhYksUPAUGxVUo6MoPXKBAgurIImUABQEUGIhTaKZpprr hISABjpM4OBWCAAUAAoU9DhQHaTYV4Z7yPl2E3h3IjXReGsimqiimFi0DTzgnbCDABr4cIIbD1jlVIx+ CjFhGHhBtSV2ALzxWgVEFgARBTpIIKmBi8Iaq6yLSKEDnZIWIIUDra4xQlVhVGDaYV+coUMLZVgnBijP 7ZBqrjkY4MAUUaQxq7XXYnvEO3no9JAPVbwzwoSe4gfVsF4Ue+4caCj2hRwPOKDQA0h5Z2RPuRKSrb77 zqqKDtx9JoFNO1wQmh1t9P+ZGFSeeqEFGup2oSGPrTkQhwK+NZRAQxAVcLEU/IIcspqq9QQeVBlcgIHK N87DRlYAvMNww+mW8QBU13HIYT07XGxAHmLh+6rIQxPNoh86pICBBBikfEHKGGRgES8N80XzKVkCoIUC oAjggENKaWxHRUWTXTZ6NwvwwNMqs91B1BZJscUp8S4sjSnuTcW11xAxE1ggZgMeeG52lMy24Rh0AB4u FomWsxha1C2NY3VUwEIOONXLNwIE1Ca4559fZmhPTbetcgcXeNOLHxV5cRgXdLiCLtVZf6hLHywUoIdk kSEAsx3Vgh688EIR3pMHHRiOfAfLn4CG6uF6oQ+muqD/JF2m9WghiypRUFAvZHkY+Y7Qw5NffkYh9RKA 8suzv7wHGKio+i6/On4dGZhWXE8dCs1TAAsP8E0pQbON+QpoQHRI7WbI88Dx3MdAD6wgA96YiGp2QJg2 iCs6bXAP9hRikK3swAAICEmqEJCACWgsaH87IAtbaAyx4aInGXBfBxi4vAsIwQMTMBBFajOCKmmjJXWw EwAcIAUU/IZIdvpe+HjxFBdCMYq+EF8MfUCBGh7vgSty3wVOMLY1EIYNARnIQEqlGhtQ4DcNmYAXAyDC KsDsHWyQIh3rGAl+RIEQ1dLAAxkYNR+woIZYRN4EUBCc1ZhmdTY4gQPUaAU8YCEQ/z6DgA36wQs7YjKT iZAUVww1kUAycDZY7CP7mJYHPaCyAKniRmSqsIcGCOAEBUjBLrIDPE3iMpfa6iS1DJSCD3gAKiuw4QPb xzSn5UAILCBZwFgpwAX00IL80SU1q9mZp5hGB/3pjAsk0sdiLg9xTruArejEqgmwwJm8k4DvahmQFIzP mvK0IzazSUHVteCbgyyl02wlAahQQA/MmBEeAMCL2tSyNPNcKCaPZk9zgWQDMthnAw1XpH8G4AQzehA7 dyGiWqqCoSKlo7Hywi5zhUMKE0SBBj6wT+Sl7KKqkc1IAkM4J4L0TCPdaQvj+Y2Q+EQNUPmhS5XHNHKs QZgSuP/AHgzgt36I76O1vCVPq1o+P2grmz7YynjSkAJ47WGcTosSABbA1RuIzTMk84Mld2HVtxpFcAQc wgQ7U61eeDIN9RRdHuW4hmc8lDZR9SlcCxu4sRXhUEbISzj8VUFXhbQ2tVKC2MRHVcNi1mzUMs1JA2vS k66hIu8wqWc5q1IqZja1geOkQ1XKldd2srSBhS1tewNb1eK2bGLLo2AH28PaAve1vh1sIi+b2+Pqy7cB yalHh+tcqTIXkcZFLnWxFU3o5nS4lRVbZbFby1pxtrrizZaIonpQ3zI3vcwd7NGONt73Wiu0u3ANBn1l X++qVxs/ym5U4evfWX3UtVwxb37/0yu+7/b1Y/9d8KJUg9ACQxjC6FsRgysMq/AYOMAQ3m92p2vhD6MJ w+mlL4lL7BrtpdfDIF7xi0ScU1Jhyb4y1hN9/6ReFbM4xwvKb3B7XGAdA5lJ+Q2MbGOkGh0oRL1BXrKL 8ktfGUPZvtFRL2GZbGXy5Pe5An5tlq/sZfREOMzZMfCXy4xl/Ip5vgZWrJnbnJm2ppm5HAYpjt1sZ6LA Oc5htsyd+8wW7uo5p8vNLpv9bOigdHcVD9YzdEd76Ec76bmMliNxIW3pn2h50s6t86U7bY4ey1fMUc1j bzxt6oyoWKoaXq9d7XnqV8M61rKeNa1rbetb4zrXut41r3vt/+tfAzvYwh42sYtt7GMjO9nKXjazm+3s Z0M72tKeNrWrbe1rYzvb2t42t7vt7W+DO9ziHje5y21uQ/cg3ekWQg98oG51H+Hd6y6CvNnt7nqz+91M wHe+501vfRtB3gIf+BAEfm+A99ve8eY3EQYO74A73N8Mb3jE/d1viy8c4Rc/+MMT7u6C17viGId4xy9u cZGXfAkPbzfHJT7xlzsciid3ucpZ/m+K23zkI4f4zUFuc3ongeb5HjrPKd7zlPc86D9HusKJbnSlgzzq Tp96xhf+dKmnXOj3lrrVr071gnt950Uv+c4xbvafb53rBkS708Wu9qZf3exNKPvSyx70sP9/Pe1qn7kS 3E51ptcd6CrHu9693nXB7z3wcSd80ZNe+IYb3u+F53vjHz/1sx+Q7m+vvOX1fnInaN7nbGc7EkLv+Mmj nfSbP73G4f75Q5je8JyHO+oRn/fOz7728Y686t+ueMfHHvMFdHvOe3/53hcf7HNHfs4Pbvu+kz72qF86 9GsO9KwvHhE6Z/7gnz99yMv+9uFvu+p/L36Puz76yS/9+lcfPMmfX/fW/zjoua9wuS//8Lz/t/HH7/u/ P13/Qd3p+R8Ash7xlZ8AIqD7mR/8OZ/+cd0C/p0ABo4DSh7l1RzTsd8A0t/k1V/GxZzstR4Ecl77dWDL KcL2ceAGgp//CAJeAu6b/eFe3U0c9G1fxLmf55lf+Vhg/2Fg9Wlg7rVd9sUgCT6e2AVh/OHfEEZdEq6g +MGfxBnhA45fFMogEgYgBfIfAeogBxJc5lHgBe4gCzohFDZfAH5g7glf1T1hCR5dFmqhC7Zh46mf0qUe DM7f4WEh1jngFq6e1tFhHIJOD+Yh7iVdGUrgCQ6dFkrfBLYg+gnh/93c75UhASYiELIg7ZEdHlZfJu4h +c2dH3YeIB6iIA5i+f2h76Hi8SlgHSofzjGiKx7gI5rh7hkgLIZdH+ZdI24gJyqi/HGhGo5h+hUg7XVh 5QWfKX6O3W0eKTLjBPqgLP4iFRbiH97h//5lYgSmHhtC4xPwYh+umy+u4QyGoTRa3jX6XDWS4vHpny4K D9nNYjO+njxGI+tlYydy4Th2nN/p4za24+iBoy8a4hR+nyMSZDziHDamox0mHgSO40CC4SbiYMsBpETu Yw3y39kBXgwinMGZXLt5JMuNoOh9ocFhpEjym0ey30iiIOypH8Ch5MxpnEpmID+2Hk2yZEwWX0fCXNZh 5LkBZVAKJYugXFEa5VEiZVIq5VIyZVM65VNCZVRK5VRSZVVaZVEOZVZq5VZyZVd65VeCZViK5ViSZVma 5VmiZVqq5VqyZVu65VvCZVzK5VzSZV3a5V3iZV7q5V7yZV/65V8CZv9gCuZgEmZhGuZhImZiKuZiMmZj OuZjQibZaNlkUmZlWuZlYmZmauZmcmZneuZngmZoiuZokmZpmuZpoiZqRuZqsmZruuZrwmZsyqZqXYRH 1OYkvEr6oNZPCU1/RUJtrpAjBCdIDCcS3GY77GZZFGclVBkTxFNymsdyno90BgN1YoR09iYi5GZwrpBv cmdzaicPgecTcCdxNoF1psN3micmjGdcZYJuPkJ7ZgI6oCc71Cd7yid9Pud2HkJu7oR58ud//pQk3Ccj qKdz5ucxHKiAJgOtGEGBOgGEDiisSCit+CaD7mZyZuhx8mZZEOd3Yid8Kudkruc3gASGjk+AMmj/h3Yn cF7o39wmaskojNLoRfQXjb5ni6Joi+qmjfYoi/ami/7ogi5ojm4nj/4nh1LRjf7oiRopb4qniD4pkyKp b+WogM4ofB5nlvaoj0rpiAZplmLplsYomXqph/oolBqCjo7pgLJpd07ocr4pD8XpfoookYrnhJqoieKp isopjLZpoM5pkuYplu4pm6JpnlbpnUYpLiRqnTJqnR7qe5bonwpqoyIqpj4qhj5ooVYpg9DppbLoin6o o85ppIrqoWKqp+4npJoqq6bqoI5p+gTqecJqrXporkoqqLrqelpqrR4odjppkW4qqa6orCKrT7komu5q qvpqmOpprN6qjkIn/552Kq9K654e67Rqy7QSFpmCaqFGa4lmq7MC6q7KKqXiarqiq7dGK6IiaLvO6I5+ KIcCK4jaa7oGq7IOq4o+q71u67yWK4Aq6rlm6q0+q5uKa7kmK7NWqr+Oa8Ma6rty67U6a6f6KaqOK8UK rMQmacJebLuqK7yCqciu64XGa8jC67IaxcKyrHEi7L5qS7+Sa8Qqa5BarMfeq54ebLNKKrtKrL4uLIrW LKkGbahuK7p2q8nCrLsmrcVu7NGWKsji69KerM8aq9QWra0yLarGbM6GaqaCrZt+LLI6KdGW59T6bNpq rcb2bNlWLLUiLMPG7NBaq6CaLLWqq8h+q9M+6LnPAi2t7i2n0u3gmq0SBK7SEq7W8ix5cqmaQmmNhmnf LqmZ2mmT7muZauvkRimIXquGlqmQeie+Jqvc1miHKmeiDpeaemnldu7IHqnoZuzksq7k1mvtdmm38ujr YizOginohivtpu6Zpu7erm7r/qnoPqnaFm/kdu5gLW+EJuhaVCgyVK9QWungssX1pgX3FoP3nluKYmtb QOdtlK99AmxYomzzzmb7uu/7wm/8yu/80m/92u/9slAQAAAh/nBocWdodW1lYXlsbmxmZHhmaXJjdnNj cnh4Z3Z6cW1leXJvdmZpY2hxbml2Zmp6YXVxZmRmdGdtb3BzcmdwdWd4dHVobGN2c3BpaGEAO2== --------------020606060003030905010001-- From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:23:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxCm-0008Bm-97 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:23:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13941 for ; Sat, 10 Dec 2005 00:22:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxBC-0001EY-La for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:21:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxB3-0001Dr-RY for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:21:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkxAr-0004oo-1A for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:21:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5LLnI007711; Fri, 9 Dec 2005 21:21:21 -0800 Date: Fri, 9 Dec 2005 21:21:21 -0800 Message-Id: <200512100521.jBA5LLnI007711@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkxAr-0004oo-1A 4420c350a6b3820c1ec0657bbe28778b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 192] LOCK_ISSUES_LOCK_URI_TYPE X-Archived-At: http://www.w3.org/mid/200512100521.jBA5LLnI007711@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10966 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:21:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=192 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:21 ------- I agree with Julian -- there isn't a compelling interoperability reason to add additional information concerning new lock token URI types. Since we now have an example of a second lock token URI type in the specification (the UUID URN), and this was introduced without needing to indicate in its syntax that it's a lock token, we seem to be able to introduce new lock token URI types without the suggested change. I'm closing this issue (with no changes to the specification) -- if someone else feels strongly, they can reopen. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:26:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxFG-0008Li-K7 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:26:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14135 for ; Sat, 10 Dec 2005 00:25:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxEY-0001t8-Rp for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:25:22 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxEX-0001sa-7H for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:25:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkxCZ-0005Kr-G2 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:25:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5NHx6007733; Fri, 9 Dec 2005 21:23:17 -0800 Date: Fri, 9 Dec 2005 21:23:17 -0800 Message-Id: <200512100523.jBA5NHx6007733@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkxCZ-0005Kr-G2 f822b6bd9dc894f3bfc3bef20e2a85bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 119] DATE_FORMAT_GETLASTMODIFIED X-Archived-At: http://www.w3.org/mid/200512100523.jBA5NHx6007733@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10967 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:25:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=119 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:23 ------- Turning this over to Lisa for adding a note about this change into the changes section of the specification. Once this has been noted in the changes section, it can be closed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:27:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxGS-0008SC-TD for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:27:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14262 for ; Sat, 10 Dec 2005 00:26:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxFp-00024u-5I for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:26:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxFn-000247-Go for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:26:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkxDo-0005tF-OV for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:26:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5OaGk007752; Fri, 9 Dec 2005 21:24:36 -0800 Date: Fri, 9 Dec 2005 21:24:36 -0800 Message-Id: <200512100524.jBA5OaGk007752@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkxDo-0005tF-OV 1a51d111bb650183a1b8684f51a6cb7a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 111] DEFINE_PRINCIPAL X-Archived-At: http://www.w3.org/mid/200512100524.jBA5OaGk007752@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10968 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:26:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=111 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:24 ------- There is now a definition of principal in the specification. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:30:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxJ6-0000aW-Mi for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:30:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14454 for ; Sat, 10 Dec 2005 00:29:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxIN-0002Q7-Qa for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:29:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxIM-0002PP-Cy for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:29:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkxIE-0002xD-Mc for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:29:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5T9Z0007773; Fri, 9 Dec 2005 21:29:09 -0800 Date: Fri, 9 Dec 2005 21:29:09 -0800 Message-Id: <200512100529.jBA5T9Z0007773@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkxIE-0002xD-Mc eb652db7c9f1e893ae461d33dc1d42fb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512100529.jBA5T9Z0007773@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10969 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:29:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:29 ------- Language concerning linear white space handling has now been added to the following sections: 9.1 (DAV Header), 9.8 (Timeout request header), 14 (DAV Properties, talking generically about the DAV:get* properties), Appendix C (opaquelocktoken). Closing the issue, as it is believed that all relevant locations in the specificaiton have now been annotated with LWS handling languages. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:32:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxLi-0001oT-5S for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:32:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14611 for ; Sat, 10 Dec 2005 00:31:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxL0-00046L-TJ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:32:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxKz-00045e-9M for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:32:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkxKo-0000Ys-Gn for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:31:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5VaSH007795; Fri, 9 Dec 2005 21:31:36 -0800 Date: Fri, 9 Dec 2005 21:31:36 -0800 Message-Id: <200512100531.jBA5VaSH007795@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkxKo-0000Ys-Gn 541fdf43e8a22db1818ac3a0be24d831 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 116] OVERWRITE_DELETE_ALL_TOO_STRONG X-Archived-At: http://www.w3.org/mid/200512100531.jBA5VaSH007795@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10970 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:32:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=116 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:31 ------- This issue was discussed during a teleconference, and the consensus there was the existing semantics in RFC 2518 are what is intended. Additional language has been added to the specification, as noted by Julian, explicitly stating that this is the desired behavior, and noting that clients can explicitly perform a merge if they want. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:39:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxS5-00044F-D1 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:39:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15301 for ; Sat, 10 Dec 2005 00:38:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxRD-0005vp-6E for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:38:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxRB-0005v2-Fo for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:38:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkxQe-0003XV-C1 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:38:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5bp3R007818; Fri, 9 Dec 2005 21:37:51 -0800 Date: Fri, 9 Dec 2005 21:37:51 -0800 Message-Id: <200512100537.jBA5bp3R007818@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkxQe-0003XV-C1 1b40e54095a819b4918e0a3450c087c1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 129] LOCK_BODY_SHOULD_BE_MUST X-Archived-At: http://www.w3.org/mid/200512100537.jBA5bp3R007818@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10971 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:38:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=129 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:37 ------- I reviewed the -08 specification. Section 8.11 states: Lock method requests to create a new lock MUST have a XML request body which contains an owner XML element and other information for this lock request. Section 8.11.1 states: A lock is refreshed by sending a LOCK request without a request body to the URL of a resource within the scope of the lock. This addresses the issue by clarifying the difference in behavior between a new lock creation and a lock refresh. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:41:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxTg-0004dx-1P for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:41:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15379 for ; Sat, 10 Dec 2005 00:40:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxT2-0006Wo-4m for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:40:20 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxT0-0006WB-FA for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:40:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkxST-0004Rm-S8 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:40:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5diAK007839; Fri, 9 Dec 2005 21:39:44 -0800 Date: Fri, 9 Dec 2005 21:39:44 -0800 Message-Id: <200512100539.jBA5diAK007839@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkxST-0004Rm-S8 0c894610bf12721e671703fb5ad3a850 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 149] NEW_MULTIPUT_METHOD X-Archived-At: http://www.w3.org/mid/200512100539.jBA5diAK007839@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10972 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:40:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=149 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:39 ------- Agree there is no consensus surrounding the addition of a MULTIPUT method in RFC2518bis (though I still think this is a fine idea for a follow-on specification). Closing the issue *snif* :-) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:43:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxVn-0005Vy-Ke for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:43:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15521 for ; Sat, 10 Dec 2005 00:42:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxVE-0006lz-4W for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:42:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxVC-0006lQ-H2 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:42:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkxV3-0005GR-Ut for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:42:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5gOCJ007864; Fri, 9 Dec 2005 21:42:24 -0800 Date: Fri, 9 Dec 2005 21:42:24 -0800 Message-Id: <200512100542.jBA5gOCJ007864@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkxV3-0005GR-Ut f08ce621b4f830d9b8a77623c35c9be4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 169] Date header required? X-Archived-At: http://www.w3.org/mid/200512100542.jBA5gOCJ007864@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10973 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:42:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=169 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:42 ------- Reassigning to Lisa to make this minor change to the Changes section. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:47:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxaM-0007mn-Mf for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:47:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15804 for ; Sat, 10 Dec 2005 00:46:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxZd-0003Aq-52 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:47:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxZb-0003AC-N0 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:47:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkxZT-0002zo-9g for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:47:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5kxCW007885; Fri, 9 Dec 2005 21:46:59 -0800 Date: Fri, 9 Dec 2005 21:46:59 -0800 Message-Id: <200512100546.jBA5kxCW007885@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkxZT-0002zo-9g fb04d5e626f0226a0b2d1d1a610727ff X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 140] UNLOCK_NEEDS_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512100546.jBA5kxCW007885@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10974 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:47:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=140 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:46 ------- This appears to be the same as issue #60 (If header evaluation when?) A resolution to this issue was suggested earlier today. Specifically, Lock-Token is used to submit the lock token with UNLOCK, If headers should be evaluated as condition headers if present, and a note was made that this is, in fact, inconsistent with other places in the specification. *** This bug has been marked as a duplicate of 60 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 00:48:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxan-0007oZ-L5 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:48:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15821 for ; Sat, 10 Dec 2005 00:47:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekxa7-0003IA-TQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 05:47:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekxa6-0003Hc-7z for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 05:47:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkxZU-0007rS-0X for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 05:47:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA5kx6k007903; Fri, 9 Dec 2005 21:46:59 -0800 Date: Fri, 9 Dec 2005 21:46:59 -0800 Message-Id: <200512100546.jBA5kx6k007903@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkxZU-0007rS-0X 832bb5c1145695b3eb01e22b26461907 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 60] If header evaluation when? X-Archived-At: http://www.w3.org/mid/200512100546.jBA5kx6k007903@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10975 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 05:47:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=60 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 21:46 ------- *** Bug 140 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:02:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxo3-0004U3-IO for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:02:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16666 for ; Sat, 10 Dec 2005 01:01:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxnK-0006ih-B3 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:01:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxnF-0006i8-CB for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:01:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ekxn7-00042l-9k for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:01:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA613tw007946; Fri, 9 Dec 2005 22:01:03 -0800 Date: Fri, 9 Dec 2005 22:01:03 -0800 Message-Id: <200512100601.jBA613tw007946@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ekxn7-00042l-9k 8d26b57ce51e0b6bf374f2a5421380ad X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512100601.jBA613tw007946@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10976 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:01:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:01 ------- I think we need to have some discussion concerning the current text in Section 8.9.4 (in the most recent draft). It suggests that clients can perform merge-like semantics for collection copies, if desired. I believe this is a change from 2518, and I just want to make sure this is what we desire. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:03:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkxpK-0004v0-GI for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:03:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16753 for ; Sat, 10 Dec 2005 01:02:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekxod-0006wN-Jg for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:02:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekxob-0006vD-Re for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:02:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkxoT-0004X7-TJ for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:02:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA62Tab007966; Fri, 9 Dec 2005 22:02:29 -0800 Date: Fri, 9 Dec 2005 22:02:29 -0800 Message-Id: <200512100602.jBA62Tab007966@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkxoT-0004X7-TJ 99818eccd3a8b4a74bb0f69c7a1d4062 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 150] SOURCE_PROPERTY_UNDERSPECIFIED X-Archived-At: http://www.w3.org/mid/200512100602.jBA62Tab007966@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10977 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:02:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=150 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:02 ------- This property has been removed, due to lack of implementation. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:09:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxv5-0006ry-5l for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:09:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17310 for ; Sat, 10 Dec 2005 01:08:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxuO-0007m6-6a for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:08:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkxuM-0007lT-IB for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:08:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkxuB-0006wg-6y for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:08:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA68AJZ007993; Fri, 9 Dec 2005 22:08:10 -0800 Date: Fri, 9 Dec 2005 22:08:10 -0800 Message-Id: <200512100608.jBA68AJZ007993@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkxuB-0006wg-6y a983d69e8647836370f76cba7a209fa8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512100608.jBA68AJZ007993@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10978 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:08:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:08 ------- Section 14.2 of the most recent specification addresses some, but not all of the suggestions. * work like a dead property There is no language: * deprecating current live property behavior * explicitly stating that the property is defined on the resource, and hence has the same value independent of URL used to retrieve it Assigning to Lisa to add language covering these two points. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:13:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxz0-00008l-V2 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:13:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17531 for ; Sat, 10 Dec 2005 01:12:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxyG-0008U6-1z for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:12:36 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxyE-0008TB-F3 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:12:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekxxd-0001Mn-Az for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:12:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6Btdc008012; Fri, 9 Dec 2005 22:11:55 -0800 Date: Fri, 9 Dec 2005 22:11:55 -0800 Message-Id: <200512100611.jBA6Btdc008012@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekxxd-0001Mn-Az 8494940b330bca0c5269a5604bb7af65 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 101] Extensibility for dav:owner X-Archived-At: http://www.w3.org/mid/200512100611.jBA6Btdc008012@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10979 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:12:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=101 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:11 ------- Agree that first sentence "MAY be extended with ..." is redundant with XML DTD ANY declaration. The use of RECOMMENDED for href seems harmless, though I'd be interested in hearing other input on this. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:14:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxzl-0000eY-3e for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:14:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17615 for ; Sat, 10 Dec 2005 01:13:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkxzC-0000C6-Fd for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:13:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EkxzA-0000BV-Ri for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:13:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekxyc-0001p8-QE for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:13:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6Cwgr008034; Fri, 9 Dec 2005 22:12:58 -0800 Date: Fri, 9 Dec 2005 22:12:58 -0800 Message-Id: <200512100612.jBA6Cwgr008034@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekxyc-0001p8-QE 505c906eb5ec674ec725f8a714b5d345 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200512100612.jBA6Cwgr008034@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10980 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:13:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:12 ------- Waiting for suggested text from Julian. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:15:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky0x-00016T-E7 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:15:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17683 for ; Sat, 10 Dec 2005 01:14:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky0L-0000P7-RH for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:14:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky0K-0000OY-EB for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:14:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eky00-00067D-5B for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:14:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6EMKk008060; Fri, 9 Dec 2005 22:14:22 -0800 Date: Fri, 9 Dec 2005 22:14:22 -0800 Message-Id: <200512100614.jBA6EMKk008060@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eky00-00067D-5B 553891c529a726cb5c3010be163d5d66 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512100614.jBA6EMKk008060@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10981 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:14:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:14 ------- Agree this is a mystery. Assigning to Lisa to add a discussion of rationale in Bugzilla, to move the discussion along. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:16:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky2P-0001Pr-8U for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:16:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17741 for ; Sat, 10 Dec 2005 01:15:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky1f-00024c-OV for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:16:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky1W-00023Z-Hx for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:15:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eky1P-0006pt-8V for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:15:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6Fo3W008084; Fri, 9 Dec 2005 22:15:50 -0800 Date: Fri, 9 Dec 2005 22:15:50 -0800 Message-Id: <200512100615.jBA6Fo3W008084@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eky1P-0006pt-8V db93ffaec01e7d99e8707b91539edd1a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 110] COMPLIANCE_RESOURCE X-Archived-At: http://www.w3.org/mid/200512100615.jBA6Fo3W008084@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10982 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:16:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=110 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:15 ------- Assigning to Lisa to search for and remove references to server compatibility. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky39-0001dE-8d for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:17:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17767 for ; Sat, 10 Dec 2005 01:16:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky2S-0002Hs-Co for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:16:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky2Q-0002HG-T7 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:16:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eky2I-0007KP-IG for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:16:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6Gj0K008118; Fri, 9 Dec 2005 22:16:45 -0800 Date: Fri, 9 Dec 2005 22:16:45 -0800 Message-Id: <200512100616.jBA6Gj0K008118@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eky2I-0007KP-IG 66806e9b2d5462cdd71f8dde467cbc77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200512100616.jBA6Gj0K008118@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10983 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:16:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |110 nThis| | ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:17:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky3O-0001eL-5z for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:17:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17771 for ; Sat, 10 Dec 2005 01:16:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky2h-0002Nn-GH for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:17:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky2b-0002Mz-M5 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:17:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eky2R-0002Kg-5v for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:17:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6Gisq008104; Fri, 9 Dec 2005 22:16:44 -0800 Date: Fri, 9 Dec 2005 22:16:44 -0800 Message-Id: <200512100616.jBA6Gisq008104@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eky2R-0002Kg-5v 9c847b749e302fb1c4941f0205f72aa7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 110] COMPLIANCE_RESOURCE X-Archived-At: http://www.w3.org/mid/200512100616.jBA6Gisq008104@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10984 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:17:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=110 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |44 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:16 ------- This issue is related to the OPTIONS * issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:21:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky6h-0003B5-Nj for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:21:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18228 for ; Sat, 10 Dec 2005 01:20:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky64-0003E7-DQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:20:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Eky62-0003Cn-HU for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:20:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Eky3x-0004H7-VN for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:20:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6IR81008140; Fri, 9 Dec 2005 22:18:27 -0800 Date: Fri, 9 Dec 2005 22:18:27 -0800 Message-Id: <200512100618.jBA6IR81008140@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Eky3x-0004H7-VN 0265b49fd2bd90b5218aca7dfc066eb3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 126] EXTEND_UNDEFINED X-Archived-At: http://www.w3.org/mid/200512100618.jBA6IR81008140@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10985 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:20:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=126 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:18 ------- Section 9.1 now defines the extend production. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:22:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky8J-00047W-P3 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:22:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18388 for ; Sat, 10 Dec 2005 01:22:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky7i-0003c0-Pi for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:22:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky7Y-0003Yt-Du for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:22:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eky7Q-00010i-EK for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:22:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6M1eB008169; Fri, 9 Dec 2005 22:22:01 -0800 Date: Fri, 9 Dec 2005 22:22:01 -0800 Message-Id: <200512100622.jBA6M1eB008169@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eky7Q-00010i-EK 4b2c1896b9d5c943a921824a61e20667 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 153] CAN_HREF_BE_RELATIVE X-Archived-At: http://www.w3.org/mid/200512100622.jBA6M1eB008169@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10987 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:22:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=153 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:21 ------- Issues concerning relative URI handling within hrefs in Multistatus responses have been addressed as part of issue #46. Closing this issue, since it's a dup. *** This bug has been marked as a duplicate of 46 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:23:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eky8J-00047X-Te for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:22:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18387 for ; Sat, 10 Dec 2005 01:22:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eky7Z-0003Zb-Fj for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:22:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eky7X-0003Y3-BB for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:22:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eky7P-000119-QE for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:22:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6M2Hc008187; Fri, 9 Dec 2005 22:22:02 -0800 Date: Fri, 9 Dec 2005 22:22:02 -0800 Message-Id: <200512100622.jBA6M2Hc008187@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eky7P-000119-QE 32ef063985975f49d517d3e7e1b187a4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 46] URLs in Multistatus X-Archived-At: http://www.w3.org/mid/200512100622.jBA6M2Hc008187@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10986 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:22:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:22 ------- *** Bug 153 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:29:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyEe-0006Qe-AS for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:29:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18910 for ; Sat, 10 Dec 2005 01:28:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyDk-0004kv-Bd for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:28:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyDZ-0004jp-Dw for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:28:25 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyDX-0006nf-Hk for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:28:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkyAD-0006q6-8J for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:28:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6OufZ008212; Fri, 9 Dec 2005 22:24:56 -0800 Date: Fri, 9 Dec 2005 22:24:56 -0800 Message-Id: <200512100624.jBA6OufZ008212@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkyAD-0006q6-8J 5fc5796d588aed60485458a68beab3f9 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512100624.jBA6OufZ008212@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10988 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:28:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:24 ------- The following language has been added to the specification to address this issue, in section 8.11.1: Note that in RFC2518, clients were indicated through the example in the text to use the If header to specify what lock to refresh (rather than the Lock-Token header). Servers are encouraged to continue to support this as well as the Lock-Token header. Assigning to Julian to review this, to ensure these are the correct semantics. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:32:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyH9-0007Cf-TR for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:32:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19118 for ; Sat, 10 Dec 2005 01:31:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyGY-0006el-9t for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:31:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyGW-0006eD-Jb for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:31:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyGM-0007ha-Rv for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:31:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6VFFo008259; Fri, 9 Dec 2005 22:31:15 -0800 Date: Fri, 9 Dec 2005 22:31:15 -0800 Message-Id: <200512100631.jBA6VFFo008259@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkyGM-0007ha-Rv dd192406cb51d51c27fa33af14518411 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 137] OPTIONS_RESPONSE_VARIES_FOR_RESOURCES X-Archived-At: http://www.w3.org/mid/200512100631.jBA6VFFo008259@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10989 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:31:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=137 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:31 ------- Agreed. OPTIONS responses vary by resource, and this is stated in RFC 2616. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyIV-0007Ps-Kj for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:33:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19231 for ; Sat, 10 Dec 2005 01:32:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyHv-0006rG-Sx for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:32:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyHt-0006qT-TX for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:32:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyHs-00089P-Ky for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:32:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkyFF-0000Qa-0e for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:32:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6U8Or008239; Fri, 9 Dec 2005 22:30:08 -0800 Date: Fri, 9 Dec 2005 22:30:08 -0800 Message-Id: <200512100630.jBA6U8Or008239@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkyFF-0000Qa-0e 8e332c71f907b8005a5374326228cdd8 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 164] HOW_DOES_WEBDAV_SUPPORT_VARIANTS X-Archived-At: http://www.w3.org/mid/200512100630.jBA6U8Or008239@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10990 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:32:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=164 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:30 ------- Addressing how to author variants within WebDAV is a large issue. It was discussed during one of the DeltaV design team meetings, as well as during some WebDAV design team meetings. It would require substantial additional text, thought, and discussion to address this issue well. There is no consensus on performing this work at this time. Additionally, I'll note that use of variants within HTTP is not widespread, and hence authoring support has not been a widely requested feature by users. I'm marking this as closed (WONTFIX). Anyone who feels strongly about this can reopen the issue. However, they should bring this up with the WG Chair (Cullen), since it would likely need a new WG activity to substantively address this issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyJ9-0007lU-7N for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:34:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19326 for ; Sat, 10 Dec 2005 01:33:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyIO-000709-Do for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:33:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyIM-0006z4-NB for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:33:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyID-0008Eh-Rb for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:33:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6X6MP008295; Fri, 9 Dec 2005 22:33:06 -0800 Date: Fri, 9 Dec 2005 22:33:06 -0800 Message-Id: <200512100633.jBA6X6MP008295@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkyID-0008Eh-Rb f13a5eaf4ef200efe0e72aea227e2621 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512100633.jBA6X6MP008295@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10991 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:33:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:33 ------- *** Bug 165 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:36:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyLW-0001Dp-UB for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:36:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19496 for ; Sat, 10 Dec 2005 01:35:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyKt-0007gs-Qr for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:35:59 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyKs-0007gF-7P for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:35:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyKj-0000cv-8y for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:35:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6ZlN5008324; Fri, 9 Dec 2005 22:35:47 -0800 Date: Fri, 9 Dec 2005 22:35:47 -0800 Message-Id: <200512100635.jBA6ZlN5008324@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EkyKj-0000cv-8y 29dfc56593078df61b6596171a24c289 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 135] RESOURCETYPE_EXTENSION X-Archived-At: http://www.w3.org/mid/200512100635.jBA6ZlN5008324@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10992 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:35:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=135 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:35 ------- Section 14.9 addresses this issue. Closing. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:41:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyPz-0002gV-9R for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:41:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19785 for ; Sat, 10 Dec 2005 01:40:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyPN-0000Nw-Ds for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:40:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyPL-0000Lp-4r for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:40:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkyPD-0007jT-T7 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:40:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6eRYP008361; Fri, 9 Dec 2005 22:40:27 -0800 Date: Fri, 9 Dec 2005 22:40:27 -0800 Message-Id: <200512100640.jBA6eRYP008361@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkyPD-0007jT-T7 3c893848b247bf32fc6f8172737b6466 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 15] DAV:error description inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512100640.jBA6eRYP008361@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10993 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:40:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |181 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyQx-0002mQ-0A for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:42:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19815 for ; Sat, 10 Dec 2005 01:41:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyQ8-0000Z4-6Y for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:41:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyNn-0007yu-Ae for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:38:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkyI6-0004uu-Us for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:33:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6X55d008281; Fri, 9 Dec 2005 22:33:05 -0800 Date: Fri, 9 Dec 2005 22:33:05 -0800 Message-Id: <200512100633.jBA6X55d008281@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkyI6-0004uu-Us 4dcc2fb9695299b40e2097472f4ecc94 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 165] DAV_ERROR_SUPPORT X-Archived-At: http://www.w3.org/mid/200512100633.jBA6X55d008281@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10994 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:41:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=165 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:33 ------- This issue is being substantively addressed as part of issue #15. No point in keeping this issue open. Closing this issue, marking it as a dup of #15. *** This bug has been marked as a duplicate of 15 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:45:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyTy-0004EU-Jv for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:45:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20078 for ; Sat, 10 Dec 2005 01:44:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyTP-0000zr-Vc for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:44:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyTO-0000zC-HG for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:44:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkyTH-0000hh-AZ for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:44:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6idBc008397; Fri, 9 Dec 2005 22:44:39 -0800 Date: Fri, 9 Dec 2005 22:44:39 -0800 Message-Id: <200512100644.jBA6idBc008397@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkyTH-0000hh-AZ f8264490c118b584f22d8b3aa3cd6bf7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512100644.jBA6idBc008397@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10995 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:44:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:44 ------- Either the specification should just add some clarification text, or it should forbid this behavior. There doesn't seem to be substantial harm in redirecting a MKCOL request, so my inclination is to add clarification text. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:47:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkyWF-0005HP-Az for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:47:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20253 for ; Sat, 10 Dec 2005 01:46:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkyVW-0002aj-Lw for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:46:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EkyVR-0002ZM-FA for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:46:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EkyVJ-0001LY-8A for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:46:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6kirM008421; Fri, 9 Dec 2005 22:46:44 -0800 Date: Fri, 9 Dec 2005 22:46:44 -0800 Message-Id: <200512100646.jBA6kirM008421@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EkyVJ-0001LY-8A 417010aa3a3a21570be8e937de27c23a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 170] no mention of 424 in section 8.3.2 X-Archived-At: http://www.w3.org/mid/200512100646.jBA6kirM008421@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10996 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:46:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=170 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:46 ------- I verified that this change has been made. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 01:55:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekye6-00083o-N9 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 01:55:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20839 for ; Sat, 10 Dec 2005 01:54:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EkydS-0004H4-IT for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 06:55:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekyd2-0003hV-Qu for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:54:45 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyQp-0002ZF-0O for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:42:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkyPD-0003uE-2L for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:42:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6eQmx008347; Fri, 9 Dec 2005 22:40:26 -0800 Date: Fri, 9 Dec 2005 22:40:26 -0800 Message-Id: <200512100640.jBA6eQmx008347@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkyPD-0003uE-2L 670d148eace2874c1e11cc8982a96401 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512100640.jBA6eQmx008347@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10997 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 06:55:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |15 AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Bug 181 depends on bug 15, which changed state. Bug 15 Summary: DAV:error description inconsistent with RFC3253 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=15 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Status|ASSIGNED |NEW Status|NEW |ASSIGNED Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:40 ------- This appears to be a duplicate of issue #15. Assigning to Julian to see if his concerns have been addressed in the resolution to issue #15. I believe that if issue #15 has been closed, this issue can be closed as well. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 02:05:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekyna-0002zW-3Y for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 02:05:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21916 for ; Sat, 10 Dec 2005 02:04:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekymm-0007dq-7J for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 07:04:48 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Ekymh-0007aj-6m for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 07:04:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ekym8-0003v3-Is for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 07:04:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA7450U008506; Fri, 9 Dec 2005 23:04:05 -0800 Date: Fri, 9 Dec 2005 23:04:05 -0800 Message-Id: <200512100704.jBA7450U008506@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ekym8-0003v3-Is 62a5ae3c8b497f83894cae59bed92780 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 166] XML_GUIDELINES_CONFORMANCE X-Archived-At: http://www.w3.org/mid/200512100704.jBA7450U008506@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10998 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 07:04:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=166 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 23:04 ------- 'Guidelines for the use of XML within IETF Protocols' has been approved as RFC 3470 (BCP 70). While the audience for RFC 3470 is protocol designers, and is intended to get them up to speed on use of XML issues, there are a few issues raised that might be useful to address in bis: * ignore processing instructions that appear in XML request/response bodies * not allowing entity declarations (should we not allow any DTD language in request/response bodies at all?) Assigning to Julian to review RFC 3470 for any other considerations we may want to put in bis. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 02:05:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekynl-00030O-9q for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 02:05:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21930 for ; Sat, 10 Dec 2005 02:04:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekyn2-0008G2-PG for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 07:05:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekyck-0003a7-Gp for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:54:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by maggie.w3.org with esmtp (Exim 4.50) id 1EkyaN-0005ZD-EA for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 06:51:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EkyaA-0008A0-Cu for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 06:51:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA6pjKq008459; Fri, 9 Dec 2005 22:51:45 -0800 Date: Fri, 9 Dec 2005 22:51:45 -0800 Message-Id: <200512100651.jBA6pjKq008459@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EkyaA-0008A0-Cu ab4c33c1748999df99a3f964746e3789 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 148] SECTION_12_4_MENTIONS_HREF_ELEMENT X-Archived-At: http://www.w3.org/mid/200512100651.jBA6pjKq008459@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/10999 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 07:05:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=148 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 22:51 ------- Agree issue can be closed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 02:08:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekyqh-0004V0-BN for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 02:08:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22101 for ; Sat, 10 Dec 2005 02:07:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ekypx-0000P1-9M for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 07:08:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ekypv-0000Ny-IM for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 07:08:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ekypo-00082B-GW for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 07:08:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBA77tB5008538; Fri, 9 Dec 2005 23:07:55 -0800 Date: Fri, 9 Dec 2005 23:07:55 -0800 Message-Id: <200512100707.jBA77tB5008538@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ekypo-00082B-GW 70fe1a28aabfc81f8f0690f8bf4adfdb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 145] LOCKDISCOVERY_ON_UNLOCKED_RESOURCE X-Archived-At: http://www.w3.org/mid/200512100707.jBA77tB5008538@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11000 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 07:08:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-09 23:07 ------- Do we need to add any text to the specification for this issue? Seems like we don't. Assigning to Julian for his opinion. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 05:54:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El2N1-0004WE-AB for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 05:54:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11087 for ; Sat, 10 Dec 2005 05:53:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El2LB-0002Gn-Jq for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 10:52:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1El2L2-0002D1-Eq for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 10:52:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1El2Kd-0006A6-8h for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 10:52:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAApuLI008667; Sat, 10 Dec 2005 02:51:56 -0800 Date: Sat, 10 Dec 2005 02:51:56 -0800 Message-Id: <200512101051.jBAApuLI008667@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1El2Kd-0006A6-8h 7a2043175a61ee6f8b4b381bff12c04a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200512101051.jBAApuLI008667@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11001 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 10:52:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 02:51 ------- One of the main points in moving to application/xml ist that you don't need the charset parameter, so it never can be in conflict with the body. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 06:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El3Jz-0001Ag-2b for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 06:55:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16432 for ; Sat, 10 Dec 2005 06:54:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El3Ip-0000t7-DF for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 11:54:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1El3Ig-0000sE-TQ for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 11:54:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1El3IU-0001Oy-Sj for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 11:54:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBABrXfg008717; Sat, 10 Dec 2005 03:53:33 -0800 Date: Sat, 10 Dec 2005 03:53:33 -0800 Message-Id: <200512101153.jBABrXfg008717@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1El3IU-0001Oy-Sj 58c07583edb433bfcd5eeecb9874bbf4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512101153.jBABrXfg008717@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11002 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 11:54:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 03:53 ------- This now reads: Description: This XML element provides either information suitable to be presented to a user (PCDATA) or a machine readable error code. This is incorrect; it can contain both. This follows from the XML extensibility rules of RFC2518. If we want to change this text, we can change the grammar accordingly, and tell clients how to extract both description text and condition codes (I volunteer to describe this if people want it). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 09:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El5jD-00053h-9n for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 09:29:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00250 for ; Sat, 10 Dec 2005 09:28:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El5hz-0006yQ-4X for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 14:28:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1El5hq-0006xZ-Fc for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 14:28:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1El5hh-000351-0J for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 14:28:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAERCvu009012; Sat, 10 Dec 2005 06:27:12 -0800 Date: Sat, 10 Dec 2005 06:27:12 -0800 Message-Id: <200512101427.jBAERCvu009012@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1El5hh-000351-0J f1f3f78f762d711800de8006d519fa0a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 205] New: new MUST level requirement for LOCK on unmapped URLs X-Archived-At: http://www.w3.org/mid/200512101427.jBAERCvu009012@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11003 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 14:28:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=205 Summary: new MUST level requirement for LOCK on unmapped URLs Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 07. Write Lock AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org The pre-draft of -09 states in section 7.6: A successful lock request to an unmapped URL MUST result in the creation of an locked resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource, and the server MUST also use the content- type and content-language information from this request. This is a new MUST-level requirement that as far as I understand hasn't been discussed anywhere before, and which contradicts an upcoming TAG finding () - that is, we can't *require* the server to use the submitted meta data. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 10:05:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El6IN-0001AD-G0 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:05:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03888 for ; Sat, 10 Dec 2005 10:05:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El6HZ-00071P-RQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 15:05:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1El6HQ-0006ca-VR for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 15:04:56 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1El6HF-0002as-Od for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 15:04:56 +0000 Received: (qmail invoked by alias); 10 Dec 2005 15:04:42 -0000 Received: from p508F8A87.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.138.135] by mail.gmx.net (mp027) with SMTP; 10 Dec 2005 16:04:42 +0100 X-Authenticated: #1915285 Message-ID: <439AEE34.2050604@gmx.de> Date: Sat, 10 Dec 2005 16:03:16 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV References: <4399DC7A.60209@gmx.de> <439A092F.6090806@cse.ucsc.edu> In-Reply-To: <439A092F.6090806@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1El6HF-0002as-Od 2eac593edf0cf049d656de08de57221a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/439AEE34.2050604@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11004 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 15:05:05 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > >> 3. Terminology >> Inconsistent typography (":" vs "-") > > Fixed. Thanks. >> "A URI mapping can be thought of as a URL pointing to a resource." >> I'm not sure what this is supposed to mean. Please remove it or clarify. > > Removed. Thanks. >> 7.6 Write Locks and Unmapped URLs >> >> A successful lock request to an unmapped URL MUST result in the >> creation of an locked resource with empty content. Subsequently, a >> successful PUT request (with the correct lock token) provides the >> content for the resource, and the server MUST also use the content- >> type and content-language information from this request. >> >> Making this a MUST creates a conflict with an upcoming TAG finding by >> Roy Fielding. > > Discussion needed; created new bugzilla issue. Done: >> 8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and >> RFC2518 Properties >> >> Nits: >> - move it back where it was in RFC2518 >> - avoid the term RFC2158 properties in the title > > Renamed; brief explanatory note added. It would be nice if it also could be moved back to where it was in RFC2518 in order to avoid needless diffs. >> - XML in example to be fixed, for instance whitespace in >> D:getlastmodified > > Fixed the example. However, since DAV:get* properties are based upon > definitions made in rfc2616, LWS may be found in some implementations -- > explanatory text added to section 14. a) the date doesn't use rfc1123 syntax b) I object to that change, LWS is not part of the value of the header, that is whitespace is not allowed here (any evidence of a server adding this???). Do I need to open an issue for that? >> - intra-doc reference to Section 13 is incorrect > > Fixed. Thanks. >> 8.3.1 [...] (2nd sentence) Again, this is correct, but >> a) doesn't really need to be mentioned, >> b) but if is mentioned, then using MUST is incorrect here. [...] > > 2nd sentence left in, with MUST removed. Thanks. >> 8.7 DELETE [...] This is still a lame way to introduce DELETE. [...] > > >> 8.9.5 Status Codes [...] 403 (Forbidden) [...] Confusing. Servers may >> treat this as a nop, just returning 200. Just be silent about it. > > Discussed this but left the text in, as the semantics were defined in > 2518 (see similar comment below). Well, it was mentioned, but the spec never contained a requirement for servers to reject this. >> 8.10.4 Status Codes >> 204 (No Content) - [...] Sentence broken [...] > > Rewrote text to clarify 204 and 201. Thanks. >> 403 (Forbidden) [...] And being source and destination identical >> would be a problem exactly why? > > Semantics defined in 2518, left alone as a change could compromise > resource identity (e.g. creation date may change, corruption of version > history, etc.). I don't buy that rational, because that would just mean that the server did what the client told him to do. In particular, the version history would not be corrupted nor removed (see RFC3253 COPY semantics). >> 12.1 Response headers [...] This section doesn't provide any useful >> information. In particular, the second sentence seems to be completely >> out of context. > > Rewrote this section (originally added following discussion of issue > 47). Second sentence has been removed. It now says: HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g. in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined. I still don't understand this. How does the presence of a Location header create an ambiguity here? The URLs in the response mean exactly what this spec defines them to mean, and there is absolutely no ambiguity here. I'd also like to point out that we've been wasting an incredible amount of time undoing a change that was meant to talk about the "Content-Location" header, not "Location". As far as I can tell, nobody has asked questions about "Location" until I asked why it was put in without prior discussion, and I fail to see how this addition makes this a better spec. Please remove it. >> 12.2 URL handling [...] > > Rewrote most of this section, incorporating some of your proposed text, > and paying attention to RFC3986 language -- please review. Now says: 12.2 URL Handling A Multi-Status body contains one or more 'response' elements. Each Zero or more. response element describes a resource, and has an 'href' element identifying the resource. The 'href' element MUST contain an absolute URI or relative reference. It MUST NOT include "." or ".." as path elements. It would be helpful if this would refer to the sections of RFC3986 defining this terms. In particular, I fail to see why we are now restricted to "absolute-URI" instead of "URI". Also note that "URI-reference" means "URI / relative-ref", so we could use just that. If a 'href' element contains a relative reference, it MUST be resolved against the Request-URI. A relative reference MUST be an absolute path (note that clients are not known to support relative paths). Again, a reference to the right places in RFC3986 grammar seems to be useful. Identifiers for collections appearing in the results SHOULD end in a '/' character. If a server allows resource names to include characters that aren't legal in HTTP URL paths, these characters must be percent-encoded on Why restrict to HTTP URL? the wire (see [RFC3986], section 2.1). For example, it is illegal to use a space character or double-quote in a URI. URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters. The last sentence doesn't seem to be useful; what we're saying here applies to all uses of multistatus bodies, including error responses, or extensions (REPORT...). >> 12.3 Handling redirected child resources [...] Sounds like "We don't >> care what servers do". > > After some discussion, we now care and have rewritten the last sentence. Great. It now says: 12.3 Handling redirected child resources Redirect responses (300-303, 305 and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in RFC2518 did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 13.9). Servers MUST use this new element with redirect responses in Multi-Status. I think the last two sentences belong into the Changes appendix, not here. >> 19.7 Risks Connected with Lock Tokens [...] > > Proposed text inserted with a couple of tweaks (title of RFC, version / > variant language, and minor wordsmithing introducing the list). Still :-) 1) Says "Variant x UUID" when it should say "Version x UUID" 2) Misses the statement "Since a WebDAV server will issue many locks over its lifetime, the implication is that it may also be publicly exposing its IEEE 802 address.". Why? >> 22.1 Normative References [...] > > Reference to 2518 moved to informative references. Thanks. I just noted that the XML Infoset reference appears under "informative", but that is indeed normative. But we're still discussing the "property value" proposal, based on what's in BugZilla (), right? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Dec 10 10:45:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El6ug-0004sY-HR for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:45:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07577 for ; Sat, 10 Dec 2005 10:44:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El6tj-0000SM-HE for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 15:44:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1El6tc-0000RF-Iu for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 15:44:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1El6tS-0000AO-IE for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 15:44:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAFhxV1009069; Sat, 10 Dec 2005 07:43:59 -0800 Date: Sat, 10 Dec 2005 07:43:59 -0800 Message-Id: <200512101543.jBAFhxV1009069@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1El6tS-0000AO-IE 0a92285e31f54bfb903c76b80a196878 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200512101543.jBAFhxV1009069@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11005 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 15:44:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 07:43 ------- Incorrect, as stated before multiple times. Please replace by: Value: URI reference (see Section 4.1 of [RFC3986]) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 10:50:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El6zf-0005aX-31 for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:50:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08399 for ; Sat, 10 Dec 2005 10:49:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El6z1-0002fG-NB for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 15:49:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1El6yz-0002ed-8C for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 15:49:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1El6ys-0005zO-F6 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 15:49:57 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAFnnN4009090; Sat, 10 Dec 2005 07:49:49 -0800 Date: Sat, 10 Dec 2005 07:49:49 -0800 Message-Id: <200512101549.jBAFnnN4009090@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1El6ys-0005zO-F6 306ef218b470dc8efc6dd1dc7983532e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512101549.jBAFnnN4009090@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11006 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 15:49:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|ejw@cs.ucsc.edu ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 07:49 ------- The text is ok, but as this is one of the few normative changes to RFC2518, this really HAS to be mentioned in the Changes section. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 10:56:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El75O-0007dP-Oz for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:56:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09187 for ; Sat, 10 Dec 2005 10:55:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El74Z-000470-2Q for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 15:55:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1El74X-00046S-E3 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 15:55:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1El74P-0004id-7h for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 15:55:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAFtLSk009113; Sat, 10 Dec 2005 07:55:21 -0800 Date: Sat, 10 Dec 2005 07:55:21 -0800 Message-Id: <200512101555.jBAFtLSk009113@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1El74P-0004id-7h e846f5087a807777b585fb95f9eaaff8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512101555.jBAFtLSk009113@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11007 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 15:55:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 07:55 ------- How about "State-Token"? Is LWS allowed between the ETag in the brackets? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 10:58:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El76y-0008B0-Vf for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:58:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09289 for ; Sat, 10 Dec 2005 10:57:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El76Q-0004KD-Rr for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 15:57:38 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1El76O-0004JY-SL for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 15:57:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1El74T-0000Le-W7 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 15:57:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAFtZfL009135; Sat, 10 Dec 2005 07:55:35 -0800 Date: Sat, 10 Dec 2005 07:55:35 -0800 Message-Id: <200512101555.jBAFtZfL009135@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1El74T-0000Le-W7 36b3dbcd9225d52a9ec5de3c52d0d987 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512101555.jBAFtZfL009135@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11008 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 15:57:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |ejw@cs.ucsc.edu Status|REOPENED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 11:28:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El7Zx-00009I-EG for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 11:28:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12663 for ; Sat, 10 Dec 2005 11:27:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El7Z1-0003Ql-QN for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 16:27:11 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1El7Yx-0003Q3-R4 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 16:27:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1El7Yo-0005Pk-D1 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 16:27:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAGQt5x009168; Sat, 10 Dec 2005 08:26:55 -0800 Date: Sat, 10 Dec 2005 08:26:55 -0800 Message-Id: <200512101626.jBAGQt5x009168@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1El7Yo-0005Pk-D1 17c76a39ac36f53073a16737dc614f52 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512101626.jBAGQt5x009168@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11009 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 16:27:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 08:26 ------- I'm happy with the changes, except that I still prefer the proposed rewrite for "Purpose": Purpose: HTTP defines the 'Location' response header (see [RFC2616], Section 14.30) for use with some HTTP status codes (such as 201 and the 300 series codes). When these status codes are used inside a 'multistatus' response body, this element can be used to provide the accompanying 'Location' header. (has [RFC2616] with the Section reference, and avoids redefining the value; what if RFC2616bis allows relative references here, for example?) ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 11:28:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El7a5-0000BK-LO for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 11:28:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12670 for ; Sat, 10 Dec 2005 11:27:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El7ZY-0003Wu-63 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 16:27:44 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1El7ZW-0003WK-GS for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 16:27:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1El7ZD-0005du-9V for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 16:27:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAGRMu8009182; Sat, 10 Dec 2005 08:27:22 -0800 Date: Sat, 10 Dec 2005 08:27:22 -0800 Message-Id: <200512101627.jBAGRMu8009182@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1El7ZD-0005du-9V 74cd782bfb685069a5b4fb4b83f7839d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512101627.jBAGRMu8009182@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11010 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 16:27:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|ejw@cs.ucsc.edu ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 11:34:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El7gZ-0001qU-7D for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 11:34:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13139 for ; Sat, 10 Dec 2005 11:34:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El7ft-0005UV-Q6 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 16:34:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1El7fq-0005To-P0 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 16:34:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1El7fi-00039y-44 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 16:34:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAGXqbV009204; Sat, 10 Dec 2005 08:33:52 -0800 Date: Sat, 10 Dec 2005 08:33:52 -0800 Message-Id: <200512101633.jBAGXqbV009204@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1El7fi-00039y-44 392e6415ccfb5c18024608fd137abb3b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512101633.jBAGXqbV009204@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11011 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 16:34:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 08:33 ------- I'm not sure with whom I'm disagreeing here, but anyway..: Should there be use case where a client needs to discover upfront whether the server claims to comply with -bis, I'd agree. Please provide this use case. Furthermore, *if* we keep the new compliance class, it should definitively use a different name, such as "rev2" or "rfcxxxx" (where xxxx is the RFC number we'll get). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 12:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El8pV-0007NC-2L for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 12:48:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20663 for ; Sat, 10 Dec 2005 12:47:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El8oB-0006A8-CV for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 17:46:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1El8o2-00068b-35 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 17:46:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1El8nu-0006Lg-5z for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 17:46:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAHkbGv009269; Sat, 10 Dec 2005 09:46:37 -0800 Date: Sat, 10 Dec 2005 09:46:37 -0800 Message-Id: <200512101746.jBAHkbGv009269@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1El8nu-0006Lg-5z b186cd129770f2845940b06cf4d8850d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 145] LOCKDISCOVERY_ON_UNLOCKED_RESOURCE X-Archived-At: http://www.w3.org/mid/200512101746.jBAHkbGv009269@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11012 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 17:46:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|ejw@cs.ucsc.edu ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 09:46 ------- I think draft 08 is very clear about this (): "The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there is one or more lock, an 'activelock' element appears for each lock on the resource." So I recommend closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 12:54:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El8vX-000096-Bs for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 12:54:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21189 for ; Sat, 10 Dec 2005 12:53:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El8ur-0007PJ-KM for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 17:53:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1El8up-0007Ok-Jv for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 17:53:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1El8ud-0001CM-TO for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 17:53:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAHrY00009288; Sat, 10 Dec 2005 09:53:34 -0800 Date: Sat, 10 Dec 2005 09:53:34 -0800 Message-Id: <200512101753.jBAHrY00009288@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1El8ud-0001CM-TO bb0d0e111506cce4dfdff9726fbb404a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512101753.jBAHrY00009288@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11013 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 17:53:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|ejw@cs.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 09:53 ------- I agree that the new text isn't perfect. Quoting: 8.9.4 COPY and Overwriting Destination Resources If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request. When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). Some considerations: ..."MAY" is incorrect here, because we aren't defining anything here... Also, if we refer to RFC3253, we'd better also state the exact place (here: Section 1.7). When an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties. That's correct. When a collection is overwritten, the source collection membership could completely replace the destination collection membership, or the source collection membership could be combined with the destination collection membership. I don't think this is allowed. The membership should be always the one of the source namespace, unless I'm missing something. In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g. to force live properties to be reset or to force collection membership to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset. That's correct, but only for the first of the two reasons. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 12:58:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El8ze-00016d-Np for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 12:58:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21561 for ; Sat, 10 Dec 2005 12:57:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1El8yu-0008AL-No for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 17:58:00 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1El8yt-00089P-39 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 17:57:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1El8yj-0005X8-U5 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 17:57:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAHvkJm009305; Sat, 10 Dec 2005 09:57:46 -0800 Date: Sat, 10 Dec 2005 09:57:46 -0800 Message-Id: <200512101757.jBAHvkJm009305@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1El8yj-0005X8-U5 7bb527710993ce6dce0b6121efd41dbb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200512101757.jBAHvkJm009305@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11014 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 17:58:00 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 09:57 ------- The current spec says: "If the lock cannot be granted to all resources, the server MUST return a Multi-Status response with a 'response' element for at least one resource which prevented the lock from being granted, along with a suitable status code for that failure (e.g. 403 (Forbidden) or 423 (Locked)). Additionally, if the resource causing the failure was not the resource requested, then the server MUST include a 'response' element for the Request-URI as well, with a 'status' element containing 424 Failed Dependency." That seems to clarify the issue, although I don't see any reason to make returning the 424 a MUST level requirement, as this is basically completely useless information. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 14:35:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElAVf-0003dn-Kv for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 14:35:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29403 for ; Sat, 10 Dec 2005 14:34:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElAUM-0005J5-VU for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 19:34:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ElAUD-0005Ht-Pn for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 19:34:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ElATv-0000tP-To for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 19:34:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAJXovZ009401; Sat, 10 Dec 2005 11:33:50 -0800 Date: Sat, 10 Dec 2005 11:33:50 -0800 Message-Id: <200512101933.jBAJXovZ009401@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ElATv-0000tP-To 526d3a8301a42074b981d712ccab768a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 119] DATE_FORMAT_GETLASTMODIFIED X-Archived-At: http://www.w3.org/mid/200512101933.jBAJXovZ009401@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11015 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 19:34:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=119 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-10 11:33 ------- Ok, added ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 14:44:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElAdZ-0005ts-AV for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 14:44:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00170 for ; Sat, 10 Dec 2005 14:43:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElAcu-0006tN-HB for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 19:43:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElAct-0006so-2g for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 19:43:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElAcl-0006Yp-Ja for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 19:43:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAJhCMc009425; Sat, 10 Dec 2005 11:43:12 -0800 Date: Sat, 10 Dec 2005 11:43:12 -0800 Message-Id: <200512101943.jBAJhCMc009425@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElAcl-0006Yp-Ja fb868d8aedfbbcbdfc8caa1fd328370f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 169] Date header required? X-Archived-At: http://www.w3.org/mid/200512101943.jBAJhCMc009425@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11016 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 19:43:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=169 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-10 11:43 ------- There's still a change from 2518 to 2518bis, although it now is at the level of a reminder rather than any more stringent requirement. I've clarified this in the changes section. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:17:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElB9W-0005zv-MS for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:17:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02613 for ; Sat, 10 Dec 2005 15:16:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElB8c-0005kX-PZ for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:16:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElB8a-0005jz-TQ for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:16:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElB8P-0006Ti-Q5 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:16:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKFsDW009461; Sat, 10 Dec 2005 12:15:54 -0800 Date: Sat, 10 Dec 2005 12:15:54 -0800 Message-Id: <200512102015.jBAKFsDW009461@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElB8P-0006Ti-Q5 056a6bd4bea0752cf556640ccb2d5525 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512102015.jBAKFsDW009461@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11017 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:16:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 12:15 ------- I'm in the process of clarifying/rewriting and came across the following issue; feedback appreciated: 1) All elements can be extended with attributes not defined in the spec. 2) All elements defined as "ANY" may not be extended, as the definition already defines the meaning of potential children (such as in ). 3) All elements defined with element content may be extended with child elements not defined in this spec. This leaves... 4) Elements defined as #PCDATA. As far as I understand, the extensibility rules in RFC2518 allow them to be extended with child elements, which recipients will ignore when not understood. There's also a precedent in RFC3253, where is allowed to travel inside . I don't have any strong feelings about this; our implementation definitively handles this correctly. However there's certainly reasonable doubt that this applies to all implementations, so should we forbid this (as currently in RFC2518bis), and just special-case DAV:responsedescription? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:19:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElBCJ-0006lH-Ku for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:19:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02816 for ; Sat, 10 Dec 2005 15:18:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElBBd-00061G-B8 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:19:17 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElBBZ-00060c-0V for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:19:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElBBL-0007pE-SO for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:19:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKIxDJ009480; Sat, 10 Dec 2005 12:18:59 -0800 Date: Sat, 10 Dec 2005 12:18:59 -0800 Message-Id: <200512102018.jBAKIxDJ009480@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElBBL-0007pE-SO ddd1e6600505720daca31e78021fd6f2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512102018.jBAKIxDJ009480@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11018 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:19:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-10 12:18 ------- This was added to try to make the spec complete when there were commas in If headers and thus could be multiple instances of the If header. It's not an untrue statement (see ABNF production) but if there's complaints, I'll remove it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:22:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElBEm-0007N0-0O for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:22:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03079 for ; Sat, 10 Dec 2005 15:21:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElBEA-0006fO-DS for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:21:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ElBE8-0006en-Fp for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:21:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ElBDz-00041i-UG for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:21:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKLbEs009501; Sat, 10 Dec 2005 12:21:37 -0800 Date: Sat, 10 Dec 2005 12:21:37 -0800 Message-Id: <200512102021.jBAKLbEs009501@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ElBDz-00041i-UG 4e19ec3823cab042c6029ad1c91f4815 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 110] COMPLIANCE_RESOURCE X-Archived-At: http://www.w3.org/mid/200512102021.jBAKLbEs009501@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11019 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:21:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=110 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-10 12:21 ------- This was resolved in draft *-02*. If there are any problems, specific instances should be brought to my attention. I believe this is just a case of the issues.htm file not being kept up to date prior to being ported into bugzilla. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:25:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElBHp-0007on-7x for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:25:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03314 for ; Sat, 10 Dec 2005 15:24:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElBHG-0007ER-IK for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:25:06 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElBHE-0007Dq-6A for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:25:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElBGO-0001g5-16 for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:25:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKOBpA009517; Sat, 10 Dec 2005 12:24:11 -0800 Date: Sat, 10 Dec 2005 12:24:11 -0800 Message-Id: <200512102024.jBAKOBpA009517@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElBGO-0001g5-16 056f71d7c25e676e8b3cc2f0219822c1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512102024.jBAKOBpA009517@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11020 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:25:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 12:24 ------- I just compared with the original text, which slightly differs. In particular, a complete paragraph seems to have gone: "When the If header is applied to a particular resource, the Tagged-list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section." Is this a mistake, or am I missing a change we agreed to make? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:29:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElBLu-00016I-Rw for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:29:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03501 for ; Sat, 10 Dec 2005 15:28:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElBLH-0007cu-JO for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:29:15 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElBLF-0007bc-RO for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:29:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElBL0-0000nQ-OI for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:29:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKSu4V009536; Sat, 10 Dec 2005 12:28:56 -0800 Date: Sat, 10 Dec 2005 12:28:56 -0800 Message-Id: <200512102028.jBAKSu4V009536@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElBL0-0000nQ-OI 81c9fff8aa93455644e3179eff9ec38e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512102028.jBAKSu4V009536@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11021 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:29:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From lisa@osafoundation.org 2005-12-10 12:28 ------- I'm afraid I'm unclear on what the consensus or even rationale is here, enough so that I don't know what text to add. Why should MKCOL specifically have 302 response forbidden? - RFC2518 didn't forbid redirects on MKCOL. - RFC2518bis adds text saying that *any* request can be redirected. - Why would 302 be forbidden and not mention other 300-level responses? Is there consensus that we should do anything here? Without knowing what the problem being solved is, I propose we do nothing. Other proposals or reasoning welcome. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 15:34:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElBQE-0001RD-6Y for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 15:34:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03763 for ; Sat, 10 Dec 2005 15:33:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElBPe-00010w-Fh for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 20:33:46 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElBPc-0000zp-R5 for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 20:33:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElBPT-0005iY-FX for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 20:33:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBAKXZ4J009556; Sat, 10 Dec 2005 12:33:35 -0800 Date: Sat, 10 Dec 2005 12:33:35 -0800 Message-Id: <200512102033.jBAKXZ4J009556@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElBPT-0005iY-FX 338a9b6453c245e898310b29d25e75bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512102033.jBAKXZ4J009556@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11022 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 20:33:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 12:33 ------- Any HTTP request can be redirected, so can MKCOL. I don't think we need to state this specially. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 16:37:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElCPA-00014j-Vv for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 16:37:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08631 for ; Sat, 10 Dec 2005 16:36:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElCNm-0005IU-M1 for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 21:35:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElCNh-0005Gf-6k for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 21:35:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElCNM-0006Ga-BL for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 21:35:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBALZQ0R009610; Sat, 10 Dec 2005 13:35:26 -0800 Date: Sat, 10 Dec 2005 13:35:26 -0800 Message-Id: <200512102135.jBALZQ0R009610@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElCNM-0006Ga-BL 8153259dad68a0d07c19affa587d4ecd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512102135.jBALZQ0R009610@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11023 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 21:35:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 13:35 ------- OK, I have convinced myself that extensibility indeed follows from the DTD fragments. If people feel that the individual cases need examples, I'm oipen to that. The extensibility rules stated were almost consistent, although sometimes the "unless recognized" part was missing. The proposed change affects all of section 13 (XML elements), 14 (properties) and some text in section 16 (XML processing). It's probably easier to review the changes in context (see ), but here are the individual changes. Besides removing all "Extensibility" statements: Section 13., para. 1: OLD: In this section, the final line of each section gives the element type declaration using the format defined in [XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). The "Extensibility" field discusses how the element may be extended in the future (or in existing extensions to WebDAV. All of the elements defined here may be extended by the addition of attributes and child elements not defined in this specification. All elements defined here are in the "DAV:" namespace. NEW: In this section, the final line of each section gives the element type declaration using the format defined in [XML]. The "Value" field, where present, specifies further restrictions on the allowable contents of the XML element using BNF (i.e., to further restrict the values of a PCDATA element). Note that all elements can be extended according to the rules defined in Section 16. Section 14., para. 5: OLD: 14.1 creationdate Property NEW: Note that all property elements can be extended according to the rules defined in Section 16. 14.1 creationdate Property Section 14., para. 78: OLD: Description: MUST be defined on all DAV compliant resources. The default value is empty. Extensibility: MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized. If the element contains the 'collection' child element plus additional unrecognized elements/attributes, it should generally be treated as a collection. If the element contains no recognized child elements it should be treated as a non-collection WebDAV-compliant resource. NEW: Description: MUST be defined on all DAV compliant resources. Each child element identifies a specific type the resource belongs to, such as DAV:collection, which is the only resource type defined by this specification (see Section 13.3). The default value is empty. (note here Description was enhanced because it needed some of the info from the Extensibility section) Section 16., para. 1: OLD: All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language. NEW: Recipients MUST ignore unknown XML attributes, unknown XML elements and all of their children while processing a DAV method that uses XML as its command language in a request or response body. Section 16., para. 6: OLD: XML DTD fragments are included for all the XML elements defined in this specification. However, legal XML may not be valid according to any DTD due to namespace usage and extension rules, so the DTD is only informational. A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD. NEW: XML DTD fragments are included for all the XML elements defined in this specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular: o Element names use the "DAV:" namespace, o Element ordering is irrelevant unless otherwise stated, o Extension attributes (attributes not already defined by this specification may be added, and MUST be ignored by recipients unless recognized), o Extension elements (elements not already defined by this specification) may be added for element type definitions other than "ANY" or "#PCDATA", and MUST be ignored by recipients unless recognized). A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 10 16:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElCYF-0003je-SI for webdav-archive@megatron.ietf.org; Sat, 10 Dec 2005 16:46:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09331 for ; Sat, 10 Dec 2005 16:45:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElCXU-0000f5-7G for w3c-dist-auth-dist@listhub.w3.org; Sat, 10 Dec 2005 21:45:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElCXK-0000cs-My for w3c-dist-auth@listhub.w3.org; Sat, 10 Dec 2005 21:45:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElCXD-0006YL-Pc for w3c-dist-auth@w3.org; Sat, 10 Dec 2005 21:45:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBALjdbZ009634; Sat, 10 Dec 2005 13:45:39 -0800 Date: Sat, 10 Dec 2005 13:45:39 -0800 Message-Id: <200512102145.jBALjdbZ009634@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElCXD-0006YL-Pc 0d2eff10a1b75ce3da297d5b088208e7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 72] Review references section X-Archived-At: http://www.w3.org/mid/200512102145.jBALjdbZ009634@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11024 X-Loop: w3c-dist-auth@w3.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, 10 Dec 2005 21:45:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=72 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-10 13:45 ------- Another todo for when we're getting to this: make the reference style for W3C specs consistent, that is either 1) XML, XML-NS and XML-INFOSET, or 2) REC-XML, REC-XML-NS and REC-XML-INFOSET, or 3) REC-xml-20040204, REC-xml-names-19990114 and REC-xml-infoset-20040204, or 4) W3C.REC-xml-20040204, W3C.REC-xml-names-19990114 and W3C.REC-xml-infoset-20040204. For readability, I would choose either 1) or 2). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 11 05:58:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElOuw-000468-Ff for webdav-archive@megatron.ietf.org; Sun, 11 Dec 2005 05:58:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08792 for ; Sun, 11 Dec 2005 05:58:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElOsi-0001v3-TX for w3c-dist-auth-dist@listhub.w3.org; Sun, 11 Dec 2005 10:56:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElOsY-0001uL-J4 for w3c-dist-auth@listhub.w3.org; Sun, 11 Dec 2005 10:56:31 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1ElOsJ-0000b1-OH for w3c-dist-auth@w3.org; Sun, 11 Dec 2005 10:56:29 +0000 Received: (qmail invoked by alias); 11 Dec 2005 10:56:10 -0000 Received: from p508F858E.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.133.142] by mail.gmx.net (mp019) with SMTP; 11 Dec 2005 11:56:10 +0100 X-Authenticated: #1915285 Message-ID: <439C057E.5000608@gmx.de> Date: Sun, 11 Dec 2005 11:54:54 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV References: <200511301916.jAUJGmM5016299@ietf.cse.ucsc.edu> In-Reply-To: <200511301916.jAUJGmM5016299@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElOsJ-0000b1-OH ddbf206d66fa7e0535e24f1d66d5f238 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/439C057E.5000608@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11025 X-Loop: w3c-dist-auth@w3.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, 11 Dec 2005 10:56:40 +0000 Content-Transfer-Encoding: 7bit Hi, before going to work on this issue, I just re-read the summary I wrote some months ago. I think it contains a correct analysis of the situation, thus I will use it as a basis for the changes. People interested in this issue may want to re-read the HTML version at , or the TXT version below. Feedback appreciated, Julian ---------------- Behaviour of WebDAV properties under namespace operations Abstract This document discusses the impact of WebDAV namespace operations on the behaviour of live properties defined in HTTP and WebDAV. 1. Detecting changes in HTTP HTTP ([RFC2616]) defines a set of response header fields that can be used to detect changes, namely "ETag" (Section 14.19) and "Last- Modified" (Section 14.29). User agents can use request header fields to make method invocations conditional, such as o "If-Modified-Since" (Section 14.25) and "If-None-Match" (Section 14.26) to GET the representation of the resource if and only if it differs from what the user agent already obtained, and o "If-Unmodified-Since" (Section 14.28) and "If-Match" (Section 14.24) to overwrite the representation using PUT if and only if it didn't change since the last GET request (thus avoiding overlapping updates). Note that HTTP defines the behaviour of these headers in terms of "variants" (i.e. the different representations that may be returned for a single resource; see Section 1.3). Furthermore, although HTTP distinguishes between the term "URI" (identifier) and "resource" (the object identified by the URI), the difference has little impact as the HTTP specification does not define any namespace operations that would change the mapping between URIs and resources. Thus, generic clients will rely on consistent behaviour of "Last-Modified" and "ETag" on a per-URI basis even in the presence of namespace operations. 1.1 Example: GET only if unchanged >> Request (getting the content initially) GET /index.html HTTP/1.1 Host: example.org >> Response HTTP/1.1 200 OK Content-Type: text/html; charset="utf-8" Content-Length: xxxx Last-Modified: Sun, 20 Mar 2005 12:45:26 GMT ...body... The user agent stores the response headers along with the content. When it needs to update the content (for instance the user initiates a refresh of the browser window), it uses that information to make the request conditional. >> Request (refreshing the content) GET /index.html HTTP/1.1 Host: example.org If-Unmodified-Since: Sun, 20 Mar 2005 12:45:26 GMT >> Response HTTP/1.1 304 Not Modified Thus, if the content did not change, the user agent avoids getting the same content again. 1.2 Example: PUT only if unchanged >> Request (getting the content initially) GET /index.html HTTP/1.1 Host: example.org >> Response HTTP/1.1 200 OK Content-Type: text/html; charset="utf-8" Content-Length: xxxx Last-Modified: Sun, 20 Mar 2005 12:45:26 GMT ETag: "1" ...body... >> Request (writing back the content) PUT /index.html HTTP/1.1 Host: example.org If-Match: "1" >> Response HTTP/1.1 200 OK However, would the content have changed between the two requests, the response would be: >> Response HTTP/1.1 412 Precondition Failed 1.3 Requirements for 'Last-Modified' and 'ETag' Below is a list of requirements for the behaviour for 'Last-Modified' and 'ETag': R1: The "Last-Modified" date returned for a specific variant of a resource must change whenever the content changes. R2: Whenever it changes, the "Last-Modified" date must increment. R3: The entity tag ("ETag") returned for a specific variant of a resource must change whenever the content changes. 2. Implications for WebDAV namespace operations The requirements above seem to be straightforward to implement, but things get tricky as soon as namespace operations such as COPY ([RFC2518], Section 8.8) and MOVE (Section 8.9) are introduced. For example, consider two resources identified by "index.html" and "index.html.bak" with last modified dates of "12:00:00 GMT" and "11: 50:00 GMT" respectively. A client may have retrieved the content for "index.html", remembering the first timestamp: >> Request (getting the content initially) GET /index.html HTTP/1.1 Host: example.org >> Response HTTP/1.1 200 OK Content-Type: text/html; charset="utf-8" Content-Length: xxxx Last-Modified: Sun, 20 Mar 2005 12:00:00 GMT ...body... Later, another user decides to restore the backup, using a WebDAV MOVE request. >> Request (getting the content initially) MOVE /index.html.bak HTTP/1.1 Host: example.org Destination: http://example.org/index.html >> Response HTTP/1.1 204 OK Finally, the first user agent decides to refresh the content for "index.html". What value for "Last-Modified" should be returned? o Moving the timestamp (setting it to "11:50:00 GMT") will cause it to move back in time, causing the client to assume that the content did not change. o Not modifying the timestamp (leaving it "12:00:00 GMT") will cause the client to assume the content did not change as well. o Thus, to avoid lost refreshes, the server will have to assign a new timestamp which differs from both timestamps and actually is newer than both. The situation for "ETag" is only slightly different; the entity tag needs to be unique across all variants ever served for the same HTTP URL (the only difference is that it doesn't have any inherent order that the conditional request headers would check). Thus, if a server can guarantee that no entity tag ever repeats for any URL within it's namespace, namespace operations do not require any post-processing (otherwise, the same considerations as for "Last-Modified" apply). [[anchor4: Mention the impact of depth=infinity namespace operations --reschke]] 3. 'Last-Modified' vs BIND [draft-ietf-webdav-bind] defines a set of new namespace operations (BIND, UNBIND, REBIND). It's easy to see that for REBIND, the same considerations will apply as for MOVE, and that UNBIND will behave as DELETE. But what about BIND? BIND creates a new URL mapping for a given resource. A server basically has two choices for implementing the "Last-Modified" for resources that support multiple bindings: 1. Store the time stamp with the resource. In this case, "Last- Modified" will be the same regardless which URL a GET/HEAD/ PROPFIND request is applied to. However, the date that is returned must satisfy the requirements defined in Section 1.3 for each of the URLs mapped to it. In practice this means that using BIND to map a URL that has been in use before may cause the "Last-Modified" date to be incremented (for all URLs through which the resource is accessible). 2. Alternatively, a server may choose to store the time stamp on a per-URL basis. This, however, will have the effect that different time stamps are returned although the underlying resource is the same (per BIND's definition). Note that unless a server implements namespace-wide unique entity tags, the same situation will apply to entity tags as well. 4. Summary Client implementors will have to expect that HTTP response headers will vary for different URLs even though the underlying resource is the same. On the other hand, they will also have to expect namespace operations such as MOVE, COPY, BIND or REBIND will affect time stamps and entity tags in a possibly surprising way. It's impossible to predict, because these headers are defined by HTTP, not per WebDAV or BIND. Looking at the properties defined in Section 13 of [RFC2518], only some of them are inherited from HTTP and thus will possibly behave as described above: +---------------------------------+---------------------------------+ | property | behaviour | +---------------------------------+---------------------------------+ | creationdate | per resource | | displayname | per resource (your mileage may | | | vary for some broken | | | implementations out there) | | creationdate | per resource | | getcontentlanguage | potentially per URL as per HTTP | | getcontentlentgth | potentially per URL as per HTTP | | getcontenttype | potentially per URL as per HTTP | | getetag | potentially per URL as per HTTP | | getlastmodified | potentially per URL as per HTTP | | lockdiscovery | per resource | | resourcetype | per resource | | supportedlock | per resource | | source | per resource | +---------------------------------+---------------------------------+ 5. References [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [draft-ietf-webdav-bind] Clemm, G., Crawford, J., Reschke, J., and J. Whitehead, "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", draft-ietf-webdav-bind-12 (work in progress), July 2005, . Author's Address Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany Phone: +49 251 2807760 Fax: +49 251 2807761 Email: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/ Appendix A. FAQ A.1 Why is it so hard to always supply robust entity tags? Example #1: a Java-based server maps filesystem objects to HTTP resources, and is stuck with what java.io.File supports (which only allows access to a very limited subset of the operating system's file information, see ). If the server doesn't fully control the filesystem, and unless it's prepared to store metadata out-of-band (outside the filesystem), it will have to compute entity tags based on file information such as the last- modified date and the length. The only robust alternative would be to compute a hash of the actual file's contents, but usually this is too expensive. Example #2: a module implementing WebDAV is just an add-on to the generic HTTP handler in a server (i.e., mod_dav inside Apache httpd server), and the server doesn't have any information except the one obtained from the underlying store (in this case the filesystem). Even if the server indeed has full access to the operating system's information, it may still not be able to use the file's inode information, for instance because it's a network drive. A.2 What's the story about weak entity tags? HTTP distinguishes between "weak" and "strong" entity tags (see [RFC2616], Section 3.11). Only strong entity tags can be used in authoring scenarios such as the one described in Section 1.2. However, if an entity tag has been computed based on "last-modified" information, it only becomes a "strong" entity tag after a certain interval of non-activity on a resource. Thus, servers may return a weak entity tag as result of a PUT operations, and only later "promote" it to a strong entity tag. Requiring servers to always return strong entity tags in the first place _will_ render Apache/mod_dav non-conformant. From w3c-dist-auth-request@frink.w3.org Sun Dec 11 08:27:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElREo-0004zW-Hg for webdav-archive@megatron.ietf.org; Sun, 11 Dec 2005 08:27:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21670 for ; Sun, 11 Dec 2005 08:26:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElRDU-0007TB-92 for w3c-dist-auth-dist@listhub.w3.org; Sun, 11 Dec 2005 13:26:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ElRDL-0007SB-DL for w3c-dist-auth@listhub.w3.org; Sun, 11 Dec 2005 13:26:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ElRDC-0001tX-Ge for w3c-dist-auth@w3.org; Sun, 11 Dec 2005 13:26:06 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBBDPknr020824; Sun, 11 Dec 2005 05:25:46 -0800 Date: Sun, 11 Dec 2005 05:25:46 -0800 Message-Id: <200512111325.jBBDPknr020824@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ElRDC-0001tX-Ge afd0594dae20aee7e8a18a11e153f524 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 206] New: broken RFC2616 references for some DAV:get* properties X-Archived-At: http://www.w3.org/mid/200512111325.jBBDPknr020824@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11026 X-Loop: w3c-dist-auth@w3.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, 11 Dec 2005 13:26:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=206 Summary: broken RFC2616 references for some DAV:get* properties Product: WebDAV-RFC2518-bis Version: -08 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org The HTTP section references for some of the DAV:get* properties are incorrect (this probably was caused by replacing "RFC2068" by "RFC2616" without also checking the section numbers). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 12:57:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elrvo-0008LN-IJ for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 12:57:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23434 for ; Mon, 12 Dec 2005 12:56:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Elrtj-0004XB-CL for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 17:55:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1ElrtV-0004Tk-IH for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 17:55:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1ElrtN-0002HP-Rg for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 17:55:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCHtGQp021962; Mon, 12 Dec 2005 09:55:16 -0800 Date: Mon, 12 Dec 2005 09:55:16 -0800 Message-Id: <200512121755.jBCHtGQp021962@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElrtN-0002HP-Rg 71cfac2a047dce0d7a12adf0a628f2d8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512121755.jBCHtGQp021962@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11027 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 17:55:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 09:55 ------- Seems to me there was enough uncertainly for this to be raised as an issue. So, my recommendation is to allow the 3xx responses, and to add a brief bit of text to the section defining MKCOL, to say something like: MKCOL, like other HTTP methods, can be redirected by a 3xx redirect response. With this text entered, we can just close this issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 13:38:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsZ3-0000wW-8b for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 13:38:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28625 for ; Mon, 12 Dec 2005 13:37:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElsY4-0006CJ-TH for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 18:37:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElsXu-0006AM-Su for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 18:37:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElsXk-0007bo-Na for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 18:37:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCIav2h022012; Mon, 12 Dec 2005 10:36:57 -0800 Date: Mon, 12 Dec 2005 10:36:57 -0800 Message-Id: <200512121836.jBCIav2h022012@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElsXk-0007bo-Na 66f0ffc59a8cef0c6d30da83a8bac37e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512121836.jBCIav2h022012@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11028 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 18:37:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 10:36 ------- I'm just looking at , and it seems that this was about spec text in an early draft of REDIRECT. I really don't see what the problem in RFC2518(bis) is supposed to be. If we state it for MKCOL, why don't we state it for PUT, PROPPATCH, LOCK, ...? This doesn't compute. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltB5-0002oA-BS for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:17:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04203 for ; Mon, 12 Dec 2005 14:16:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Elt9y-0000vl-4V for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:16:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Elt9n-0000uS-U9 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:16:19 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1Elt9b-0006IH-FQ for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:16:19 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBCJFuMw020936 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 12 Dec 2005 11:15:56 -0800 (PST) In-Reply-To: <439AEE34.2050604@gmx.de> References: <4399DC7A.60209@gmx.de> <439A092F.6090806@cse.ucsc.edu> <439AEE34.2050604@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: WebDAV Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Mon, 12 Dec 2005 11:15:55 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: lisa.w3.org 1Elt9b-0006IH-FQ 312f66b2771b67a2b06fdcba92aa64cf X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/BFD8D8E2-ADE5-47DB-9C51-82FB9E804427@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11029 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:16:30 +0000 Content-Transfer-Encoding: 7bit >>> 8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and >>> RFC2518 Properties >>> >>> Nits: >>> - move it back where it was in RFC2518 >>> - avoid the term RFC2158 properties in the title >> Renamed; brief explanatory note added. > > It would be nice if it also could be moved back to where it was in > RFC2518 in order to avoid needless diffs. Seems like a minor issue, so we left the example in its current location. > >>> - XML in example to be fixed, for instance whitespace in >>> D:getlastmodified >> Fixed the example. However, since DAV:get* properties are based >> upon definitions made in rfc2616, LWS may be found in some >> implementations -- explanatory text added to section 14. > > a) the date doesn't use rfc1123 syntax Um, my understanding is that we haven't decided to change the format of DAV:getlastmodified, which still uses rfc1123 date format. That said, I do have a preference for the RFC 2518 style of representing the value of properties by explicitly referencing the same production in RFC 2616 that the actual header uses. > b) I object to that change, LWS is not part of the value of the > header, that is whitespace is not allowed here (any evidence of a > server adding this???). Do I need to open an issue for that? Well, the issue here is what to do concerning these statements in RFC 2616, section 4.2: The field value MAY be preceded by any amount of LWS, though a single SP is preferred. field-value = *( field-content | LWS ) So, if you view the contents of a header as anything to the right of the colon, then the LWS is part of the value, and we need to state something about it. Another position we could take is to state that the property values only include the field-content: field-content = This is a stronger statement. However, it seemed to me that some server, somewhere, is bound to accidentally put in some LWS either before or after the field-content. As a result, the more interoperable approach was to put in the text stating that LWS might appear, and to be prepared to handle it. That said, the use of the word "value" in: For properties defined based on HTTP GET response headers (DAV:get*), the value could include LWS as defined in , section 4.2. Is ambiguous. A better approach would be to say: For properties defined based on HTTP GET response headers (DAV:get*), the value of the property is intended to be the field-content (as defined in Section 4.2 of RFC2616) of the corresponding header. However, RFC 2616 does permit the protocol octet stream prior to the field-content to contain by LWS, and after the field-content to have LWS. As a result, server implementations SHOULD use just the field- content, and clients MUST be prepared to strip LWS. > >>> 8.7 DELETE [...] This is still a lame way to introduce DELETE. >>> [...] >>> 8.9.5 Status Codes [...] 403 (Forbidden) [...] Confusing. >>> Servers may treat this as a nop, just returning 200. Just be >>> silent about it. >> Discussed this but left the text in, as the semantics were defined >> in 2518 (see similar comment below). > > Well, it was mentioned, but the spec never contained a requirement > for servers to reject this. I'm not following your reply. What is "this"? > >>> 403 (Forbidden) [...] And being source and destination >>> identical would be a problem exactly why? >> Semantics defined in 2518, left alone as a change could compromise >> resource identity (e.g. creation date may change, corruption of >> version history, etc.). > > I don't buy that rational, because that would just mean that the > server did what the client told him to do. In particular, the > version history would not be corrupted nor removed (see RFC3253 > COPY semantics). This is just mirroring the semantics found in RFC 2518. Seems like we'd need to do an interop check on this condition before making any changes here. > >>> 12.1 Response headers [...] This section doesn't provide any >>> useful information. In particular, the second sentence seems to >>> be completely out of context. >> Rewrote this section (originally added following discussion of >> issue 47). Second sentence has been removed. > > It now says: > > HTTP defines the Location header to indicate a preferred URL for > the > resource that was addressed in the Request-URI (e.g. in response to > successful PUT requests or in redirect responses). However, use of > this header creates ambiguity when there are URLs in the body of > the > response, as with Multi-Status. Thus, use of the Location header > with the Multi-Status response is intentionally undefined. > > I still don't understand this. How does the presence of a Location > header create an ambiguity here? The URLs in the response mean > exactly what this spec defines them to mean, and there is > absolutely no ambiguity here. As we have discussed in prior teleconferences, the potential ambiguity comes from this: When there is just the Request-URI, there is only ever one resource being discussed in the request or response. With the multistatus response, there are potentially may resources being discussed in the response. > > I'd also like to point out that we've been wasting an incredible > amount of time undoing a change that was meant to talk about the > "Content-Location" header, not "Location". Agreed, although I'll note that you're the one raising concerns about LWS handling in properties :-) *ducks* Let's discuss this briefly in the next telecon. If there is no consensus there, I recommend asking Cullen to declare consensus. I agree we should close this and move on. > >>> 12.2 URL handling [...] >> Rewrote most of this section, incorporating some of your proposed >> text, and paying attention to RFC3986 language -- please review. > > Now says: > > 12.2 URL Handling > > A Multi-Status body contains one or more 'response' elements. Each > > Zero or more. > > response element describes a resource, and has an 'href' element > identifying the resource. The 'href' element MUST contain an > absolute URI or relative reference. It MUST NOT include "." or > ".." > as path elements. > > It would be helpful if this would refer to the sections of RFC3986 > defining this terms. In particular, I fail to see why we are now > restricted to "absolute-URI" instead of "URI". OK, adding section references to RFC 3986 seems like a good idea to me. It seemed to be that using absolute URI (section 4.3) captured the intent of the WG. That is, we either want a fully qualified URL (i.e, not a relative URL) or we want a relative reference without ""." or "..". As far as I can tell, the only difference between URI (section 3): URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] and absolute-URI (section 4.3): absolute-URI = scheme ":" hier-part [ "?" query ] Is the optional ["#" fragment] part. While I don't see an immediate use case for including the fragment, I also don't see a compelling reason to forbid it, so I'm fine with using "URI" instead of "absolute-URI". > Also note that "URI-reference" means "URI / relative-ref", so we > could use just that. Ah, good find. I agree that we should use this instead. > > If a 'href' element contains a relative reference, it MUST be > resolved against the Request-URI. A relative reference MUST be an > absolute path (note that clients are not known to support relative > paths). > > Again, a reference to the right places in RFC3986 grammar seems to > be useful. OK. > > Identifiers for collections appearing in the results SHOULD end > in a > '/' character. > > If a server allows resource names to include characters that aren't > legal in HTTP URL paths, these characters must be percent- > encoded on > > Why restrict to HTTP URL? Agreed -- this is too restrictive. The percent encoding rules apply to all URIs. > > the wire (see [RFC3986], section 2.1). For example, it is > illegal to > use a space character or double-quote in a URI. URIs appearing in > PROPFIND or PROPPATCH XML bodies (or other XML marshalling > defined in > this specification) are still subject to all URI rules, including > forbidden characters. > > The last sentence doesn't seem to be useful; what we're saying here > applies to all uses of multistatus bodies, including error > responses, or extensions (REPORT...). I disagree. We're making it clear that, just because a URI appears in XML, doesn't mean existing rules don't apply to it. > > >> 19.7 Risks Connected with Lock Tokens [...] >> Proposed text inserted with a couple of tweaks (title of RFC, >> version / variant language, and minor wordsmithing introducing the >> list). > > Still :-) > > 1) Says "Variant x UUID" when it should say "Version x UUID" Ah. I misread the specification when we were editing last Friday. I agree it should be changed back to Version. > > 2) Misses the statement "Since a WebDAV server will issue many > locks over its lifetime, the implication is that it may also be > publicly exposing its IEEE 802 address.". Why? I don't recall. I'm fine with putting this back in. > >>> 22.1 Normative References [...] >> Reference to 2518 moved to informative references. > > Thanks. I just noted that the XML Infoset reference appears under > "informative", but that is indeed normative. But we're still > discussing the "property value" proposal, based on what's in > BugZilla ( id=10>), right? I think so -- 10 is still open, I believe. I'm fine with moving XML Infoset into the normative category. - Jim From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:23:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltGu-0003Ok-OI for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:23:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05024 for ; Mon, 12 Dec 2005 14:22:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltGI-0001kG-OY for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:23:02 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EltGG-0001ji-U1 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:23:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EltFt-00078Z-Iz for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:22:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJMVD4022054; Mon, 12 Dec 2005 11:22:31 -0800 Date: Mon, 12 Dec 2005 11:22:31 -0800 Message-Id: <200512121922.jBCJMVD4022054@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EltFt-00078Z-Iz c3bc5915f4d587ff06dab2b0cb0a6ab0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512121922.jBCJMVD4022054@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11030 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:23:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:22 ------- The rationale for explicitly stating that 3xx redirects apply is as follows. Most use of HTTP is for reading resources. For reads, it's pretty clear what a redirect means -- go someplace else and read what's there. If you have been strongly conditioned to view redirects as just applying to reads, then having redirects apply to writes seems a bit strange. Most people have *never* worked with a system that can possibly store your data under a different location than the one you initially specified. For example, file systems do not work this way. As a result, even though it is a straightforward extension of the semantics of the 3xx responses, it still runs counter to the predominant set of experiences that most programmers have. It also seems potentially dangerous -- what if my work is written someplace I don't want it to go? Since this behavior is non-typical (as compared to the "typical" filesystem behavior), it makes sense for all write operations to explicitly state that they can be redirected via 3xx. The reason we don't exhaustively list that all HTTP responses potentially apply to all WebDAV methods is because most HTTP response codes don't involve semantics that run counter to the typical experience of developers. That is, 3xx is exceptional, exactly because the semantics are atypical. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:27:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltKZ-0003nZ-Hy for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:27:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05575 for ; Mon, 12 Dec 2005 14:26:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltJy-0002Yn-Ev for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:26:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltJv-0002X6-Mf for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:26:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltJq-0002TJ-Ru for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:26:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJQV4s022074; Mon, 12 Dec 2005 11:26:31 -0800 Date: Mon, 12 Dec 2005 11:26:31 -0800 Message-Id: <200512121926.jBCJQV4s022074@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltJq-0002TJ-Ru 45f5c30efb5bdbda25c00249e0b88975 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200512121926.jBCJQV4s022074@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11031 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:26:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:26 ------- RFC 3023 states, in section 3.2: Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the charset of the XML MIME entity. The current WebDAV specification follows this. I'm not seeing any problem, or proposed text change here. Re-closing the issue. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:31:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltOE-0004FG-Q9 for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:31:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06057 for ; Mon, 12 Dec 2005 14:30:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltNV-0004R9-2U for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:30:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EltNR-0004G8-18 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:30:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EltNM-0002NI-Ri for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:30:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJUKlW022093; Mon, 12 Dec 2005 11:30:20 -0800 Date: Mon, 12 Dec 2005 11:30:20 -0800 Message-Id: <200512121930.jBCJUKlW022093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EltNM-0002NI-Ri b4cf4f54afdb6ab2137cfa9a81e6f701 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512121930.jBCJUKlW022093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11032 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:30:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |julian.reschke@greenbytes.de Status|REOPENED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:30 ------- I'm fine with responsedescription containing both a description and the error tag. I'm not sure how to represent this in XML DTD language easily. Assigning to Julian to make a proposal. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:34:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltR8-0004bz-HA for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:34:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06628 for ; Mon, 12 Dec 2005 14:33:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltQU-0005Km-4a for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:33:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EltQL-0005Jc-NX for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:33:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EltQD-0003ab-Ci for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:33:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJXGnE022148; Mon, 12 Dec 2005 11:33:16 -0800 Date: Mon, 12 Dec 2005 11:33:16 -0800 Message-Id: <200512121933.jBCJXGnE022148@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EltQD-0003ab-Ci 2edf8b283b03905cd87f02d3763d3a9b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT X-Archived-At: http://www.w3.org/mid/200512121933.jBCJXGnE022148@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11033 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:33:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:33 ------- *** Bug 205 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:34:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltRC-0004cZ-FY for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:34:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06637 for ; Mon, 12 Dec 2005 14:33:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltQa-0005PE-AP for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:33:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltQQ-0005K0-5a for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:33:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltQD-0005I9-E7 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:33:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJXBfG022118; Mon, 12 Dec 2005 11:33:11 -0800 Date: Mon, 12 Dec 2005 11:33:11 -0800 Message-Id: <200512121933.jBCJXBfG022118@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltQD-0005I9-E7 8756d73389abd69d44fc9fd99acdb950 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT X-Archived-At: http://www.w3.org/mid/200512121933.jBCJXBfG022118@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11034 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:33:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:33 ------- Adding some text from BUG 205, which is a duplicate: The pre-draft of -09 states in section 7.6: A successful lock request to an unmapped URL MUST result in the creation of an locked resource with empty content. Subsequently, a successful PUT request (with the correct lock token) provides the content for the resource, and the server MUST also use the content- type and content-language information from this request. This is a new MUST-level requirement that as far as I understand hasn't been discussed anywhere before, and which contradicts an upcoming TAG finding () - that is, we can't *require* the server to use the submitted meta data. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:34:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltRO-0004dB-JO for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:34:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06649 for ; Mon, 12 Dec 2005 14:33:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltQi-0005Sl-DO for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:33:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EltQQ-0005KE-LD for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:33:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EltQH-0005ML-Kv for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:33:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJXFD3022134; Mon, 12 Dec 2005 11:33:15 -0800 Date: Mon, 12 Dec 2005 11:33:15 -0800 Message-Id: <200512121933.jBCJXFD3022134@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EltQH-0005ML-Kv 731a1defb96bc7e885773c4078d20b77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 205] new MUST level requirement for LOCK on unmapped URLs X-Archived-At: http://www.w3.org/mid/200512121933.jBCJXFD3022134@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11035 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:33:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=205 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:33 ------- This appears to be a duplicate of #152. Will add the link to the TAG discussion to 152. *** This bug has been marked as a duplicate of 152 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:36:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltT3-0005G1-5f for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:36:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06906 for ; Mon, 12 Dec 2005 14:35:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltSO-0006Fg-4v for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:35:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltSL-0006F7-BF for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:35:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltSH-00068I-HS for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:35:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJZO3q022171; Mon, 12 Dec 2005 11:35:24 -0800 Date: Mon, 12 Dec 2005 11:35:24 -0800 Message-Id: <200512121935.jBCJZO3q022171@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltSH-00068I-HS 553ff01674dcac28a048e1e240441165 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200512121935.jBCJZO3q022171@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11036 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:35:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:35 ------- Agree that this should be changed to: Value: URI-reference (see Section 4.1 of [RFC3986]) (note addition of "-" as compared with Julian's suggestion). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:37:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltU9-0005sZ-Vz for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:37:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07459 for ; Mon, 12 Dec 2005 14:36:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltTR-0006cr-Vp for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:36:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltTQ-0006cJ-A1 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:36:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltTJ-0006Sr-Q3 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:36:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJaQJl022193; Mon, 12 Dec 2005 11:36:26 -0800 Date: Mon, 12 Dec 2005 11:36:26 -0800 Message-Id: <200512121936.jBCJaQJl022193@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltTJ-0006Sr-Q3 fc1063df7da43726a8e263ce74f0d45f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512121936.jBCJaQJl022193@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11037 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:36:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ejw@cs.ucsc.edu |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:36 ------- Turning over to Lisa to add this to the Changes section. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:45:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltYD-0007OE-2q for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:41:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08909 for ; Mon, 12 Dec 2005 14:40:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltXM-0007O6-Mb for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:40:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltXK-0007NT-VA for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:40:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltXG-0007vb-BO for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:40:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJeQt7022218; Mon, 12 Dec 2005 11:40:26 -0800 Date: Mon, 12 Dec 2005 11:40:26 -0800 Message-Id: <200512121940.jBCJeQt7022218@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltXG-0007vb-BO 083537c40eaa50cc1d92e6e140365d2e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512121940.jBCJeQt7022218@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11038 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:40:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ejw@cs.ucsc.edu |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:40 ------- I believe the intent is for LWS to *not* be permitted between the ETag in the brackets. Turning over to Lisa to add a note to the "If-Header" section that implied LWS is not permitted in the "State-Token" production. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:48:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eltek-0002Na-Sa for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:48:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11760 for ; Mon, 12 Dec 2005 14:47:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Elte1-0002E7-04 for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:47:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eltdv-0002DW-U7 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:47:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eltdn-00021F-2d for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:47:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJl2HW022242; Mon, 12 Dec 2005 11:47:02 -0800 Date: Mon, 12 Dec 2005 11:47:02 -0800 Message-Id: <200512121947.jBCJl2HW022242@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eltdn-00021F-2d beee57af3d4ca4034b36814eed2137de X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512121947.jBCJl2HW022242@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11039 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:47:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ejw@cs.ucsc.edu |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:47 ------- I'm fine with using the proposed text for the Purpose of the location XML element. Turning over to Lisa to make the change. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:52:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltiL-0004JP-H3 for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:52:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13296 for ; Mon, 12 Dec 2005 14:50:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElthN-00030M-QF for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:51:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElthK-0002zk-VG for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:50:58 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElthE-0003lT-2K for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:50:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJophe022263; Mon, 12 Dec 2005 11:50:51 -0800 Date: Mon, 12 Dec 2005 11:50:51 -0800 Message-Id: <200512121950.jBCJophe022263@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElthE-0003lT-2K cc84033306c89c23b17d35617ada2f2d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512121950.jBCJophe022263@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11040 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:51:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ------- Additional Comments From lisa@osafoundation.org 2005-12-12 11:50 ------- Has anybody found whether WebDAV clients that display DAV:error text will display the condition code as well? If they do, this would argue against allowing both. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:55:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eltlt-0006JT-55 for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:55:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14505 for ; Mon, 12 Dec 2005 14:54:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltlF-0003QN-Ei for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:55:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EltlB-0003Pa-Gz for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:54:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eltkw-0005Jd-EG for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:54:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJscR3022282; Mon, 12 Dec 2005 11:54:38 -0800 Date: Mon, 12 Dec 2005 11:54:38 -0800 Message-Id: <200512121954.jBCJscR3022282@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eltkw-0005Jd-EG 8f729803e43ee40306c32aa1b7cb8513 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512121954.jBCJscR3022282@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11041 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:55:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:54 ------- This should be discussed during the teleconference. If there is no agreement, we should ask Cullen to make a consensus call. There appears to be a fundamental disagreement here. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 14:57:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltnC-0006nA-Nf for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 14:57:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14739 for ; Mon, 12 Dec 2005 14:56:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EltmT-0004AE-Rt for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 19:56:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EltmN-000497-9z for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 19:56:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltmJ-0005WE-2X for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 19:56:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCJtl37022304; Mon, 12 Dec 2005 11:55:47 -0800 Date: Mon, 12 Dec 2005 11:55:47 -0800 Message-Id: <200512121955.jBCJtl37022304@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltmJ-0005WE-2X a92d32d65983b566cf0c620e5ac6e8a6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 145] LOCKDISCOVERY_ON_UNLOCKED_RESOURCE X-Archived-At: http://www.w3.org/mid/200512121955.jBCJtl37022304@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11042 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 19:56:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=145 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:55 ------- Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:01:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltrW-0000oA-Rc for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:01:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15444 for ; Mon, 12 Dec 2005 15:00:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eltqg-0006yu-QP for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:00:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eltqc-0006lp-Ef for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:00:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EltqT-0007Ae-Sd for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:00:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCK0Bru022324; Mon, 12 Dec 2005 12:00:11 -0800 Date: Mon, 12 Dec 2005 12:00:11 -0800 Message-Id: <200512122000.jBCK0Bru022324@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EltqT-0007Ae-Sd b539010226457d091e4a174a645f4feb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512122000.jBCK0Bru022324@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11043 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:00:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 12:00 ------- > ..."MAY" is incorrect here, because we aren't defining anything here... Also, if > we refer to RFC3253, we'd better also state the exact place (here: Section 1.7). I agree. Use "can" or "will" instead. > I don't think this is allowed. The membership should be always the one of the > source namespace, unless I'm missing something. This is what I thought -- the merge behavior is not what was previously in RFC 2518. > That's correct, but only for the first of the two reasons. I don't understand this. Are you suggesting a change? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:04:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eltu0-0001jx-TG for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:04:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15983 for ; Mon, 12 Dec 2005 15:03:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElttN-0007eK-5E for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:03:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElttL-0007dh-Ku for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:03:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElttE-0000QK-9a for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:03:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCK3Gqo022357; Mon, 12 Dec 2005 12:03:16 -0800 Date: Mon, 12 Dec 2005 12:03:16 -0800 Message-Id: <200512122003.jBCK3Gqo022357@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElttE-0000QK-9a a0a1e02b89df3853e1d3770520b62b6d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200512122003.jBCK3Gqo022357@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11044 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:03:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 12:03 ------- It makes sense to keep the final sentence in, since it makes it clear when the 424 is returned. However, then sentence does need to have a statement about how required it is. Choices are MAY, SHOULD, MUST. MAY: IMO, too weak SHOULD: could live with it, but implies there may be reasons a server wouldn't do this. I can't think of any such cases MUST: seems to describe desired behavior, and makes a clear statement. Hence, I lean toward using MUST here. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:15:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elu5Q-0006GD-JZ for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:15:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18684 for ; Mon, 12 Dec 2005 15:14:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Elu4b-0000qw-5f for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:15:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Elu4X-0000qM-Gf for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:14:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Elu4M-0003vx-ES for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:14:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKEhgU022384; Mon, 12 Dec 2005 12:14:43 -0800 Date: Mon, 12 Dec 2005 12:14:43 -0800 Message-Id: <200512122014.jBCKEhgU022384@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Elu4M-0003vx-ES 904aa745bd6ed617500fe23804949e28 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512122014.jBCKEhgU022384@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11045 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:15:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 12:14 ------- This is an important paragraph, which should be in the specification. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:21:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluBC-0008Tf-04 for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:21:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20630 for ; Mon, 12 Dec 2005 15:20:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluA8-0003z3-Gf for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:20:44 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EluA5-0003yV-2p for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:20:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Elu9h-00061w-ON for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:20:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKKGxt022401; Mon, 12 Dec 2005 12:20:16 -0800 Date: Mon, 12 Dec 2005 12:20:16 -0800 Message-Id: <200512122020.jBCKKGxt022401@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Elu9h-00061w-ON 88d1053cd01ecc680222fc59c1a526de X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122020.jBCKKGxt022401@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11046 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:20:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 12:20 ------- I generally like all of the proposed changes, except for: Section 14., para. 78: OLD: Description: MUST be defined on all DAV compliant resources. The default value is empty. Extensibility: MAY be extended with any child elements or attributes which SHOULD be ignored if not recognized. If the element contains the 'collection' child element plus additional unrecognized elements/attributes, it should generally be treated as a collection. If the element contains no recognized child elements it should be treated as a non-collection WebDAV-compliant resource. NEW: Description: MUST be defined on all DAV compliant resources. Each child element identifies a specific type the resource belongs to, such as DAV:collection, which is the only resource type defined by this specification (see Section 13.3). The default value is empty. (note here Description was enhanced because it needed some of the info from the Extensibility section) In particular, I think the previous extensibility section had a good and useful statement about treating collection-like resources as collections. This needs to be kept. I'm OK with deleting the first sentence of the extensibility section, though I'd prefer it to remain. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:26:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluFS-0001sr-9p for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:26:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21355 for ; Mon, 12 Dec 2005 15:25:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluEj-0004wm-0a for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:25:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EluEh-0004wD-8Y for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:25:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EluEX-0007yv-Fe for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:25:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKPCwJ022418; Mon, 12 Dec 2005 12:25:12 -0800 Date: Mon, 12 Dec 2005 12:25:12 -0800 Message-Id: <200512122025.jBCKPCwJ022418@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EluEX-0007yv-Fe 0cf7fed9837835cf445efc4392037869 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 42] Consider deprecating text/xml for XML request/response bodies X-Archived-At: http://www.w3.org/mid/200512122025.jBCKPCwJ022418@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11047 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:25:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=42 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:25 ------- Well, at a minimum we'll need to change "STRONGLY RECOMMENDED" to something else, because that's not defined in RFC2119. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:27:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluGl-0003Ij-Du for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:27:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21625 for ; Mon, 12 Dec 2005 15:26:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluG9-0005AR-CW for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:26:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EluG7-00059o-Q5 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:26:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EluG5-0001YP-26 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:26:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKQmaf022428; Mon, 12 Dec 2005 12:26:48 -0800 Date: Mon, 12 Dec 2005 12:26:48 -0800 Message-Id: <200512122026.jBCKQmaf022428@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EluG5-0001YP-26 f9a1f648a8ff0305bd87393f299ef349 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512122026.jBCKQmaf022428@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11048 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:26:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:26 ------- Well, those clients would be broken. As a matter of fact, I've never seen a client using the responsedescription at all. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:29:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluIm-0004Wy-Dw for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:29:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21994 for ; Mon, 12 Dec 2005 15:28:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluI3-0005Wj-Qt for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:28:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EluI1-0005W6-J6 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:28:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EluHy-0002St-5W for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:28:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKSnBD022446; Mon, 12 Dec 2005 12:28:49 -0800 Date: Mon, 12 Dec 2005 12:28:49 -0800 Message-Id: <200512122028.jBCKSnBD022446@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EluHy-0002St-5W 7775d640b49546499690fff4eefe7964 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 205] new MUST level requirement for LOCK on unmapped URLs X-Archived-At: http://www.w3.org/mid/200512122028.jBCKSnBD022446@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11049 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:28:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=205 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:28 ------- I'm not sure it is a duplicate, because this is an actual problem with a new MUST level req, while the other one was merely a request for clarification. That being said, I'll be happy to discuss both together. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:32:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluLq-0005Bt-5p for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:32:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22346 for ; Mon, 12 Dec 2005 15:31:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluL1-0000Go-Bm for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:31:59 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EluKy-0000GA-Uy for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:31:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EluKd-0002PM-65 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:31:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKVYZ4022467; Mon, 12 Dec 2005 12:31:34 -0800 Date: Mon, 12 Dec 2005 12:31:34 -0800 Message-Id: <200512122031.jBCKVYZ4022467@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EluKd-0002PM-65 9414c846e0c899b568cab81a706699ab X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512122031.jBCKVYZ4022467@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11050 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:31:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:31 ------- Yes, the suggested change would be to replace In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g. to force live properties to be reset or to force collection membership to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset. by In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g. to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:34:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluND-0005Ub-5q for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:34:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22556 for ; Mon, 12 Dec 2005 15:33:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluMX-0000ci-RC for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:33:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EluMW-0000c8-3o for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:33:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EluMQ-0002Ls-N2 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:33:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKX1ow022481; Mon, 12 Dec 2005 12:33:01 -0800 Date: Mon, 12 Dec 2005 12:33:01 -0800 Message-Id: <200512122033.jBCKX1ow022481@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EluMQ-0002Ls-N2 29691c71b6342f3fff986a722de6db8e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 95] possible LOCK response codes X-Archived-At: http://www.w3.org/mid/200512122033.jBCKX1ow022481@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11051 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:33:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=95 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:33 ------- Again, I can live with all of these, but I don't see any reason to put in a MUST level requirement that essentially doesn't provide any additional information to the client (just as for DELETE where we say that it doesn't need to be returned at all). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:39:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluRx-0006Hx-Oa for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:39:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23416 for ; Mon, 12 Dec 2005 15:38:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluRK-0001Rz-86 for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:38:30 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EluRG-0001Qu-FJ for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:38:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EluR6-0005Ao-Dd for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:38:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKcF5F022502; Mon, 12 Dec 2005 12:38:15 -0800 Date: Mon, 12 Dec 2005 12:38:15 -0800 Message-Id: <200512122038.jBCKcF5F022502@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EluR6-0005Ao-Dd 48f73fb35c07d9013facd2b1f1656e1d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512122038.jBCKcF5F022502@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11052 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:38:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 12:38 ------- > The rationale for explicitly stating that 3xx redirects apply is as follows. > > Most use of HTTP is for reading resources. For reads, it's pretty clear what a redirect means -- go > someplace else and read what's there. > > If you have been strongly conditioned to view redirects as just applying to reads, then having redirects > apply to writes seems a bit strange. Most people have *never* worked with a system that can possibly > store your data under a different location than the one you initially specified. For example, file systems > do not work this way. As a result, even though it is a straightforward extension of the semantics of the > 3xx responses, it still runs counter to the predominant set of experiences that most programmers have. > It also seems potentially dangerous -- what if my work is written someplace I don't want it to go? Then your user agent is broken. HTTP is very clear about the fact that clients must not automatically follow redirects upon invocations of unsafe methods (see and ). > Since this behavior is non-typical (as compared to the "typical" filesystem behavior), it makes sense for > all write operations to explicitly state that they can be redirected via 3xx. The reason we don't > exhaustively list that all HTTP responses potentially apply to all WebDAV methods is because most > HTTP response codes don't involve semantics that run counter to the typical experience of developers. > That is, 3xx is exceptional, exactly because the semantics are atypical. So again, why not state it for LOCK, PUT, PROPPATCH then? Still not convinced. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EluYs-0000lH-4v for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:46:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24501 for ; Mon, 12 Dec 2005 15:45:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluY7-0004mi-EI for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:45:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EluY3-0004km-5m for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:45:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EluXu-0006ka-MM for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:45:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCKj9G1022529; Mon, 12 Dec 2005 12:45:09 -0800 Date: Mon, 12 Dec 2005 12:45:09 -0800 Message-Id: <200512122045.jBCKj9G1022529@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EluXu-0006ka-MM 62d87320df67e84e00fa950a83ee677e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512122045.jBCKj9G1022529@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11053 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:45:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 12:45 ------- > So again, why not state it for LOCK, PUT, PROPPATCH then? Still not convinced. Sorry, let me be more clear. I do recommend explicitly stating it for these methods as well. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 15:58:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elukc-00034o-Ga for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:58:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26288 for ; Mon, 12 Dec 2005 15:57:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eluji-0007F8-OQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 20:57:30 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Elujf-0007ES-O5 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 20:57:28 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1ElujZ-0004mF-50 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 20:57:26 +0000 Received: (qmail invoked by alias); 12 Dec 2005 20:57:16 -0000 Received: from p508F9E2C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.158.44] by mail.gmx.net (mp018) with SMTP; 12 Dec 2005 21:57:16 +0100 X-Authenticated: #1915285 Message-ID: <439DE3DF.8030206@gmx.de> Date: Mon, 12 Dec 2005 21:55:59 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead CC: WebDAV References: <4399DC7A.60209@gmx.de> <439A092F.6090806@cse.ucsc.edu> <439AEE34.2050604@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1ElujZ-0004mF-50 0a7a3773b786a47be4f2320c865b41e3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/439DE3DF.8030206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11054 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 20:57:30 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: >>>> - XML in example to be fixed, for instance whitespace in >>>> D:getlastmodified >>> Fixed the example. However, since DAV:get* properties are based upon >>> definitions made in rfc2616, LWS may be found in some implementations >>> -- explanatory text added to section 14. >> >> a) the date doesn't use rfc1123 syntax > > Um, my understanding is that we haven't decided to change the format of > DAV:getlastmodified, which still uses rfc1123 date format. Yes, but the example doesn't use it. > That said, I do have a preference for the RFC 2518 style of representing > the value of properties by explicitly referencing the same production in > RFC 2616 that the actual header uses. Of course. >> b) I object to that change, LWS is not part of the value of the >> header, that is whitespace is not allowed here (any evidence of a >> server adding this???). Do I need to open an issue for that? > > Well, the issue here is what to do concerning these statements in RFC > 2616, section 4.2: > > The field value MAY be preceded by any amount of LWS, though a single > SP is preferred. > > field-value = *( field-content | LWS ) > > So, if you view the contents of a header as anything to the right of the > colon, then the LWS is part of the value, and we need to state something > about it. > > Another position we could take is to state that the property values only > include the field-content: > > field-content = and consisting of either *TEXT or combinations > of token, separators, and quoted-string> > > This is a stronger statement. However, it seemed to me that some server, > somewhere, is bound to accidentally put in some LWS either before or > after the field-content. As a result, the more interoperable approach > was to put in the text stating that LWS might appear, and to be prepared > to handle it. That said, the use of the word "value" in: > > For properties defined based on HTTP GET response headers (DAV:get*), > the value could include LWS as defined in , > section 4.2. > > Is ambiguous. A better approach would be to say: > > For properties defined based on HTTP GET response headers (DAV:get*), > the value of the property is intended to be the field-content (as > defined in Section 4.2 of RFC2616) of the corresponding header. However, > RFC 2616 does permit the protocol octet stream prior to the > field-content to contain by LWS, and after the field-content to have > LWS. As a result, server implementations SHOULD use just the > field-content, and clients MUST be prepared to strip LWS. Do we have evidence of servers putting in LWS, and clients ignoring it? Otherwise I'd prefer to stick with the most simple approach (forbidding the LWS). >>>> 8.7 DELETE [...] This is still a lame way to introduce DELETE. [...] >>>> 8.9.5 Status Codes [...] 403 (Forbidden) [...] Confusing. Servers >>>> may treat this as a nop, just returning 200. Just be silent about it. >>> Discussed this but left the text in, as the semantics were defined in >>> 2518 (see similar comment below). >> >> Well, it was mentioned, but the spec never contained a requirement for >> servers to reject this. > > I'm not following your reply. What is "this"? This = rejecting MOVE / COPY requests where source and destination are the same. >>>> 403 (Forbidden) [...] And being source and destination identical >>>> would be a problem exactly why? >>> Semantics defined in 2518, left alone as a change could compromise >>> resource identity (e.g. creation date may change, corruption of >>> version history, etc.). >> >> I don't buy that rational, because that would just mean that the >> server did what the client told him to do. In particular, the version >> history would not be corrupted nor removed (see RFC3253 COPY semantics). > > This is just mirroring the semantics found in RFC 2518. Seems like we'd > need to do an interop check on this condition before making any changes > here. As far as I can tell, there's no interoperability to worry about. A server just must make sure that kind of request does not unintentionally destroy the resource (which could happen with a naive implementation that DELETEs the destination first). Telling servers what to do exactly is micro-managing the issue. If people are concerned about this problem, just warn implementors that requests like that may occur, and that the server must be prepared for them. >>>> 12.1 Response headers [...] This section doesn't provide any useful >>>> information. In particular, the second sentence seems to be >>>> completely out of context. >>> Rewrote this section (originally added following discussion of issue >>> 47). Second sentence has been removed. >> >> It now says: >> >> HTTP defines the Location header to indicate a preferred URL for the >> resource that was addressed in the Request-URI (e.g. in response to >> successful PUT requests or in redirect responses). However, use of >> this header creates ambiguity when there are URLs in the body of the >> response, as with Multi-Status. Thus, use of the Location header >> with the Multi-Status response is intentionally undefined. >> >> I still don't understand this. How does the presence of a Location >> header create an ambiguity here? The URLs in the response mean exactly >> what this spec defines them to mean, and there is absolutely no >> ambiguity here. > > As we have discussed in prior teleconferences, the potential ambiguity > comes from this: When there is just the Request-URI, there is only ever > one resource being discussed in the request or response. With the > multistatus response, there are potentially may resources being > discussed in the response. HTTP says (): "The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource." I'm not sure how anybody could come to the assumption that things are different in case of a multistatus. >> I'd also like to point out that we've been wasting an incredible >> amount of time undoing a change that was meant to talk about the >> "Content-Location" header, not "Location". > > Agreed, although I'll note that you're the one raising concerns about > LWS handling in properties :-) *ducks* Ahem. I did raise a concern because of a *change* in the spec that I think isn't required, and makes life harder for clients. Again, for these types of changes it would be really good to understand what problem we're actually trying to fix. > Let's discuss this briefly in the next telecon. If there is no consensus > there, I recommend asking Cullen to declare consensus. I agree we should > close this and move on. Fine with me. > ... >> the wire (see [RFC3986], section 2.1). For example, it is illegal to >> use a space character or double-quote in a URI. URIs appearing in >> PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in >> this specification) are still subject to all URI rules, including >> forbidden characters. >> >> The last sentence doesn't seem to be useful; what we're saying here >> applies to all uses of multistatus bodies, including error responses, >> or extensions (REPORT...). > > I disagree. We're making it clear that, just because a URI appears in > XML, doesn't mean existing rules don't apply to it. I'm not against making that cleat (thus the example in the text proposed by me in ), I just find the current wording confusing. The rule applies to *any* method (not only PROPFIND or PROPPATCH), and to all kinds of XML (not only multistatus). > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:03:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elup8-0004EC-VB for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:03:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26996 for ; Mon, 12 Dec 2005 16:02:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluoZ-0000yr-Ab for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:02:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EluoU-0000yC-O6 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:02:26 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EluoR-0007gd-Df for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:02:26 +0000 Received: (qmail invoked by alias); 12 Dec 2005 21:02:21 -0000 Received: from p508F9E2C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.158.44] by mail.gmx.net (mp032) with SMTP; 12 Dec 2005 22:02:21 +0100 X-Authenticated: #1915285 Message-ID: <439DE510.2030400@gmx.de> Date: Mon, 12 Dec 2005 22:01:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDAV Content-Type: multipart/mixed; boundary="------------090206000808080209050802" X-Y-GMX-Trusted: 0 Received-SPF: none (lisa.w3.org: domain of julian.reschke@gmx.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EluoR-0007gd-Df ab066dcf1c9c1125db0328e65e6620ca X-Original-To: w3c-dist-auth@w3.org Subject: [Fwd: RFC 4316 on Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties] X-Archived-At: http://www.w3.org/mid/439DE510.2030400@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11055 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:02:31 +0000 This is a multi-part message in MIME format. --------------090206000808080209050802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. The WebDAV property datatypes spec finally has been published as experimental RFC (see for other versions that plain text). Thanks again to those who reviewed (and implemented) the spec, and provided valuable feedback. Best regards, Julian -------- Original Message -------- From: - Mon Dec 12 21:19:57 2005 X-Account-Key: account5 X-UIDL: ee141f3102d108e1ca3fd276cd93e50b X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: X-Flags: 0000 Delivered-To: GMX delivery to julian.reschke@gmx.de Received: (qmail invoked by alias); 12 Dec 2005 20:16:38 -0000 Received: from megatron.ietf.org (EHLO megatron.ietf.org) [132.151.6.71] by mx0.gmx.net (mx021) with SMTP; 12 Dec 2005 21:16:38 +0100 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elu02-0004Fx-Oe; Mon, 12 Dec 2005 15:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eltzy-0004Ef-AO for ietf-announce@megatron.ietf.org; Mon, 12 Dec 2005 15:10:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17122 for ; Mon, 12 Dec 2005 15:09:10 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elu0g-0003dm-5h for ietf-announce@ietf.org; Mon, 12 Dec 2005 15:11:00 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBCK9X022962; Mon, 12 Dec 2005 12:09:33 -0800 (PST) Message-Id: <200512122009.jBCK9X022962@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 12 Dec 2005 12:09:33 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: rfc-editor@rfc-editor.org Subject: RFC 4316 on Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: 8L/vYzcMeSEkZ/RadnQhaXN1IGRvb8C6 A new Request for Comments is now available in online RFC libraries. RFC 4316 Title: Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties Author(s): J. Reschke Status: Experimental Date: December 2005 Mailbox: julian.reschke@greenbytes.de Pages: 11 Characters: 20352 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-reschke-webdav-property-datatypes-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4316.txt This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 --------------090206000808080209050802 Content-Type: Message/External-body; name="rfc4316.txt" Content-Disposition: inline; filename="rfc4316.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <051212120830.RFC@RFC-EDITOR.ORG> --------------090206000808080209050802 Content-Type: text/plain; name="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOKUME%7E1/JR/LOKALE%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------090206000808080209050802-- From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:04:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eluqw-0004vY-9J for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:04:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27444 for ; Mon, 12 Dec 2005 16:04:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluqL-000197-7v for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:04:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EluqI-00018X-Ry for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:04:18 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EluqF-0008Pc-4l for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:04:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCL4E6l022582; Mon, 12 Dec 2005 13:04:14 -0800 Date: Mon, 12 Dec 2005 13:04:14 -0800 Message-Id: <200512122104.jBCL4E6l022582@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EluqF-0008Pc-4l 02bf6e9ab17e83baee896f18f4bde09a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122104.jBCL4E6l022582@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11056 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:04:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-12 13:04 ------- I believe the new extensibility section is much clearer than the older section, and that the additional wording in the older section was confusing, not helpful. So I vote to keep the new extensibility section as written, and not add back anything from the older section. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eluv4-0007il-Kx for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:09:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28308 for ; Mon, 12 Dec 2005 16:08:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EluuG-0001uK-CR for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:08:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EluuD-0001tk-L8 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:08:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Elutz-0001HO-5e for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:08:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCL84dw022602; Mon, 12 Dec 2005 13:08:04 -0800 Date: Mon, 12 Dec 2005 13:08:04 -0800 Message-Id: <200512122108.jBCL84dw022602@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Elutz-0001HO-5e 518dba5b3151bb4499d89e79a7743ce5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512122108.jBCL84dw022602@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11057 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:08:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-12 13:08 ------- And even if they did display both the text and the error code, that would be better than disallowing the error code to be inserted (many error messages displayed to users include both an error code and error text). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:30:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElvFA-0004gM-SV for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:30:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00369 for ; Mon, 12 Dec 2005 16:28:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElvDk-0005xp-06 for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:28:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElvDg-0005wT-MK for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:28:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElvDc-0000W6-FC for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:28:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCLSN81022622; Mon, 12 Dec 2005 13:28:23 -0800 Date: Mon, 12 Dec 2005 13:28:23 -0800 Message-Id: <200512122128.jBCLSN81022622@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElvDc-0000W6-FC b85b84a260c92832ddc5ed6f6fc02621 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122128.jBCLSN81022622@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11058 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:28:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 13:28 ------- OK, proposed description for "resourcetype" property expanded to: Description: MUST be defined on all DAV compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by this specification (see Section 13.3). If the element contains the 'collection' child element plus additional unrecognized elements, it should generally be treated as a collection. If the element contains no recognized child elements, it should be treated as a non-collection resource. The default value is empty. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:33:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElvIz-0005Tw-Dv for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:33:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00846 for ; Mon, 12 Dec 2005 16:32:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElvIG-0008Gm-6h for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:33:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElvIB-0008Fo-M2 for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:33:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElvI9-0002S0-79 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:33:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCLX41k022638; Mon, 12 Dec 2005 13:33:04 -0800 Date: Mon, 12 Dec 2005 13:33:04 -0800 Message-Id: <200512122133.jBCLX41k022638@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElvI9-0002S0-79 610ad76fdc0c6ec4da3b5d02fb225793 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122133.jBCLX41k022638@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11059 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:33:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-12 13:33 ------- I'm happy with Julian's extended revised text. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:37:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElvMV-0005w5-8N for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:37:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01334 for ; Mon, 12 Dec 2005 16:36:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElvLr-0000Qb-GV for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:36:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElvLo-0000Pc-HB for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:36:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElvLm-0003uo-6t for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:36:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCLanJp022656; Mon, 12 Dec 2005 13:36:49 -0800 Date: Mon, 12 Dec 2005 13:36:49 -0800 Message-Id: <200512122136.jBCLanJp022656@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElvLm-0003uo-6t e031e330642a1e511133a57c36388009 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122136.jBCLanJp022656@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11060 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:36:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 13:36 ------- I am happy with the new proposed text as well. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 16:38:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElvNR-0006NX-IG for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 16:38:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01427 for ; Mon, 12 Dec 2005 16:37:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElvMl-0001W7-7u for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 21:37:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ElvMi-0001Ur-Fa for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 21:37:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ElvMR-00048H-48 for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 21:37:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCLbThk022674; Mon, 12 Dec 2005 13:37:29 -0800 Date: Mon, 12 Dec 2005 13:37:29 -0800 Message-Id: <200512122137.jBCLbThk022674@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ElvMR-00048H-48 7626b5ea463e92d5b9e22a387d2308b9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512122137.jBCLbThk022674@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11061 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 21:37:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 13:37 ------- Assigning to Lisa to make the proposed changes. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Mon Dec 12 17:49:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElwUY-00066V-1Y for webdav-archive@megatron.ietf.org; Mon, 12 Dec 2005 17:49:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09427 for ; Mon, 12 Dec 2005 17:48:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ElwTL-0002e8-Tc for w3c-dist-auth-dist@listhub.w3.org; Mon, 12 Dec 2005 22:48:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ElwT8-0002dM-Us for w3c-dist-auth@listhub.w3.org; Mon, 12 Dec 2005 22:48:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ElwT4-0006dV-8B for w3c-dist-auth@w3.org; Mon, 12 Dec 2005 22:48:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBCMmGJ5022721; Mon, 12 Dec 2005 14:48:16 -0800 Date: Mon, 12 Dec 2005 14:48:16 -0800 Message-Id: <200512122248.jBCMmGJ5022721@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ElwT4-0006dV-8B ce6e898de998b4ed235e7a8c03114b57 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512122248.jBCMmGJ5022721@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11062 X-Loop: w3c-dist-auth@w3.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, 12 Dec 2005 22:48:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-12 14:48 ------- While looking into this, I came across the following language in Section 14.7 of the current spec (): COPY/MOVE behaviour: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this is preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Thus, clients cannot rely on this value for caching and SHOULD use ETags. This sounds like if the spec is trying to tell the readers that servers indeed do not comply to RFC2616, thus should not rely on the semantics defined by RFC2616. This is a really drastic change, which as far as I can tell has never been discussed on the mailing list. For now I'll assume that there is *nO* consensus to keep this in in this form. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 04:18:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6J2-0000Ok-KD for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 04:18:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23812 for ; Tue, 13 Dec 2005 04:17:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Em6HC-0004aj-1F for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 09:16:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Em6H2-0004Zh-QW for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 09:16:40 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Em6Gy-0006th-D9 for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 09:16:39 +0000 Received: (qmail invoked by alias); 13 Dec 2005 09:16:16 -0000 Received: from p508FA96F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.111] by mail.gmx.net (mp015) with SMTP; 13 Dec 2005 10:16:16 +0100 X-Authenticated: #1915285 Message-ID: <439E9115.50104@gmx.de> Date: Tue, 13 Dec 2005 10:15:01 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> In-Reply-To: <4398472E.2020600@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Em6Gy-0006th-D9 ee89bcd83df2714625ce44230289e667 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/439E9115.50104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11063 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 09:16:50 +0000 Content-Transfer-Encoding: 7bit OK, this is really an important issue RFC2518bis has to solve (I'd say, if we can't resolve it, we shouldn't publish a revision at all). So far I've seen two people agreeing that the semantics described by GULP for this situation are indeed correct/desirable, and nobody speaking against. I also note that this is what our server implements (running code!), and nobody has so far made a proposal to define lock semantics differently (not on a case-by-case basis, but with a explanation spanning all methods/situations). So any additional feedback would be highly appreciated. Best regards, Julian Julian Reschke wrote: > > Hi. > > yesterday's conference call resulted in kind of interesting > news on this issues. > > As far as I can tell, the current authors of the draft for RFC2518bis > took the position that the text called GULP - the Grand Unified Locking > Proposal (see for instance [1]) - doesn't need to be incorporated into > RFC2518bis because all it says is already covered over there. > > When we discussed BugZilla issue 54 [2], we discovered that there's > indeed disagreement on locking semantics, and that we need to resolve > that one way or another. > > So what we ended up are two separate questions, which are: > > (1) Should there be a single (normative) place in the doc which provides > a high-level overview of locking, similar but not necessarily identical > with GULP? > > As far as I can tell, the attendees of the conference call concluded > that yes, we want that. > > (2) What are the semantics for a lock on a resource having multiple > bindings (issue 54)? Consider: > > - A resource Z identified by URLs /foo/a and /foo/b. > > - Z gets locked by a LOCK request on /foo/a. > > In this situation, is a lock token required to DELETE /foo/b? GULP's > answer to that one is that you don't need the lock token. Removing the > URI /foo/b does not affect the state of resource Z, nor does it affect > any URL that is protected by that lock (/foo/a and /foo/). A lock token > would need to be provided if the resource /foo itself would be locked, > but it isn't. > > On the other hand, a PUT or a PROPPATCH applied to /foo/b will require > the lock token because it affects the state of resource Z. This may be > confusing, but follows from the fact that the URI of a resource is not > part of it's lockable state. My assumption is that any other attempt to > define this would be even more confusing. > > > Feedback appreciated, > > Julian > > > [1] > > > [2] > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:07:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIJD-0000eW-Iq for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:07:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06044 for ; Tue, 13 Dec 2005 17:06:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIHJ-0007Vh-F8 for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:05:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIH4-0007Uq-I1 for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:05:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EmIGw-0004DA-4J for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:05:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBDM56QT023703; Tue, 13 Dec 2005 14:05:06 -0800 Date: Tue, 13 Dec 2005 14:05:06 -0800 Message-Id: <200512132205.jBDM56QT023703@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EmIGw-0004DA-4J 17a23ec7e1ec0287cbdfe03f9c0f2b64 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512132205.jBDM56QT023703@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11064 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:05:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-13 14:05 ------- Thanks for the changes so far. I think there are still a few things that need to be done: - Relax the definition so that status codes other than 403 and 409 are explicitly allowed (this is what the spec is using anyway). - Decide where to have the normative text for any given condition (I would say this very section), then make sure that all condition names uses throughout the spec are really defined over here, and add proper references. - Last but not least, make each of the descriptions a subsection, so that it appears in the ToC and other parts of the spec can refer to them (without forcing the user to page through the spec). I'm volunteering to make these changes if we have consensus for them. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:18:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmITr-0004S6-F2 for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:18:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07360 for ; Tue, 13 Dec 2005 17:17:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIT4-0002cg-Oe for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:17:54 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmISs-0002bW-I4 for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:17:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmIRl-0004JC-Dg for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:17:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBDMGWKM023727; Tue, 13 Dec 2005 14:16:32 -0800 Date: Tue, 13 Dec 2005 14:16:32 -0800 Message-Id: <200512132216.jBDMGWKM023727@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmIRl-0004JC-Dg 46359b40a2a25a91bf5576ebd4878df8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512132216.jBDMGWKM023727@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11065 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:17:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-13 14:16 ------- I haven't been able to finish the proposed changes for this issue, but here's some text that could go into the introduction of section 14. I'm currently not sure whether we should have it there, or whether it would be better just to expand the explanations for DAV:getlastmodified and DAV:getetag. Speaking of which, one could argue that these explanations don't belong here at all, but should appear where the WebDAV namespace ops are defined. Feedback appreciated. The properties defined by this specification fall into two distinct categories: 1. Properties defined based on the values of certain HTTP response headers, such as DAV:getetag which is based on HTTP's "ETag" response header. 2. Other properties that not have a direct counterpart in HTTP (such as DAV:creationdate). Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing namespace operations (such as COPY or MOVE) does preserve their semantics, in particular: o For any given URL, the "Last-Modified" value must increment everytime the representation returned upon GET changes (within the limits of timestamp resolution). o For any given URL, no "ETag" value must ever be re-used for different representations returned by GET. In practice this means that servers o may have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation, and o similarily, may have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server). For properties defined based on HTTP GET response headers (DAV:get*), the value could include LWS as defined in [RFC2616], section 4.2. Server implementors SHOULD NOT include extra LWS in these values, however client implementors MUST be prepared to handle extra LWS. Note that all property elements can be extended according to the rules defined in Section 16. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:23:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIY7-0005i9-JA for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:23:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07908 for ; Tue, 13 Dec 2005 17:22:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIXP-0003Lu-0h for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:22:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIXM-0003LM-3h for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:22:20 +0000 Received: from mail.dl.ac.uk ([148.79.80.138] helo=mserv7.dl.ac.uk) by maggie.w3.org with esmtp (Exim 4.50) id 1EmIXK-0001Cq-5X for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:22:19 +0000 X-DL-MFrom: X-DL-Connect: Received: from exchange10.dl.ac.uk (exchange10.dl.ac.uk [148.79.163.40]) by mserv7.dl.ac.uk (8.12.10/8.12.8/[ref postmaster@dl.ac.uk]) with ESMTP id jBDMLphW011923 for ; Tue, 13 Dec 2005 22:22:00 GMT Importance: normal Priority: normal Received: from exchange02.dl.ac.uk ([148.79.80.19]) by exchange10.dl.ac.uk with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Dec 2005 22:21:51 +0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Dec 2005 22:21:51 -0000 Message-ID: <77673C9ECE12AB4791B5AC0A7BF40C8F012CB67E@exchange02.fed.cclrc.ac.uk> Thread-Topic: Re: unsubscribe s.y.crompton@dl.ac.uk thread-index: AcYAM51PsswbVX5TRZWHbJEpvOFGBg== From: "Crompton, SY \(Shirley\)" To: X-OriginalArrivalTime: 13 Dec 2005 22:21:51.0410 (UTC) FILETIME=[9D9A3920:01C60033] X-CCLRC-SPAM-report: 0 : X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mserv7.dl.ac.uk id jBDMLphW011923 Received-SPF: none (maggie.w3.org: domain of s.y.crompton@dl.ac.uk does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=1.2 X-W3C-Scan-Sig: maggie.w3.org 1EmIXK-0001Cq-5X 19f675753ef05d64771d0408da8c960f X-Original-To: w3c-dist-auth@w3.org Subject: Re: unsubscribe s.y.crompton@dl.ac.uk X-Archived-At: http://www.w3.org/mid/77673C9ECE12AB4791B5AC0A7BF40C8F012CB67E@exchange02.fed.cclrc.ac.uk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11066 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:22:23 +0000 Content-Transfer-Encoding: 8bit From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:27:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIcE-0006ka-VA for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:27:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08392 for ; Tue, 13 Dec 2005 17:26:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIbS-0004DP-Ry for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:26:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIbO-0004Cr-Pr for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:26:30 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EmIb0-0002vY-12 for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:26:29 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2005 14:26:01 -0800 X-IronPort-AV: i="3.99,248,1131350400"; d="scan'208"; a="377832264:sNHT30800360" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBDMPv70007362 for ; Tue, 13 Dec 2005 14:25:57 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 22:25:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 14:26:04 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Do server store arbitrary content Thread-Index: AcYANDQocsfvR2wnEdqd2AARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EmIb0-0002vY-12 ed23f1c87a4dd49e9d85072256b301f0 X-Original-To: w3c-dist-auth@w3.org Subject: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/BFC48A7C.65368%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11067 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:26:34 +0000 Content-Transfer-Encoding: 7bit I have a questions for the WG. Can servers, within policy constraints, be expected to store arbitrary data. What I mean be the policy constraints is clearly a server might reject a request because it was too large, or it decided the file had a virus and it would not store it. But in general, can a client expect a WebDAV serve to be able to store say a HTML file? From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:29:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIeS-0007uv-JQ for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:29:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08796 for ; Tue, 13 Dec 2005 17:28:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIdr-0004T5-CZ for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:29:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIdl-0004Ri-Pq for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:28:57 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EmIdh-0003p8-MX for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:28:57 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2005 14:28:27 -0800 X-IronPort-AV: i="3.99,248,1131350400"; d="scan'208"; a="377833426:sNHT1467582166" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBDMSQQg003427; Tue, 13 Dec 2005 14:28:26 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 22:28:26 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 14:28:33 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: Wilfredo S=?ISO-8859-1?B?4Q==?=nchez Vega , Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcYANIz3y8v+BmwnEdqd2AARJEEJ/A== In-Reply-To: <438D8498.4000609@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1EmIdh-0003p8-MX 0686f66437ecec835a4b8e1b8c7d06f8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFC48B11.6536C%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11068 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:29:03 +0000 Content-Transfer-Encoding: 7bit I have still been looking for an answer on a question I asked long ago on this. If a client needs a strong ETag, and it gets a weak ETag, should the client poll the server until it gets a strong ETag? This seems to be the recommendation but no one seem to say "yes" or "no" to this? On 11/30/05 2:53 AM, "Julian Reschke" wrote: > Lisa Dusseault wrote: >> On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote: >> >>> >>> It seems that you have a very specific authoring scenario in mind, >>> which you'd like to be simpler to support in a client. How about >>> summarizing the *precise* requirements first, then think about the >>> right technical approach, and only then discuss a way what to do in >>> the spec? Yes, that's more work to do then simply stating "Strong >>> ETags are now required", but it's the better approach nevertheless. >>> >>> >> >> First, before discussing the precise requirements I have in mind, I'd >> like to remind you that the "Strong ETags" proposal didn't come from me >> alone, I'm not the only one with requirements. After the 2002 interop >> where this was first discussed, we had a bunch of list discussion about >> this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov > > I guess it would be good if people would just re-read what was discussed > back then (Dan: > , > myself replying: > ). > > If there was consensus back then, it was for: > > 1) ETags are good. Strong ETags are better. Optimally, PUT returns a > strong Etag. > > 2) Server support for ETags must be consistent (that is, DAV:getetag and > ETag response header should agree) > > Re 1) I don't think there's any disagreement here. The question is how > to achieve it. Putting SHOULD- or MUST-level requirements into the spec > without understanding why servers may not be doing it already is IMHO > the wrong approach. > > Re 2) Of course. If that needs clarification in the spec, let's do it. > >> 28. You were the one who pointed out that solving the problem we were >> discussing required strong ETags, not weak ETags. > > What I pointed out was that the requirement you want to make makes > Apache/mod_dav non-compliant, as it returns weak ETags upon PUT. > >> The requirements: >> - Clients must be able to interoperate against different server >> implementations with great consistency. That means that there should be >> very few cases where clients need to determine what the server >> implementation is or what features it supports, or how, before choosing >> between alternative code paths. > > Yes. It's good when this is the case. On the other hand, it's also good > when servers can support WebDAV for a wide range of resource types, not > just filesystem-like stores. > >> - Clients must be able to be confident, when doing a PUT, that they are >> not overwriting another client's change -- that means that there must be >> some way to compare the state of the resource to the state when it was >> last retrieved. > > ETags do that. If a server doesn't support ETags, the client always can > refuse to update. > > On the other hand, as Wilfredo just pointed out, filesystems do not have > ETags either, and people just live with that (last update wins). So yes, > it's nice if you can avoid it, but it's unclear why it needs to be a > WebDAV requirement. > >> - Specifically, this must work for images, HTML pages, office >> documents, etc -- without requiring any different behavior on the part >> of a client. It would be nice if the server didn't have to care what >> kind of resource it had, as well. > > So are you now requiring that a WebDAV server can store any type of > binary content? What if it's a WebDAV connector on top of an XML database? > >> - It must be possible to write a generic library or remote file system, >> such as WebDAV FS, Xythos WFC or Adobe's library -- one which >> communicates with the WebDAV server on behalf of an application such as >> Word or Photoshop, without requiring overly heavy integration between >> the application and the library. > > It's hard to judge what that actually means protocol-wise. > >> - Clients must be able to keep an offline store with content that's >> fairly reliably consistent with what's on the server. (One problem to >> solve here is for the client to know whether it needs to download a >> resource after a PUT) > > As far as I can tell, the recent discussion on the HTTP mailing list > shows that ETags do not help with that. > >> I generated these rather off-the-cuff, but I believe that's a good start >> at least. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:32:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIgp-000071-Fo for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:32:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08987 for ; Tue, 13 Dec 2005 17:31:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIg7-0006Xb-OB for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:31:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIfy-0006WW-Uc for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:31:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EmIfv-0003mj-8S for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:31:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBDMVAHu023746; Tue, 13 Dec 2005 14:31:10 -0800 Date: Tue, 13 Dec 2005 14:31:10 -0800 Message-Id: <200512132231.jBDMVAHu023746@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EmIfv-0003mj-8S efb14a34fdd68f8123b8539f9cb5c6d8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512132231.jBDMVAHu023746@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11069 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:31:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-13 14:31 ------- The text you have proposed above all looks good to me. WRT where this information should go, I'd would be inclined to place this information into the definition of MOVE and COPY, instead of in the property definitions, but I wouldn't object to it appearing in the property definitions instead (the only thing I'd object to is duplicating this text in both places :- ). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:32:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIhU-0000DO-RZ for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:32:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09109 for ; Tue, 13 Dec 2005 17:31:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIgu-0006hF-Na for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:32:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIgp-0006gh-5q for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:32:07 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EmIgk-0003zM-8E for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:32:06 +0000 Received: (qmail invoked by alias); 13 Dec 2005 22:31:57 -0000 Received: from p508FA96F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.111] by mail.gmx.net (mp038) with SMTP; 13 Dec 2005 23:31:57 +0100 X-Authenticated: #1915285 Message-ID: <439F4B88.1050908@gmx.de> Date: Tue, 13 Dec 2005 23:30:32 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Lisa Dusseault , =?ISO-8859-1?Q?Wilfredo_S=E1?= =?ISO-8859-1?Q?nchez_Vega?= , Geoffrey M Clemm , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EmIgk-0003zM-8E ad0695f5f1089e9cf0cb0184c65ab33b X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/439F4B88.1050908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11070 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:32:12 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I have still been looking for an answer on a question I asked long ago on > this. If a client needs a strong ETag, and it gets a weak ETag, should the > client poll the server until it gets a strong ETag? This seems to be the > recommendation but no one seem to say "yes" or "no" to this? The answer is "no", unless the client happens to know that it talks to a server that indeed upgrades the weak to a strong one later (which in general will not be the case). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:33:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIi0-0000Du-6V for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:33:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09183 for ; Tue, 13 Dec 2005 17:32:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIhJ-0006m5-53 for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:32:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIhF-0006lR-PW for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:32:33 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmIh8-00050H-PZ for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:32:33 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBDMWDs3007628; Tue, 13 Dec 2005 14:32:13 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay7.apple.com (Apple SCV relay) with ESMTP id 23A9DA5; Tue, 13 Dec 2005 14:32:13 -0800 (PST) In-Reply-To: <77673C9ECE12AB4791B5AC0A7BF40C8F012CB67E@exchange02.fed.cclrc.ac.uk> References: <77673C9ECE12AB4791B5AC0A7BF40C8F012CB67E@exchange02.fed.cclrc.ac.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: Jim Luther Date: Tue, 13 Dec 2005 14:32:48 -0800 To: "Crompton, SY (Shirley)" X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (lisa.w3.org: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.7 X-W3C-Scan-Sig: lisa.w3.org 1EmIh8-00050H-PZ dac0600a407b649a3d58381e4c402ffe X-Original-To: w3c-dist-auth@w3.org Subject: Re: unsubscribe s.y.crompton@dl.ac.uk X-Archived-At: http://www.w3.org/mid/CDBC3082-24B5-4269-B340-41ADD7D180FF@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11071 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:32:37 +0000 Content-Transfer-Encoding: 7bit The instructions for the mailing list administrative requests can be found at: http://www.w3.org/Mail/Request From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:35:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIjn-0000fR-Pa for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:35:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09433 for ; Tue, 13 Dec 2005 17:34:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIj5-00071g-6O for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:34:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmIj1-00070d-58; Tue, 13 Dec 2005 22:34:23 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmIhq-0001rL-PU; Tue, 13 Dec 2005 22:34:21 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMX7lI013375; Tue, 13 Dec 2005 17:33:07 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBDMX7Xp115420; Tue, 13 Dec 2005 17:33:07 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBDMX6Wp026464; Tue, 13 Dec 2005 17:33:07 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMX6ED026455; Tue, 13 Dec 2005 17:33:06 -0500 In-Reply-To: To: Cullen Jennings Cc: WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 13 Dec 2005 17:33:16 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/13/2005 17:33:05, Serialize complete at 12/13/2005 17:33:05 Content-Type: multipart/alternative; boundary="=_alternative 007BE175852570D6_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmIhq-0001rL-PU 91f2d561dbf2fc72ac77d7b002ca7549 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/OF424A4E25.EFFAAF60-ON852570D6.007BCC7E-852570D6.007BE1D4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11072 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:34:27 +0000 This is a multipart message in MIME format. --=_alternative 007BE175852570D6_= Content-Type: text/plain; charset="US-ASCII" Yes, I would expect a WebDV server to be able to store arbitrary content (within the kinds of policy constraints that you mention). Cheers, Geoff Cullen wrote on 12/13/2005 05:26:04 PM: > > > I have a questions for the WG. Can servers, within policy constraints, be > expected to store arbitrary data. What I mean be the policy constraints is > clearly a server might reject a request because it was too large, or it > decided the file had a virus and it would not store it. But in general, can > a client expect a WebDAV serve to be able to store say a HTML file? > > > --=_alternative 007BE175852570D6_= Content-Type: text/html; charset="US-ASCII"
Yes, I would expect a WebDV server to be able to store arbitrary content
(within the kinds of policy constraints that you mention).

Cheers,
Geoff


Cullen wrote on 12/13/2005 05:26:04 PM:

>
>
> I have a questions for the WG. Can servers, within policy constraints, be
> expected to store arbitrary data. What I mean be the policy constraints is
> clearly a server might reject a request because it was too large, or it
> decided the file had a virus and it would not store it. But in general, can
> a client expect a WebDAV serve to be able to store say a HTML file?
>
>
>
--=_alternative 007BE175852570D6_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:36:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIl3-0001E3-5u for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:36:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09527 for ; Tue, 13 Dec 2005 17:35:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIkM-0007YQ-Ld for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:35:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIkJ-0007Xn-7J for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 22:35:43 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EmIjz-0004gS-Qy for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 22:35:42 +0000 Received: (qmail invoked by alias); 13 Dec 2005 22:34:52 -0000 Received: from p508FA96F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.111] by mail.gmx.net (mp011) with SMTP; 13 Dec 2005 23:34:52 +0100 X-Authenticated: #1915285 Message-ID: <439F4C38.8040407@gmx.de> Date: Tue, 13 Dec 2005 23:33:28 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EmIjz-0004gS-Qy 5121d0672dc98b23dbd93ca7e81e82c8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/439F4C38.8040407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11073 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:35:46 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I have a questions for the WG. Can servers, within policy constraints, be > expected to store arbitrary data. What I mean be the policy constraints is > clearly a server might reject a request because it was too large, or it > decided the file had a virus and it would not store it. But in general, can > a client expect a WebDAV serve to be able to store say a HTML file? In general, no it can't. There are servers that accept only particular types of content (such as something running on top of an XML database). Would it be useful to allow clients to discover support for these kinds of things upfront? Sure, that's exactly I'd be happy to define a profile and give it a compliance class name for use in the DAV header (for example). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:37:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIm0-0001QM-DE for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:37:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09761 for ; Tue, 13 Dec 2005 17:36:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIlP-0007gR-Ms for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:36:51 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmIlG-0007fN-U5; Tue, 13 Dec 2005 22:36:43 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmIjM-0002OR-4X; Tue, 13 Dec 2005 22:36:41 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMYWHJ015956; Tue, 13 Dec 2005 17:34:32 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBDMYXKn111340; Tue, 13 Dec 2005 17:34:33 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBDMYWFG022899; Tue, 13 Dec 2005 17:34:33 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMYWvo022896; Tue, 13 Dec 2005 17:34:32 -0500 In-Reply-To: <439F4B88.1050908@gmx.de> To: Julian Reschke Cc: Cullen Jennings , Lisa Dusseault , WebDav , w3c-dist-auth-request@w3.org, Wilfredo =?ISO-8859-1?Q?S=E1nchez_Vega?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 13 Dec 2005 17:34:43 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/13/2005 17:34:31, Serialize complete at 12/13/2005 17:34:31 Content-Type: multipart/alternative; boundary="=_alternative 007C02ED852570D6_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmIjM-0002OR-4X 034329b30a512dc12a379cd12880431b X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/OF7F927488.C6C3E2CB-ON852570D6.007BF88C-852570D6.007C038F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11074 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:36:51 +0000 This is a multipart message in MIME format. --=_alternative 007C02ED852570D6_= Content-Type: text/plain; charset="US-ASCII" +1 for "no". Julian wrote on 12/13/2005 05:30:32 PM: > > Cullen Jennings wrote: > > I have still been looking for an answer on a question I asked long ago on > > this. If a client needs a strong ETag, and it gets a weak ETag, should the > > client poll the server until it gets a strong ETag? This seems to be the > > recommendation but no one seem to say "yes" or "no" to this? > > The answer is "no", unless the client happens to know that it talks to a > server that indeed upgrades the weak to a strong one later (which in > general will not be the case). --=_alternative 007C02ED852570D6_= Content-Type: text/html; charset="US-ASCII"
+1 for "no".

Julian wrote on 12/13/2005 05:30:32 PM:

>
> Cullen Jennings wrote:
> > I have still been looking for an answer on a question I asked long ago on
> > this. If a client needs a strong ETag, and it gets a weak ETag, should the
> > client poll the server until it gets a strong ETag? This seems to be the
> > recommendation but no one seem to say "yes" or "no" to this?
>
> The answer is "no", unless the client happens to know that it talks to a
> server that indeed upgrades the weak to a strong one later (which in
> general will not be the case).
 --=_alternative 007C02ED852570D6_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 13 17:47:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIvx-0004Ri-S3 for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:47:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10665 for ; Tue, 13 Dec 2005 17:46:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmIvJ-0002ZM-4j for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 22:47:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmIvC-0002Xo-Ir; Tue, 13 Dec 2005 22:46:58 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmIux-0000xP-Q8; Tue, 13 Dec 2005 22:46:57 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMkg1K026336; Tue, 13 Dec 2005 17:46:42 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBDMkgXp121690; Tue, 13 Dec 2005 17:46:42 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBDMkgqE029630; Tue, 13 Dec 2005 17:46:42 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBDMkfL0029627; Tue, 13 Dec 2005 17:46:42 -0500 In-Reply-To: <439F4C38.8040407@gmx.de> To: Julian Reschke Cc: Cullen Jennings , WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 13 Dec 2005 17:46:52 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/13/2005 17:46:41, Serialize complete at 12/13/2005 17:46:41 Content-Type: multipart/alternative; boundary="=_alternative 007D1ECE852570D6_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EmIux-0000xP-Q8 256430f735ec061a81e2c6e24819399f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/OFD844126C.2F9500F5-ON852570D6.007C8690-852570D6.007D205B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11075 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 22:47:05 +0000 This is a multipart message in MIME format. --=_alternative 007D1ECE852570D6_= Content-Type: text/plain; charset="US-ASCII" OK, I'll also change my vote to "no" (:-). The repositories I build are "general content" repositories, but even they have sections of the namespace (such as where "activities" live) which do not support arbitrary content. I can see other applications (such as calendar management applications) which would disallow arbitrary content (or at least severely restrict where it can be placed). Cheers, Geoff Julian wrote on 12/13/2005 05:33:28 PM: > > Cullen Jennings wrote: > > > > I have a questions for the WG. Can servers, within policy constraints, be > > expected to store arbitrary data. What I mean be the policy constraints is > > clearly a server might reject a request because it was too large, or it > > decided the file had a virus and it would not store it. But in general, can > > a client expect a WebDAV serve to be able to store say a HTML file? > > In general, no it can't. There are servers that accept only particular > types of content (such as something running on top of an XML database). > > Would it be useful to allow clients to discover support for these kinds > of things upfront? Sure, that's exactly I'd be happy to define a profile > and give it a compliance class name for use in the DAV header (for example). > > Best regards, Julian > --=_alternative 007D1ECE852570D6_= Content-Type: text/html; charset="US-ASCII"
OK, I'll also change my vote to "no" (:-).  The repositories I build are "general content" repositories, but even they have sections of the namespace (such as where "activities" live) which do not support arbitrary content.  I can see other applications (such as calendar management applications) which would disallow arbitrary content (or at least severely restrict where it can be placed).

Cheers,
Geoff


Julian wrote on 12/13/2005 05:33:28 PM:

>
> Cullen Jennings wrote:
> >
> > I have a questions for the WG. Can servers, within policy constraints, be
> > expected to store arbitrary data. What I mean be the policy constraints is
> > clearly a server might reject a request because it was too large, or it
> > decided the file had a virus and it would not store it. But in general, can
> > a client expect a WebDAV serve to be able to store say a HTML file?
>
> In general, no it can't. There are servers that accept only particular
> types of content (such as something running on top of an XML database).
>
> Would it be useful to allow clients to discover support for these kinds
> of things upfront? Sure, that's exactly I'd be happy to define a profile
> and give it a compliance class name for use in the DAV header (for example).
>
> Best regards, Julian
>
--=_alternative 007D1ECE852570D6_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 13 18:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJE6-0001RY-1v for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 18:06:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12229 for ; Tue, 13 Dec 2005 18:05:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmJDI-0007nk-3B for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 23:05:40 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmJD1-0007mw-Bp for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 23:05:23 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmJCX-0004Ik-Sf for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 23:05:22 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 15:04:50 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240628456:sNHT30869572" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBDN4mMe015736 for ; Tue, 13 Dec 2005 15:04:49 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 23:04:46 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 15:04:53 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: New compliance class - was Re: [Bug 200] remove "bis" compliance class Thread-Index: AcYAOaBZ3y/ppmwsEdqd2AARJEEJ/A== In-Reply-To: <200512121954.jBCJscR3022282@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmJCX-0004Ik-Sf 9dc25b958430412f1385e292221ee1f1 X-Original-To: w3c-dist-auth@w3.org Subject: New compliance class - was Re: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/BFC49395.6538C%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11076 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 23:05:40 +0000 Content-Transfer-Encoding: 7bit I just read section 17 and, well, I'm certainly not clear how versioning works. Is there a need for a client to do something different based on if it is talking to a server that does all the MUST in 2518 and a server that does all the MUST in bis. If so, the description in 17.1 may be problematic. If this is the case, can someone provide an concrete example of this? If there is no case of this, we can use the same class for all the MUSTs in bis. If not we will need a way to tell if a server does all the MUST in 2518 or all the MUST in bis. The description in 17.2 leaves me very unclear of what needs to be implemented to be class 2. By "support" do you mean implement the MUSTs? The SHOULDs? the MAYs? Any reason not to rename "class bis" to "class 3". What is our take on Forced-Authenticate. Do we have a use case that requires us to create a new class for this? On 12/12/05 11:54 AM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 > > > > > > ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-12 11:54 ------- > This should be discussed during the teleconference. If there is no agreement, > we should ask Cullen to > make a consensus call. There appears to be a fundamental disagreement here. > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 18:11:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJIo-00035v-R6 for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 18:11:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12624 for ; Tue, 13 Dec 2005 18:10:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmJHw-00006O-Bq for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 23:10:28 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmJHR-00089l-LE; Tue, 13 Dec 2005 23:09:58 +0000 Received: from adsl-68-126-173-45.dsl.snfc21.pacbell.net ([68.126.173.45] helo=joliet-jake.wsanchez.net) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmJHJ-00065x-A0; Tue, 13 Dec 2005 23:09:56 +0000 Received: from [192.168.1.125] (unknown [216.9.46.57]) by joliet-jake.wsanchez.net (Postfix) with ESMTP id A4FC31C80B2; Tue, 13 Dec 2005 15:09:42 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--558125291; protocol="application/pkcs7-signature" Message-Id: <7C05ED77-C16B-4E93-ACAC-0EA50AA49CF7@wsanchez.net> Cc: Julian Reschke , Cullen Jennings , Lisa Dusseault , WebDav , w3c-dist-auth-request@w3.org From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 13 Dec 2005 15:09:40 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmJHJ-00065x-A0 90a21261a2f539d6e8d40778a2820ded X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/7C05ED77-C16B-4E93-ACAC-0EA50AA49CF7@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11077 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 23:10:28 +0000 --Apple-Mail-4--558125291 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Yeah, you have no way to know that you will ever get a strong ETag unless you are depending on a specific server implementation. -wsv On Dec 13, 2005, at 2:34 PM, Geoffrey M Clemm wrote: > > +1 for "no". > > Julian wrote on 12/13/2005 05:30:32 PM: > > > > > Cullen Jennings wrote: > > > I have still been looking for an answer on a question I asked > long ago on > > > this. If a client needs a strong ETag, and it gets a weak ETag, > should the > > > client poll the server until it gets a strong ETag? This seems > to be the > > > recommendation but no one seem to say "yes" or "no" to this? > > > > The answer is "no", unless the client happens to know that it > talks to a > > server that indeed upgrades the weak to a strong one later (which in > > general will not be the case). --Apple-Mail-4--558125291 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHbDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQlMIIDjqADAgECAhBx7J2j8CFn/hGS fsXTuaKyMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNTEyMTIwMTA1NDFaFw0wNjEyMTIwMTA1NDFaMIIBHzEVMBMGA1UEBBMMU2Fu Y2hleiBWZWdhMREwDwYDVQQqEwhXaWxmcmVkbzEeMBwGA1UEAxMVV2lsZnJlZG8gU2FuY2hleiBW ZWdhMSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekB3c2FuY2hlei5uZXQxITAfBgkqhkiG9w0BCQEW EndzYW5jaGV6QGFwcGxlLmNvbTEiMCAGCSqGSIb3DQEJARYTd3NhbmNoZXpAYXBhY2hlLm9yZzEf MB0GCSqGSIb3DQEJARYQd3NhbmNoZXpAbWl0LmVkdTEkMCIGCSqGSIb3DQEJARYVd3NhbmNoZXpA YWx1bS5taXQuZWR1MR8wHQYJKoZIhvcNAQkBFhB3c2FuY2hlekBtYWMuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4pAElSKR4KhKaopixoANvjnn/ZJirl2wJL7mEtgxA6kzZ/iB t9m9h3CNTh2h9g87CbOb10trNI8MmusNLgC4y2Z1Jv9EEV9LidrYW8iJx5vrqPOpOCwKqdqM4K+y kCC/CZVRYh7b5Di0UChUqtfNc6MROXz30GNq3n5fpWNbzz64DgAMSohwfSQbtt4f1W3OHIDHbtOl s4RNYmQssgI+SiYYekfJZl0RKrTEs0iYkTUFDV/Rwm1/GcIUpEHU00jmZJ2NxZUnWpOWlMa+iWn7 xUpr1W3CWXEnD9/leXRokoKhZvU5K4SiZyLqstEnWz5Qqz8sq6/ZD80K1z8G5XnjZQIDAQABo4GY MIGVMIGEBgNVHREEfTB7gRV3c2FuY2hlekB3c2FuY2hlei5uZXSBEndzYW5jaGV6QGFwcGxlLmNv bYETd3NhbmNoZXpAYXBhY2hlLm9yZ4EQd3NhbmNoZXpAbWl0LmVkdYEVd3NhbmNoZXpAYWx1bS5t aXQuZWR1gRB3c2FuY2hlekBtYWMuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA gU93zJYHgQsOY2QwIFlBViwUWbRGwb4wflJH1sp1gyX+JOxdB60AbIdME/kSTp9tJUvHRyt1j0Yq SWXADqqohXo04XgZusdwqEjIy2dMt6c7KG+NocLqhgL9Y6HqLRWTC1Ve3TxZVn18Wb0j41fJIYhi 6RwT/cRyFQ9rcdZCatMxggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQceydo/AhZ/4Rkn7F07misjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEyMTMyMzA5NDFaMCMGCSqGSIb3DQEJ BDEWBBQTmTNp4Zfa9WIW51j1aOUf9w/8EzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHHsnaPwIWf+EZJ+xdO5orIwgYcGCyqGSIb3 DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHHs naPwIWf+EZJ+xdO5orIwDQYJKoZIhvcNAQEBBQAEggEAcW4w3ht2ZH/AzHz/M0XhleH0z8o+B+6B KjpaWcR8bSyQgudpdxOnagYtmMycUX18pSosdErcqZf3bAzUEDJdW7q0UDCxLymdgdFhjTSsVjTi pr6ynLZq6ebNQHbTuoSyLOlpxCrTauOZum0d1NKIvs5ogXpmtYNirOdITbFBgp/GV1Z33G/++XyK Z65O9lK0FxdxmYrrpuCs8WIt5yDZGy0O0v0Q1fSr50K3ecqm1XrdLO+TTkuGTwLsWTqQxFcbDsnz cdjy/ClCh0gctaeZ+LvJvcE/oRTbAlgC94azDKl1PCjgdniBDwom0OYZAVmjvlnuqFJKUS4xmoWg XmzeTAAAAAAAAA== --Apple-Mail-4--558125291-- From w3c-dist-auth-request@frink.w3.org Tue Dec 13 18:26:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJXm-0007N0-Er for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 18:26:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13802 for ; Tue, 13 Dec 2005 18:25:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmJX5-0005Dk-Fq for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 23:26:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmJWu-00059X-AK for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 23:25:56 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1EmJWq-00038Q-Bv for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 23:25:55 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 15:25:39 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240634103:sNHT5651409582" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBDNPbpf026002 for ; Tue, 13 Dec 2005 15:25:37 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 23:25:37 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 15:25:44 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Concern about bugzilla SPAM Thread-Index: AcYAPIoByJ1fQGwvEdqd2AARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (maggie.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: maggie.w3.org 1EmJWq-00038Q-Bv 082ad30ac0f3602c6aa808c27a8b2e6a X-Original-To: w3c-dist-auth@w3.org Subject: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/BFC49878.6539C%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11078 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 23:26:07 +0000 Content-Transfer-Encoding: 7bit I'd like some feedback on if people are OK with the bugzilla stuff being mailed to the list? Is it good? should we stop it and discuss on list then post resolution into bugzilla? On 12/8/05 9:36 AM, "DigitallySmooth" wrote: > > how do I get off this list please? > > ----- Original Message ----- > From: > To: > Sent: Wednesday, December 07, 2005 1:47 PM > Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS > > >> >> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 >> >> lisa@osafoundation.org changed: >> >> What |Removed |Added >> -------------------------------------------------------------------------- > -- >> Status|NEW |RESOLVED >> Resolution| |FIXED >> >> >> >> >> >> ------- You are receiving this mail because: ------- >> You are the QA contact for the bug, or are watching the QA contact. >> >> From w3c-dist-auth-request@frink.w3.org Tue Dec 13 18:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJeA-0000XR-5r for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 18:33:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14440 for ; Tue, 13 Dec 2005 18:32:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmJdP-0007di-KO for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 23:32:39 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmJdM-0007d3-Hn for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 23:32:36 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmJdG-0004dj-F2 for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 23:32:35 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 15:32:30 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240636362:sNHT32698044" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBDNWRMe024404; Tue, 13 Dec 2005 15:32:28 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by sea-alpha-e2k3.sea-alpha.cisco.com ([10.93.132.88]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 23:38:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 15:32:34 -0800 From: Cullen Jennings To: WebDav CC: Julian Reschke Message-ID: Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcYAPX5ivP6w3mwwEdqd2AARJEEJ/A== In-Reply-To: <439E9115.50104@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmJdG-0004dj-F2 61911e13380aae0bd4940b25b3442271 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/BFC49A12.6539F%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11079 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 23:32:39 +0000 Content-Transfer-Encoding: 7bit This is clearly a very important topic - Julian points out he thinks it is one of the few where if we can't solve it, we should not publish an update. Let me break it apart into a few different issues - I think we agree on most of them and the others we might agree but I don't understand well enough to be sure we do. So let me try and split these up and ask some questions to help figure out how to either know we do agree or get to agreement. In any system that supports locking, it is always a complex issues with many tradeoffs. One topic is should we have a section in this document that introduces the concepts, defines any terminology, explains the model, explains way it works, and points out any gotchas that implementers may not think of and should be aware of. I think we all agree having this in bis is a *good* idea. >From this point, I think we get to two different areas. 1) what type of locks to do we want 2) give agreement on how locks work, how do we want to specify them. Let me discuss #2 first. We have the question is if the level of text in the GULP provides enough information to for interoperable implementations. I have never argued that a specification should tell people how they have to implement something but it should be written in such a way that is implementable. From reading GULP, is it clear how you might implement it? Is it clear that there is a polynomial time algorithm to implement locking? We could specify locks in many different ways - one would be to describe the invariants of they system with regards to the locks. This is basically the approach GULP takes. The other would be to provide certain algorithmic rules that results in the same set of invariants. This is the approach most specifications take. Both have their place and useful. Now, we could normatively use algorithm and still provide the GULP style description of the invariants. On the conference call, I felt this was what people wanted. Did I totally miss this? Thoughts? It is hard to call consensus on this because it is hard for people to express their opinion until they see some text but unless I hear otherwise, I will assume this is the path we are somewhat proceeding down towards coming up with some text ask for consensus on. Back to the first issue of what type of LOCKs are we building. This is by far the more important issue. GULP provides one possible answer to this but I'm not sure we have agreement on that. I will now refer to the PUT and DELETE example that Julian put out earlier in this thread. My read of the email is that we *do* agree on how the PUT would work. I'm not sure we agree on how the DELETE should work. We might agree but I can't tell. Let's assume we are working on a server that does not support bind. I'm not clear how DELETE works. If /foo/a and /foo/b both point at the same resource, and /foo/b is deleted, is there a guarantee that the resource will not be deleted and that /foo/a will still point at the resource? Does the spec allow the server to choose a model and some might allow it and some might not? If so, do we need to allow the server to be able to select a locking model that follows this? There seems to be questions around depth and depth infinity, do we agree on these. These are probably the wrong questions but what I am trying to do is separate this into two parts. 1 is how locks work, 2 is how we specify them in bis. On the topic of how it works, does anyone care to help me frame the really key question to decide how it works? On 12/13/05 1:15 AM, "Julian Reschke" wrote: > > OK, > > this is really an important issue RFC2518bis has to solve (I'd say, if > we can't resolve it, we shouldn't publish a revision at all). > > So far I've seen two people agreeing that the semantics described by > GULP for this situation are indeed correct/desirable, and nobody > speaking against. I also note that this is what our server implements > (running code!), and nobody has so far made a proposal to define lock > semantics differently (not on a case-by-case basis, but with a > explanation spanning all methods/situations). > > So any additional feedback would be highly appreciated. > > Best regards, Julian > > > Julian Reschke wrote: >> >> Hi. >> >> yesterday's conference call resulted in kind of interesting >> news on this issues. >> >> As far as I can tell, the current authors of the draft for RFC2518bis >> took the position that the text called GULP - the Grand Unified Locking >> Proposal (see for instance [1]) - doesn't need to be incorporated into >> RFC2518bis because all it says is already covered over there. >> >> When we discussed BugZilla issue 54 [2], we discovered that there's >> indeed disagreement on locking semantics, and that we need to resolve >> that one way or another. >> >> So what we ended up are two separate questions, which are: >> >> (1) Should there be a single (normative) place in the doc which provides >> a high-level overview of locking, similar but not necessarily identical >> with GULP? >> >> As far as I can tell, the attendees of the conference call concluded >> that yes, we want that. >> >> (2) What are the semantics for a lock on a resource having multiple >> bindings (issue 54)? Consider: >> >> - A resource Z identified by URLs /foo/a and /foo/b. >> >> - Z gets locked by a LOCK request on /foo/a. >> >> In this situation, is a lock token required to DELETE /foo/b? GULP's >> answer to that one is that you don't need the lock token. Removing the >> URI /foo/b does not affect the state of resource Z, nor does it affect >> any URL that is protected by that lock (/foo/a and /foo/). A lock token >> would need to be provided if the resource /foo itself would be locked, >> but it isn't. >> >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will require >> the lock token because it affects the state of resource Z. This may be >> confusing, but follows from the fact that the URI of a resource is not >> part of it's lockable state. My assumption is that any other attempt to >> define this would be even more confusing. >> >> >> Feedback appreciated, >> >> Julian >> >> >> [1] >> >> >> [2] >> >> > From w3c-dist-auth-request@frink.w3.org Tue Dec 13 18:33:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmJeI-0000Xe-12 for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 18:33:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14451 for ; Tue, 13 Dec 2005 18:32:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmJdc-0007j8-OH for w3c-dist-auth-dist@listhub.w3.org; Tue, 13 Dec 2005 23:32:52 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmJdZ-0007ht-FJ for w3c-dist-auth@listhub.w3.org; Tue, 13 Dec 2005 23:32:49 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmJdQ-0004dj-Jr for w3c-dist-auth@w3.org; Tue, 13 Dec 2005 23:32:48 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 15:32:40 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240636420:sNHT32584964" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBDNWbpf028692; Tue, 13 Dec 2005 15:32:38 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Dec 2005 23:32:37 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 15:32:45 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav Message-ID: Thread-Topic: [Bug 188] PROPFIND include-dead-props Thread-Index: AcYAPYTww5d6AmwwEdqd2AARJEEJ/A== In-Reply-To: <439389F4.4080007@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmJdQ-0004dj-Jr 7f0fa4b8a28c6566901f7bb38bb40795 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/BFC49A1D.653A0%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11080 X-Loop: w3c-dist-auth@w3.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, 13 Dec 2005 23:32:52 +0000 Content-Transfer-Encoding: 7bit On 12/4/05 4:29 PM, "Julian Reschke" wrote: > > Lisa Dusseault wrote: >>> But if a server implements "bis", it MUST also support lots of other >>> unrelated features. This is a question of granularity, and optimally, >>> we won't need "bis" at all because all the things we add can be >>> discovered individually (such as support for DAV:lockroot, for example). >> >> This isn't my idea of optimality. Servers should implement all of >> RFC2518bis, not cherry-pick bits and pieces. > > On the other hand, putting a set of totally unrelated changes into one > single bag, and hoping that server implementors will be thrilled to > implement all of this or nothing at all isn't realistic either. In > particular if this set contains stuff that can't be implemented by some. > > Best regards, Julian IETF has long tried make its protocols such that if you have a FOO server and a FOO client, they will work together. Clearly the easiest for the server would be to provide very few things, and the easiest for the client would be for the server to provide a lot of things. It's fine to say that my client requires a server that does version 4 of the protocol but most people seem to have a pretty dim view of places where a server fully compliant with RFC XXXX can't work with a given client while all that client uses are things defined in RFC XXXX. I'd encourage the group to try and meet that sort of goal - I realize this has some tradeoff at points, and thus the compliance class and other profiling mechanism but realize they do have many problems and use sparingly. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 19:01:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmK5L-0006U9-3j for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:01:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16581 for ; Tue, 13 Dec 2005 19:00:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmK4a-0005pD-V6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 00:00:44 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmK4R-0005oH-O0 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 00:00:36 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmK4C-0005x8-7p for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 00:00:34 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 16:00:17 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240644541:sNHT32921640" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBE00FMe003524; Tue, 13 Dec 2005 16:00:16 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 00:00:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 16:00:23 -0800 From: Cullen Jennings To: Lisa Dusseault , Julian Reschke CC: WebDav Message-ID: Thread-Topic: [Bug 11] Protection against XML Denial Of Service attacks Thread-Index: AcYAQWEvn4B3PGw0Edqd2AARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmK4C-0005x8-7p b2fbced1f9ed722f798822cbb62bc392 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks X-Archived-At: http://www.w3.org/mid/BFC4A097.653AB%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11081 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 00:00:44 +0000 Content-Transfer-Encoding: 7bit On 12/1/05 10:58 AM, "Lisa Dusseault" wrote: >> We discussed this during the conference call: 5xx is a server error, >> in particular 503 means "not now but maybe later". If a server detects >> a DOS attack, that's the last thing it would want to tell the client. Hmm, there might be some places you want this. This is not a Chair comment - just take it as a random individual comment. Imagine you had say 40,000 phones that all got their config information over DAV in some enterprise. And when the building power cycles, they all go and hit the server at the same time. I call this a Start of Service attack (SOS) but it is a lot like DDOS from server point of view. Some other protocols have found that returning a 5xx with a Retry-After time is very useful here. The retry time can be adjusted based on the depth of the queue in the server and the length of time the server has been in an overload state to push out the retries out to a point where the server has a chance of processing them instead of just sending the 503. The load balancer can realize the servers are overloaded and switch traffic to servers that can send the 503 at extremely high rates. There are also systems build to deal with very large DDOS attacks that do things like the following. Imagine that an ISP has a client with server with address X. The server tells the ISP that the server is under DDOS attack. The ISP has a system that "steals" address X and routes all traffic to that system. The first thing it does with any request is does some bounce back, such as a 503 with a retry after 0 seconds, if the client retries again, at least the client is doing some work. This often help differentiate good clients from DDOS attackers. Then the ISP system forwards the request down the original server but keeps track of where the requests are coming from. Now the ISP can see that 90% of the request are coming into it's network from one particular other AS. The ISP can rate limit down the request from the one AS at the edge of ISP and it can allow the other request from all the other AS to not be rate limited. This allows valid clients that are coming from different AS to not be effected, and clients in the same AS as attacker to be severely rate limited. It takes advantage of the 5xx to verify that there is a valid client at the sender of a request. This approach has been used to stop some very large scale DDOS attacks on large web sites. It works well for HTTP. Anyways, other protocols have found 5xx with Retry-After one of the best way to handle temporarily overload on the servers. I agree, if you know something is a DOS attack, the best thing might be not to respond but it is very difficult to distinguish which particular request during a DDOS attack is a bad one and which is good. Cullen (not as chair) From w3c-dist-auth-request@frink.w3.org Tue Dec 13 19:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmK9f-0007ke-1M for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:06:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17809 for ; Tue, 13 Dec 2005 19:04:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmK93-0006gE-OS for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 00:05:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmK91-0006fZ-9c for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 00:05:19 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmK8y-0008H3-Ad for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 00:05:19 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBE05FNK023203; Tue, 13 Dec 2005 16:05:15 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay8.apple.com (Apple SCV relay) with ESMTP id 5658718B; Tue, 13 Dec 2005 16:05:15 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: WebDav Content-Transfer-Encoding: 7bit From: Jim Luther Date: Tue, 13 Dec 2005 16:05:50 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (lisa.w3.org: domain of luther.j@apple.com designates 17.254.13.23 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.1 X-W3C-Scan-Sig: lisa.w3.org 1EmK8y-0008H3-Ad 3fa082663e360b9368489065c60e37f4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/B77F60FB-89D3-4DB6-AB98-17079CA54767@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11082 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 00:05:21 +0000 Content-Transfer-Encoding: 7bit I mark is as read, but don't bother to read it. Too much noise to signal. On Dec 13, 2005, at 3:25 PM, Cullen Jennings wrote: > I'd like some feedback on if people are OK with the bugzilla stuff > being > mailed to the list? Is it good? should we stop it and discuss on > list then > post resolution into bugzilla? From w3c-dist-auth-request@frink.w3.org Tue Dec 13 19:22:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmKPV-000617-FL for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 19:22:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22602 for ; Tue, 13 Dec 2005 19:21:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmKOU-0001YA-N1 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 00:21:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmKOM-0001XC-QZ for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 00:21:11 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmKOE-0004m2-TX for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 00:21:09 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 16:21:02 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240652516:sNHT32148004" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBE0Ksph018246; Tue, 13 Dec 2005 16:20:59 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 00:20:55 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 16:21:03 -0800 From: Cullen Jennings To: Julian Reschke CC: Lisa Dusseault , Wilfredo S=?ISO-8859-1?B?4Q==?=nchez Vega , Geoffrey M Clemm , WebDav Message-ID: Thread-Topic: ETags, next call, was: Notes on call from today ... Thread-Index: AcYARERIguXlRWw3Edqd2AARJEEJ/A== In-Reply-To: <439F4B88.1050908@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmKOE-0004m2-TX d734f70bc054adf589c0b94909f6f88d X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags, next call, was: Notes on call from today ... X-Archived-At: http://www.w3.org/mid/BFC4A56F.653C8%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11083 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 00:21:18 +0000 Content-Transfer-Encoding: 7bit On 12/13/05 2:30 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> I have still been looking for an answer on a question I asked long ago on >> this. If a client needs a strong ETag, and it gets a weak ETag, should the >> client poll the server until it gets a strong ETag? This seems to be the >> recommendation but no one seem to say "yes" or "no" to this? > > The answer is "no", unless the client happens to know that it talks to a > server that indeed upgrades the weak to a strong one later (which in > general will not be the case). > > Best regards, Julian Ok - thanks - that helps me think about this. From w3c-dist-auth-request@frink.w3.org Tue Dec 13 20:26:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmLPA-0000kJ-7g for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 20:26:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04297 for ; Tue, 13 Dec 2005 20:24:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmLNo-00084L-7Z for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 01:24:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmLNZ-00081q-9O for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 01:24:25 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmLNF-0001Ml-VL for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 01:24:24 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 13 Dec 2005 17:24:04 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBE1O0Me027747; Tue, 13 Dec 2005 17:24:01 -0800 (PST) Received: from 10.21.90.182 ([10.21.90.182]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 01:24:00 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 17:24:08 -0800 From: Cullen Jennings To: Julian Reschke , Jim Whitehead , Elias Sinderson , Geoffrey M Clemm CC: WebDav , Lisa Dusseault Message-ID: Thread-Topic: Tomorrows call Thread-Index: AcYATRRRUrCXqWxAEdqNnQARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmLNF-0001Ml-VL b8663e8c771c9a598ac29f2cf5017ffe X-Original-To: w3c-dist-auth@w3.org Subject: Tomorrows call X-Archived-At: http://www.w3.org/mid/BFC4B438.653E8%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11084 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 01:24:40 +0000 Content-Transfer-Encoding: 7bit Lisa left me a phone message and wanted to pass on to everyone she has been unable to send email from the conference she is at. She is not going to be able to make the call tomorrow as she is flying at that time. I should be able to join about an hour late. It seems like without Lisa on the call, Jim might be able to resolve any issues that came out of last Friday's edits. Cullen From w3c-dist-auth-request@frink.w3.org Tue Dec 13 20:34:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmLXR-0002QI-7A for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 20:34:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05560 for ; Tue, 13 Dec 2005 20:33:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmLWn-0002IG-It for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 01:33:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmLWi-0002HB-Tb for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 01:33:52 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EmLWg-0004QM-EW for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 01:33:52 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2005 17:33:49 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="377914012:sNHT35807500" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBE1XlQK006331; Tue, 13 Dec 2005 17:33:47 -0800 (PST) Received: from 10.21.90.182 ([10.21.90.182]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 01:33:47 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 17:33:54 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: Do server store arbitrary content Thread-Index: AcYATnGZsEgUn2xBEdqNnQARJEEJ/A== In-Reply-To: <439F4C38.8040407@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmLWg-0004QM-EW 6bca47f8ae371c9f48bb402fcc6ade77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/BFC4B682.653F4%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11085 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 01:33:57 +0000 Content-Transfer-Encoding: 7bit On 12/13/05 2:33 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> I have a questions for the WG. Can servers, within policy constraints, be >> expected to store arbitrary data. What I mean be the policy constraints is >> clearly a server might reject a request because it was too large, or it >> decided the file had a virus and it would not store it. But in general, can >> a client expect a WebDAV serve to be able to store say a HTML file? > > In general, no it can't. There are servers that accept only particular > types of content (such as something running on top of an XML database). > > Would it be useful to allow clients to discover support for these kinds > of things upfront? Sure, that's exactly I'd be happy to define a profile > and give it a compliance class name for use in the DAV header (for example). > > Best regards, Julian You keep mentioning the XML database but I would have expected them to save non XML data as more or less a BLOB. Am I missing something key here? From w3c-dist-auth-request@frink.w3.org Tue Dec 13 20:37:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmLaS-0004Co-DB for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 20:37:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06150 for ; Tue, 13 Dec 2005 20:36:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmLZr-0003NL-Ca for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 01:37:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmLZm-00038w-MV for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 01:37:02 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmLZf-0006jq-Bd for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 01:37:01 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 17:36:53 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="240668337:sNHT30677236" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBE1aoMe001151; Tue, 13 Dec 2005 17:36:51 -0800 (PST) Received: from 10.21.90.182 ([10.21.90.182]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 01:36:49 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 17:36:57 -0800 From: Cullen Jennings To: Jim Luther CC: WebDav Message-ID: Thread-Topic: Concern about bugzilla SPAM Thread-Index: AcYATt6tHPfI8mxCEdqNnQARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmLZf-0006jq-Bd f94c7e2a3c5163a8f530ff970894787e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/BFC4B739.653F8%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11086 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 01:37:07 +0000 Content-Transfer-Encoding: 7bit Yes - I've received two private requests so far saying people would rather not see it. Does anyone have ideas on how we could cut down the volume? We do need to keep using bugzilla as the tool to resolve bis. I'm not willing to consider changing that right now but if folks have ideas on how to improve the SNR of this list, that would be good. Cullen On 12/13/05 4:05 PM, "Jim Luther" wrote: > I mark is as read, but don't bother to read it. Too much noise to > signal. > > On Dec 13, 2005, at 3:25 PM, Cullen Jennings wrote: > >> I'd like some feedback on if people are OK with the bugzilla stuff >> being >> mailed to the list? Is it good? should we stop it and discuss on >> list then >> post resolution into bugzilla? From w3c-dist-auth-request@frink.w3.org Tue Dec 13 21:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMZN-00076t-0h for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12146 for ; Tue, 13 Dec 2005 21:39:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMYB-0000lS-Tb for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 02:39:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmMY0-0000jG-OE for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 02:39:16 +0000 Received: from mail.gmx.net ([213.165.64.21]) by lisa.w3.org with smtp (Exim 4.50) id 1EmMWT-0002V2-A6 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 02:39:16 +0000 Received: (qmail invoked by alias); 14 Dec 2005 02:37:39 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp020) with SMTP; 14 Dec 2005 03:37:39 +0100 X-Authenticated: #1915285 Message-ID: <439F850D.20004@gmx.de> Date: Wed, 14 Dec 2005 03:35:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Jim Whitehead , Elias Sinderson , Geoffrey M Clemm , WebDav , Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmMWT-0002V2-A6 46aff7de2714fde2a05973eece29cffa X-Original-To: w3c-dist-auth@w3.org Subject: Re: Tomorrows call X-Archived-At: http://www.w3.org/mid/439F850D.20004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11087 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 02:39:27 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Lisa left me a phone message and wanted to pass on to everyone she has been > unable to send email from the conference she is at. She is not going to be > able to make the call tomorrow as she is flying at that time. I should be > able to join about an hour late. > > It seems like without Lisa on the call, Jim might be able to resolve any > issues that came out of last Friday's edits. Sounds good to me... From w3c-dist-auth-request@frink.w3.org Tue Dec 13 21:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMZM-00076p-Ep for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12145 for ; Tue, 13 Dec 2005 21:39:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMYe-0000pQ-W1 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 02:39:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmMYb-0000ol-Lm for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 02:39:53 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EmMYX-0005EK-7D for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 02:39:52 +0000 ReceFrom w3c-dist-auth-request@frink.w3.org Tue Dec 13 21:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMZN-00076t-0h for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12146 for ; Tue, 13 Dec 2005 21:39:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMYB-0000lS-Tb for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 02:39:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmMY0-0000jG-OE for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 02:39:16 +0000 Received: from mail.gmx.net ([213.165.64.21]) by lisa.w3.org with smtp (Exim 4.50) id 1EmMWT-0002V2-A6 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 02:39:16 +0000 Received: (qmail invoked by alias); 14 Dec 2005 02:37:39 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp020) with SMTP; 14 Dec 2005 03:37:39 +0100 X-Authenticated: #1915285 Message-ID: <439F850D.20004@gmx.de> Date: Wed, 14 Dec 2005 03:35:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Jim Whitehead , Elias Sinderson , Geoffrey M Clemm , WebDav , Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmMWT-0002V2-A6 46aff7de2714fde2a05973eece29cffa X-Original-To: w3c-dist-auth@w3.org Subject: Re: Tomorrows call X-Archived-At: http://www.w3.org/mid/439F850D.20004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11087 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 02:39:27 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Lisa left me a phone message and wanted to pass on to everyone she has been > unable to send email from the conference she is at. She is not going to be > able to make the call tomorrow as she is flying at that time. I should be > able to join about an hour late. > > It seems like without Lisa on the call, Jim might be able to resolve any > issues that came out of last Friday's edits. Sounds good to me... From w3c-dist-auth-request@frink.w3.org Tue Dec 13 21:40:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMZM-00076p-Ep for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:40:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12145 for ; Tue, 13 Dec 2005 21:39:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMYe-0000pQ-W1 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 02:39:56 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmMYb-0000ol-Lm for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 02:39:53 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EmMYX-0005EK-7D for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 02:39:52 +0000 Received: (qmail invoked by alias); 14 Dec 2005 02:39:43 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp017) with SMTP; 14 Dec 2005 03:39:43 +0100 X-Authenticated: #1915285 Message-ID: <439F858B.1060505@gmx.de> Date: Wed, 14 Dec 2005 03:38:03 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmMYX-0005EK-7D be6b5f895104399c09ae2bcd68072bee X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/439F858B.1060505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11088 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 02:39:56 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 12/13/05 2:33 PM, "Julian Reschke" wrote: > >> Cullen Jennings wrote: >>> I have a questions for the WG. Can servers, within policy constraints, be >>> expected to store arbitrary data. What I mean be the policy constraints is >>> clearly a server might reject a request because it was too large, or it >>> decided the file had a virus and it would not store it. But in general, can >>> a client expect a WebDAV serve to be able to store say a HTML file? >> In general, no it can't. There are servers that accept only particular >> types of content (such as something running on top of an XML database). >> >> Would it be useful to allow clients to discover support for these kinds >> of things upfront? Sure, that's exactly I'd be happy to define a profile >> and give it a compliance class name for use in the DAV header (for example). >> >> Best regards, Julian > > You keep mentioning the XML database but I would have expected them to save > non XML data as more or less a BLOB. Am I missing something key here? You may or you may not. I can only provide hear-say here (I was referring to Slide running on top of certain Tamino instances; that's Software AG's XML database). Another example (as discussed before) would be a Calendar (CalDAV) or a Newsfeed (Atompub) server. Both may restrict the type of content you can put in specific places. Best regards, Julian ived: (qmail invoked by alias); 14 Dec 2005 02:39:43 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp017) with SMTP; 14 Dec 2005 03:39:43 +0100 X-Authenticated: #1915285 Message-ID: <439F858B.1060505@gmx.de> Date: Wed, 14 Dec 2005 03:38:03 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmMYX-0005EK-7D be6b5f895104399c09ae2bcd68072bee X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/439F858B.1060505@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11088 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 02:39:56 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 12/13/05 2:33 PM, "Julian Reschke" wrote: > >> Cullen Jennings wrote: >>> I have a questions for the WG. Can servers, within policy constraints, be >>> expected to store arbitrary data. What I mean be the policy constraints is >>> clearly a server might reject a request because it was too large, or it >>> decided the file had a virus and it would not store it. But in general, can >>> a client expect a WebDAV serve to be able to store say a HTML file? >> In general, no it can't. There are servers that accept only particular >> types of content (such as something running on top of an XML database). >> >> Would it be useful to allow clients to discover support for these kinds >> of things upfront? Sure, that's exactly I'd be happy to define a profile >> and give it a compliance class name for use in the DAV header (for example). >> >> Best regards, Julian > > You keep mentioning the XML database but I would have expected them to save > non XML data as more or less a BLOB. Am I missing something key here? You may or you may not. I can only provide hear-say here (I was referring to Slide running on top of certain Tamino instances; that's Software AG's XML database). Another example (as discussed before) would be a Calendar (CalDAV) or a Newsfeed (Atompub) server. Both may restrict the type of content you can put in specific places. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 21:56:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMou-0003Vv-EQ for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:56:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13459 for ; Tue, 13 Dec 2005 21:55:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMoA-0004d6-8M for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 02:55:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmMnz-0004cO-PA for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 02:55:47 +0000 Received: from mail.gmx.net ([213.165.64.21]) by lisa.w3.org with smtp (Exim 4.50) id 1EmMnu-0008WV-1Y for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 02:55:46 +0000 Received: (qmail invoked by alias); 14 Dec 2005 02:55:39 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp028) with SMTP; 14 Dec 2005 03:55:39 +0100 X-Authenticated: #1915285 Message-ID: <439F8946.8080803@gmx.de> Date: Wed, 14 Dec 2005 03:53:58 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmMnu-0008WV-1Y f33103d97bc019381606d6eaf50df269 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/439F8946.8080803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11089 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 02:55:58 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > This is clearly a very important topic - Julian points out he thinks it is > one of the few where if we can't solve it, we should not publish an update. That was probably a bit radical, but locking clarifications certainly *are* what people expect from us. > ... > We have the question is if the level of text in the GULP provides enough > information to for interoperable implementations. I have never argued that a > specification should tell people how they have to implement something but it > should be written in such a way that is implementable. From reading GULP, is > it clear how you might implement it? Is it clear that there is a polynomial GULP wasn't around when we implemented locking, but as far I can tell, it closely describes the model we actually did implement after reading the spec, reading the rationals (Yaron's WebDAV Book of Why, and having lots of conversations over here (which eventually resulted in people writing GULP down). > time algorithm to implement locking? We could specify locks in many > different ways - one would be to describe the invariants of they system with > regards to the locks. This is basically the approach GULP takes. The other > would be to provide certain algorithmic rules that results in the same set > of invariants. This is the approach most specifications take. Both have > their place and useful. Now, we could normatively use algorithm and still > provide the GULP style description of the invariants. On the conference > call, I felt this was what people wanted. Did I totally miss this? Thoughts? I have no strong feelings about this, as long as the result is as precise as what we have today with GULP. If there's a different approach to that which could work, I'm interested to see it. > It is hard to call consensus on this because it is hard for people to > express their opinion until they see some text but unless I hear otherwise, > I will assume this is the path we are somewhat proceeding down towards > coming up with some text ask for consensus on. > > Back to the first issue of what type of LOCKs are we building. This is by > far the more important issue. GULP provides one possible answer to this but > I'm not sure we have agreement on that. I will now refer to the PUT and > DELETE example that Julian put out earlier in this thread. My read of the > email is that we *do* agree on how the PUT would work. I'm not sure we agree Yes, that's because PUT affects the "lockable" state of the resource (something we at some point need to define, and which RFC2518bis currently doesn't). > on how the DELETE should work. We might agree but I can't tell. Let's > assume we are working on a server that does not support bind. I'm not clear > how DELETE works. If /foo/a and /foo/b both point at the same resource, and > /foo/b is deleted, is there a guarantee that the resource will not be > deleted and that /foo/a will still point at the resource? Does the spec No, there's no guarantee for that. Indeed this is the containment model RFC2518 *required* people to implement, and which we got rid of. > allow the server to choose a model and some might allow it and some might > not? If so, do we need to allow the server to be able to select a locking That's my understanding. RFC2518bis allows servers to vary, while BIND requires specific semantics (where destroying the resource and removing URL mappings to the resource in general are separate tasks). > model that follows this? There seems to be questions around depth and depth > infinity, do we agree on these. I think GULP works just fine. If you do have an hypothetical server that upon DELETEing /foo/b also destroys the resource mapped to, and all other bindings to it, then yes, you'll need the lock token even though the resource was only locked through /foo/a. The difference here is not in the locking model (it's the same), but in the implemented semantics of DELETE. As a matter of fact, the same question could be asked regarding access permissions on the container collections. If you do have /foo1/a and /foo2/a mapped to the same resource, do yo need DAV:unbind privileges for both if you DELETE /foo1/a? The answer depends on what your server is doing upon DELETE. > These are probably the wrong questions but what I am trying to do is > separate this into two parts. 1 is how locks work, 2 is how we specify them > in bis. On the topic of how it works, does anyone care to help me frame the > really key question to decide how it works? I think the best starting point is indeed GULP, and to let people raise potential problems they see with that model. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 22:04:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMwA-0005Z2-NS for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 22:04:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14216 for ; Tue, 13 Dec 2005 22:03:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMvT-0006ev-Ix for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 03:03:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmMvP-0006eA-5w for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 03:03:27 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EmMvL-0000c7-Nr for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 03:03:26 +0000 Received: (qmail invoked by alias); 14 Dec 2005 03:03:17 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp036) with SMTP; 14 Dec 2005 04:03:17 +0100 X-Authenticated: #1915285 Message-ID: <439F8B0F.3000208@gmx.de> Date: Wed, 14 Dec 2005 04:01:35 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EmMvL-0000c7-Nr 30a95490b747cd7f0a934b388e418dbf X-Original-To: w3c-dist-auth@w3.org Subject: Re: New compliance class - was Re: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/439F8B0F.3000208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11090 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 03:03:31 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I just read section 17 and, well, I'm certainly not clear how versioning > works. > > Is there a need for a client to do something different based on if it is > talking to a server that does all the MUST in 2518 and a server that does > all the MUST in bis. If so, the description in 17.1 may be problematic. If I don't think so. As a matter of fact, unless somebody can come up with as use case, defining a new compliance class seems to be completely useless. > this is the case, can someone provide an concrete example of this? If there > is no case of this, we can use the same class for all the MUSTs in bis. If > not we will need a way to tell if a server does all the MUST in 2518 or all > the MUST in bis. > > The description in 17.2 leaves me very unclear of what needs to be > implemented to be class 2. By "support" do you mean implement the MUSTs? The > SHOULDs? the MAYs? I agree that the distinction is extremely unclear. As far as I can tell, there are lots of MUST level requirements in the spec which are about locking, thus do not need to be implemented on a non-class-2 resource. > Any reason not to rename "class bis" to "class 3". People may read "3" as including "2", which would be a bad thing. Locking is optional in RFC2518, and it still is in BIS. Again, we wouldn't need to think about this if we didn't have that new compliance class at all. It would be nice if those who think we need it could provide an example where a client would actually be able to make use out of this information. > What is our take on Forced-Authenticate. Do we have a use case that requires > us to create a new class for this? As far as I can tell, the consensus was to remove it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 22:05:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMxM-0006et-2O for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 22:05:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14285 for ; Tue, 13 Dec 2005 22:04:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmMwf-0006nc-Nr for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 03:04:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmMwd-0006mx-QL for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 03:04:43 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EmMwW-0003l2-Kv for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 03:04:43 +0000 Received: (qmail invoked by alias); 14 Dec 2005 03:04:35 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp019) with SMTP; 14 Dec 2005 04:04:35 +0100 X-Authenticated: #1915285 Message-ID: <439F8B5D.4040806@gmx.de> Date: Wed, 14 Dec 2005 04:02:53 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Jim Luther , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmMwW-0003l2-Kv 0fa6ceeed5dbb6679287c61b689c843d X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/439F8B5D.4040806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11091 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 03:04:45 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Yes - I've received two private requests so far saying people would rather > not see it. > > Does anyone have ideas on how we could cut down the volume? We do need to > keep using bugzilla as the tool to resolve bis. I'm not willing to consider > changing that right now but if folks have ideas on how to improve the SNR of > this list, that would be good. Agreed. I think the right approach would be not to discuss in BugZilla, but to only use it for the actual resolution process. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 13 22:39:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmNU0-0007py-6P for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 22:39:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17080 for ; Tue, 13 Dec 2005 22:38:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmNTG-0005Qo-Ne for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 03:38:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmNTA-0005Or-42; Wed, 14 Dec 2005 03:38:20 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmNT1-0008WC-QD; Wed, 14 Dec 2005 03:38:18 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBE3c59r022441; Tue, 13 Dec 2005 22:38:05 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBE3c5Kn118186; Tue, 13 Dec 2005 22:38:05 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBE3c5Uu007804; Tue, 13 Dec 2005 22:38:05 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBE3c5tE007800; Tue, 13 Dec 2005 22:38:05 -0500 In-Reply-To: <439F8B0F.3000208@gmx.de> To: Julian Reschke Cc: Cullen Jennings , WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 13 Dec 2005 22:38:02 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/13/2005 22:38:04, Serialize complete at 12/13/2005 22:38:04 Content-Type: multipart/alternative; boundary="=_alternative 0013FB65852570D7_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmNT1-0008WC-QD abbee6821684dc7ed071d8fd4ebcebd9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: New compliance class - was Re: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/OF29481505.63F45032-ON852570D7.0013C9BB-852570D7.0013FBF8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11092 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 03:38:26 +0000 This is a multipart message in MIME format. --=_alternative 0013FB65852570D7_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/13/2005 10:01:35 PM: > Cullen Jennings wrote: > > > > I just read section 17 and, well, I'm certainly not clear how versioning > > works. > > > > Is there a need for a client to do something different based on if it is > > talking to a server that does all the MUST in 2518 and a server that does > > all the MUST in bis. If so, the description in 17.1 may be problematic. If > > I don't think so. As a matter of fact, unless somebody can come up with > as use case, defining a new compliance class seems to be completely useless. I agree with Julian, and I haven't yet seen an even partially compelling use case that motivates the introduction of a new compliance class. I suggest that unless such a compelling use case is identified very soon, this matter be resolved by not introducing a new compliance class. > > What is our take on Forced-Authenticate. Do we have a use case that requires > > us to create a new class for this? > > As far as I can tell, the consensus was to remove it. That was my understanding as well. Cheers, Geoff --=_alternative 0013FB65852570D7_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/13/2005 10:01:35 PM:

> Cullen Jennings wrote:
> >
> > I just read section 17 and, well, I'm certainly not clear how versioning
> > works.
> >
> > Is there a need for a client to do something different based on if it is
> > talking to a server that does all the MUST in 2518  and a server that does
> > all the MUST in bis. If so, the description in 17.1 may be problematic. If
>
> I don't think so. As a matter of fact, unless somebody can come up with
> as use case, defining a new compliance class seems to be completely useless.

I agree with Julian, and I haven't yet seen an even partially compelling
use case that motivates the introduction of a new compliance class.  I suggest
that unless such a compelling use case is identified very soon, this matter
be resolved by not introducing a new compliance class.

> > What is our take on Forced-Authenticate. Do we have a use case that requires
> > us to create a new class for this?
>
> As far as I can tell, the consensus was to remove it.
That was my understanding as well.

Cheers,
Geoff

--=_alternative 0013FB65852570D7_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 13 22:46:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmNbQ-0000nT-8P for webdav-archive@megatron.ietf.org; Tue, 13 Dec 2005 22:46:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18046 for ; Tue, 13 Dec 2005 22:45:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmNaQ-0007cg-62 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 03:45:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmNaO-0007bo-0U; Wed, 14 Dec 2005 03:45:48 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmNaL-0000Et-CQ; Wed, 14 Dec 2005 03:45:47 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBE3jinJ029812; Tue, 13 Dec 2005 22:45:44 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBE3jiKn124132; Tue, 13 Dec 2005 22:45:44 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBE3jh8u005613; Tue, 13 Dec 2005 22:45:44 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBE3jhcS005610; Tue, 13 Dec 2005 22:45:43 -0500 In-Reply-To: <439F8946.8080803@gmx.de> To: Julian Reschke Cc: Cullen Jennings , WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 13 Dec 2005 22:45:42 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/13/2005 22:45:43, Serialize complete at 12/13/2005 22:45:43 Content-Type: multipart/alternative; boundary="=_alternative 0014AF12852570D7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmNaL-0000Et-CQ ccdeebfc78e2994ede77823499869da4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF3AE7B513.8D2DB5B4-ON852570D7.001471C4-852570D7.0014AF89@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11093 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 03:45:50 +0000 This is a multipart message in MIME format. --=_alternative 0014AF12852570D7_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/13/2005 09:53:58 PM: > Cullen Jennings wrote: > > ... On the topic of how it works, does anyone care to help me frame the > > really key question to decide how it works? > > I think the best starting point is indeed GULP, and to let people raise > potential problems they see with that model. I agree. Cheers, Geoff --=_alternative 0014AF12852570D7_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/13/2005 09:53:58 PM:

> Cullen Jennings wrote:

> > ... On the topic of how it works, does anyone care to help me frame the
> > really key question to decide how it works?
>
> I think the best starting point is indeed GULP, and to let people raise
> potential problems they see with that model.
I agree.

Cheers,
Geoff
  --=_alternative 0014AF12852570D7_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 00:08:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmOsp-00071s-2A for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 00:08:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26057 for ; Wed, 14 Dec 2005 00:07:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmOrX-00064o-K7 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 05:07:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmOrN-00063j-RP for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 05:07:25 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1EmOrK-0002ac-S6 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 05:07:25 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Dec 2005 21:07:22 -0800 X-IronPort-AV: i="3.99,250,1131350400"; d="scan'208"; a="684395730:sNHT35062172" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBE57J70006588; Tue, 13 Dec 2005 21:07:19 -0800 (PST) Received: from 10.21.96.130 ([10.21.96.130]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 05:07:18 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 21:07:24 -0800 From: Cullen Jennings To: Julian Reschke CC: WebDav Message-ID: Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcYAbET0g1cHbGxfEdq0TwARJEEJ/A== In-Reply-To: <439F8946.8080803@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmOrK-0002ac-S6 c8f0778f5d9739f78294ea5fdb0d5568 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/BFC4E88C.6545E%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11094 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 05:07:35 +0000 Content-Transfer-Encoding: 7bit Ok, I'll wait a bit and see if others provide comments on any of this, but given what you are saying here, I think I can imagine how to propose a way of including GULP that meets various folks needs. On 12/13/05 6:53 PM, "Julian Reschke" wrote: > Cullen Jennings wrote: >> >> This is clearly a very important topic - Julian points out he thinks it is >> one of the few where if we can't solve it, we should not publish an update. > > That was probably a bit radical, but locking clarifications certainly > *are* what people expect from us. > >> ... >> We have the question is if the level of text in the GULP provides enough >> information to for interoperable implementations. I have never argued that a >> specification should tell people how they have to implement something but it >> should be written in such a way that is implementable. From reading GULP, is >> it clear how you might implement it? Is it clear that there is a polynomial > > GULP wasn't around when we implemented locking, but as far I can tell, > it closely describes the model we actually did implement after reading > the spec, reading the rationals (Yaron's WebDAV Book of Why, > and having lots of conversations over > here (which eventually resulted in people writing GULP down). > >> time algorithm to implement locking? We could specify locks in many >> different ways - one would be to describe the invariants of they system with >> regards to the locks. This is basically the approach GULP takes. The other >> would be to provide certain algorithmic rules that results in the same set >> of invariants. This is the approach most specifications take. Both have >> their place and useful. Now, we could normatively use algorithm and still >> provide the GULP style description of the invariants. On the conference >> call, I felt this was what people wanted. Did I totally miss this? Thoughts? > > I have no strong feelings about this, as long as the result is as > precise as what we have today with GULP. If there's a different approach > to that which could work, I'm interested to see it. > >> It is hard to call consensus on this because it is hard for people to >> express their opinion until they see some text but unless I hear otherwise, >> I will assume this is the path we are somewhat proceeding down towards >> coming up with some text ask for consensus on. >> >> Back to the first issue of what type of LOCKs are we building. This is by >> far the more important issue. GULP provides one possible answer to this but >> I'm not sure we have agreement on that. I will now refer to the PUT and >> DELETE example that Julian put out earlier in this thread. My read of the >> email is that we *do* agree on how the PUT would work. I'm not sure we agree > > Yes, that's because PUT affects the "lockable" state of the resource > (something we at some point need to define, and which RFC2518bis > currently doesn't). > >> on how the DELETE should work. We might agree but I can't tell. Let's >> assume we are working on a server that does not support bind. I'm not clear >> how DELETE works. If /foo/a and /foo/b both point at the same resource, and >> /foo/b is deleted, is there a guarantee that the resource will not be >> deleted and that /foo/a will still point at the resource? Does the spec > > No, there's no guarantee for that. Indeed this is the containment model > RFC2518 *required* people to implement, and which we got rid of. > >> allow the server to choose a model and some might allow it and some might >> not? If so, do we need to allow the server to be able to select a locking > > That's my understanding. RFC2518bis allows servers to vary, while BIND > requires specific semantics (where destroying the resource and removing > URL mappings to the resource in general are separate tasks). > >> model that follows this? There seems to be questions around depth and depth >> infinity, do we agree on these. > > I think GULP works just fine. > > If you do have an hypothetical server that upon DELETEing /foo/b also > destroys the resource mapped to, and all other bindings to it, then yes, > you'll need the lock token even though the resource was only locked > through /foo/a. The difference here is not in the locking model (it's > the same), but in the implemented semantics of DELETE. > > As a matter of fact, the same question could be asked regarding access > permissions on the container collections. If you do have /foo1/a and > /foo2/a mapped to the same resource, do yo need DAV:unbind privileges > for both if you DELETE /foo1/a? The answer depends on what your server > is doing upon DELETE. > >> These are probably the wrong questions but what I am trying to do is >> separate this into two parts. 1 is how locks work, 2 is how we specify them >> in bis. On the topic of how it works, does anyone care to help me frame the >> really key question to decide how it works? > > I think the best starting point is indeed GULP, and to let people raise > potential problems they see with that model. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 04:21:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmSpf-0000dW-Ru for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 04:21:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24834 for ; Wed, 14 Dec 2005 04:20:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmSnp-0000WP-2r for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 09:20:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmSne-0000VY-Ez for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 09:19:50 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmSna-0002HJ-0h for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 09:19:49 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBE9JUKc001711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Dec 2005 01:19:31 -0800 (PST) Message-ID: <439FE3A9.7070605@cse.ucsc.edu> Date: Wed, 14 Dec 2005 01:19:37 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Julian Reschke , Jim Whitehead , Geoffrey M Clemm , WebDav , Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmSna-0002HJ-0h b2db6e627e329dda104bb469c838e5d8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Tomorrows call X-Archived-At: http://www.w3.org/mid/439FE3A9.7070605@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11095 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 09:20:01 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >[...] It seems like without Lisa on the call, Jim might be able to resolve any >issues that came out of last Friday's edits. > That sounds like a plan, although there are a number of lock related issues remaining... Let's try to work through any editing session issues quickly so there is enough time to make some good progress on them. Cheers, Elias From w3c-dist-auth-request@frink.w3.org Wed Dec 14 04:28:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmSwD-0002J6-3e for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 04:28:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25506 for ; Wed, 14 Dec 2005 04:27:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmSv9-0001mt-2I for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 09:27:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmSv6-0001mL-TA for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 09:27:33 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EmSv3-0002bM-3t for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 09:27:32 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBE9R9lw003304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Dec 2005 01:27:09 -0800 (PST) Message-ID: <439FE574.3080302@cse.ucsc.edu> Date: Wed, 14 Dec 2005 01:27:16 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EmSv3-0002bM-3t ec30e8a15908af9b7dc11c2c2acf2560 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/439FE574.3080302@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11096 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 09:27:35 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >I'd like some feedback on if people are OK with the bugzilla stuff being >mailed to the list? > It depends on how closely someone is following a given issue, but much of the email is noise. >Is it good? > IMO, only the comments are really useful -- state change messages are only useful for those most directly concerned with an issue. >should we stop it and discuss on list then post resolution into bugzilla? > > I think this would generally be a good path to follow. I'd be perfectly happy with links to discussion threads in the list archive being posted as the resolution. Unless anyone feels strongly otherwise, we can start removing the mailing list as a contact for bugs as we update them during tomorrows' telecon. Cheers, Elias From w3c-dist-auth-request@frink.w3.org Wed Dec 14 04:33:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmT0s-0003V0-EL for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 04:33:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25972 for ; Wed, 14 Dec 2005 04:32:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmSzp-0003cf-R2 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 09:32:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmSzo-0003c6-2l for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 09:32:24 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by lisa.w3.org with esmtp (Exim 4.50) id 1EmSzl-0004B3-4t for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 09:32:23 +0000 Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id E913F44B89; Wed, 14 Dec 2005 10:35:54 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav From: Stefan Eissing Date: Wed, 14 Dec 2005 10:32:16 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) Received-SPF: none (lisa.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EmSzl-0004B3-4t 860ab018411fc98a8a353d50afe7abd6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/bd0a4f52f12f99be539fdb4fc3146eac@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11097 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 09:32:25 +0000 Content-Transfer-Encoding: 7bit It is good to see new/resolved issues notifications on the mailliing list. But the huge amount seems to be state changes which I personally am not concerned about. So nowadays, I just delete bugzilla mails without looking at them. +1 for avoiding notification on trivial changes. //Stefan Am 14.12.2005 um 00:25 schrieb Cullen Jennings: > > > I'd like some feedback on if people are OK with the bugzilla stuff > being > mailed to the list? Is it good? should we stop it and discuss on list > then > post resolution into bugzilla? > > > > > On 12/8/05 9:36 AM, "DigitallySmooth" > wrote: > >> >> how do I get off this list please? >> >> ----- Original Message ----- >> From: >> To: >> Sent: Wednesday, December 07, 2005 1:47 PM >> Subject: [Bug 120] DEEP_LOCK_ERROR_STATUS >> >> >>> >>> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=120 >>> >>> lisa@osafoundation.org changed: >>> >>> What |Removed |Added >>> --------------------------------------------------------------------- >>> ----- >> -- >>> Status|NEW |RESOLVED >>> Resolution| |FIXED >>> >>> >>> >>> >>> >>> ------- You are receiving this mail because: ------- >>> You are the QA contact for the bug, or are watching the QA contact. >>> >>> > From w3c-dist-auth-request@frink.w3.org Wed Dec 14 12:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaCv-0004DY-C5 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 12:14:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25274 for ; Wed, 14 Dec 2005 12:13:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmaAb-0000VU-Mb for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 17:12:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmaAQ-0000RQ-6i for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 17:11:50 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Ema7I-0002WP-Fd for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 17:11:48 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBEH8VZa014173 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Dec 2005 09:08:31 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/alternative; boundary=Apple-Mail-7--493395343 Message-Id: Cc: WebDav From: Jim Whitehead Date: Wed, 14 Dec 2005 09:08:30 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Ema7I-0002WP-Fd aa444ecf7a8a160f62a3a6a020edea1b X-Original-To: w3c-dist-auth@w3.org Subject: Re: New compliance class - was Re: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/BC202484-E9E8-4F36-8995-DB26D6DE887D@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11098 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 17:12:01 +0000 --Apple-Mail-7--493395343 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit My rationale for adding a new compliance class is to ensure that clients know whether a server is using the 2518 semantics or 2518bis semantics. There are a lot of minor changes in semantics between the two specifications. I imagine there are some cases where a client would want to know this. Let me push back, and say that, given we are adding many MUST and SHOULD level requirements to the specification, I think the burden of proof lies on showing that there is no possible reason why a client would ever want to discover whether a server supports 2518 or 2518bis. I haven't yet heard even a partially compelling argument for this :-) - Jim On Dec 13, 2005, at 7:38 PM, Geoffrey M Clemm wrote: > > Julian wrote on 12/13/2005 10:01:35 PM: > > > Cullen Jennings wrote: > > > > > > I just read section 17 and, well, I'm certainly not clear how > versioning > > > works. > > > > > > Is there a need for a client to do something different based on > if it is > > > talking to a server that does all the MUST in 2518 and a > server that does > > > all the MUST in bis. If so, the description in 17.1 may be > problematic. If > > > > I don't think so. As a matter of fact, unless somebody can come > up with > > as use case, defining a new compliance class seems to be > completely useless. > > I agree with Julian, and I haven't yet seen an even partially > compelling > use case that motivates the introduction of a new compliance > class. I suggest > that unless such a compelling use case is identified very soon, > this matter > be resolved by not introducing a new compliance class. > > > > What is our take on Forced-Authenticate. Do we have a use case > that requires > > > us to create a new class for this? > > > > As far as I can tell, the consensus was to remove it. > > That was my understanding as well. > > Cheers, > Geoff > --Apple-Mail-7--493395343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My rationale for adding a = new compliance class is to ensure that clients know whether a server is = using the 2518 semantics or 2518bis semantics. There are a lot of minor = changes in semantics between the two specifications. I imagine there are = some cases where a client would want to know this.

Let me push back, and say = that, given we are adding many MUST and SHOULD level requirements to the = specification, I think the burden of proof lies on showing that there is = no possible reason why a client would ever want to discover whether a = server supports 2518 or 2518bis. I haven't yet heard even a partially = compelling argument for this :-)

- Jim


On Dec 13, 2005, = at 7:38 PM, Geoffrey M Clemm wrote:


Julian wrote on 12/13/2005 10:01:35 PM:

> = Cullen Jennings wrote:
> >
> > I just read section = 17 and, well, I'm certainly not clear how versioning
> > = works.
> >
> > Is there a need for a client to do = something different based on if it is
> > talking to a server = that does all the MUST in 2518 =A0and a server that does
> > = all the MUST in bis. If so, the description in 17.1 may be problematic. = If
>
> I don't think so. As a matter of fact, unless = somebody can come up with
> as use case, defining a new = compliance class seems to be completely useless.
=
I agree with Julian, and I haven't yet seen an = even partially compelling
use case = that motivates the introduction of a new compliance class. =A0I = suggest
that unless such a = compelling use case is identified very soon, this matter =
be resolved by not introducing a new compliance = class.

> > What is our = take on Forced-Authenticate. Do we have a use case that requires
= > > us to create a new class for this?
>
> As far = as I can tell, the consensus was to remove it.
 =
That was my understanding as well. =

Cheers,
Geoff

=

= --Apple-Mail-7--493395343-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 12:29:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaRf-0001Ho-Qw for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 12:29:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27735 for ; Wed, 14 Dec 2005 12:28:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmaQQ-0006Pi-NF for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 17:28:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmaQG-0006OE-Ki for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 17:28:12 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmaQ8-0005LF-Am for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 17:28:12 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBEHRFRF009059 for ; Wed, 14 Dec 2005 12:27:15 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBEHRFMh123236 for ; Wed, 14 Dec 2005 12:27:15 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBEHREga023742 for ; Wed, 14 Dec 2005 12:27:15 -0500 Received: from d01mc261.pok.ibm.com (d01mc261.pok.ibm.com [9.56.227.238]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBEHREcn023729; Wed, 14 Dec 2005 12:27:14 -0500 In-Reply-To: To: Jim Whitehead Cc: WebDav MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 14 Dec 2005 12:27:12 -0500 X-MIMETrack: Serialize by Router on D01MC261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 12/14/2005 12:27:14, Serialize complete at 12/14/2005 12:27:14 Content-Type: multipart/alternative; boundary="=_alternative 005FDCC9852570D7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmaQ8-0005LF-Am 546d2b9cf1e531fffc3647a5c8cc9f88 X-Original-To: w3c-dist-auth@w3.org Subject: Re: New compliance class - was Re: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/OF4426ABA9.7B76390E-ON852570D7.005F433D-852570D7.005FDE17@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11099 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 17:28:22 +0000 This is a multipart message in MIME format. --=_alternative 005FDCC9852570D7_= Content-Type: text/plain; charset="US-ASCII" One doesn't (or at least, I don't :-) add things to a specification based on "not being able to prove they aren't needed". You cannot think of a single compelling case where a client would want to be able to distinguish the 2518bis semantics from the 2518 semantics? I'd suggest we just take this as a sign that we have succeeded in achieving backward compatibility, and so no new compliance class is needed. Cheers, Geoff My rationale for adding a new compliance class is to ensure that clients know whether a server is using the 2518 semantics or 2518bis semantics. There are a lot of minor changes in semantics between the two specifications. I imagine there are some cases where a client would want to know this. Let me push back, and say that, given we are adding many MUST and SHOULD level requirements to the specification, I think the burden of proof lies on showing that there is no possible reason why a client would ever want to discover whether a server supports 2518 or 2518bis. I haven't yet heard even a partially compelling argument for this :-) - Jim On Dec 13, 2005, at 7:38 PM, Geoffrey M Clemm wrote: Julian wrote on 12/13/2005 10:01:35 PM: > Cullen Jennings wrote: > > > > I just read section 17 and, well, I'm certainly not clear how versioning > > works. > > > > Is there a need for a client to do something different based on if it is > > talking to a server that does all the MUST in 2518 and a server that does > > all the MUST in bis. If so, the description in 17.1 may be problematic. If > > I don't think so. As a matter of fact, unless somebody can come up with > as use case, defining a new compliance class seems to be completely useless. I agree with Julian, and I haven't yet seen an even partially compelling use case that motivates the introduction of a new compliance class. I suggest that unless such a compelling use case is identified very soon, this matter be resolved by not introducing a new compliance class. > > What is our take on Forced-Authenticate. Do we have a use case that requires > > us to create a new class for this? > > As far as I can tell, the consensus was to remove it. That was my understanding as well. Cheers, Geoff --=_alternative 005FDCC9852570D7_= Content-Type: text/html; charset="US-ASCII"
One doesn't (or at least, I don't :-) add things to a specification based on "not being able to prove they aren't needed".

You cannot think of a single compelling case where a client would want to be able to distinguish the 2518bis semantics from the 2518 semantics?

I'd suggest we just take this as a sign that we have succeeded in achieving backward compatibility, and so no new compliance class is needed.

Cheers,
Geoff




My rationale for adding a new compliance class is to ensure that clients know whether a server is using the 2518 semantics or 2518bis semantics. There are a lot of minor changes in semantics between the two specifications. I imagine there are some cases where a client would want to know this.

Let me push back, and say that, given we are adding many MUST and SHOULD level requirements to the specification, I think the burden of proof lies on showing that there is no possible reason why a client would ever want to discover whether a server supports 2518 or 2518bis. I haven't yet heard even a partially compelling argument for this :-)

- Jim


On Dec 13, 2005, at 7:38 PM, Geoffrey M Clemm wrote:


Julian wrote on 12/13/2005 10:01:35 PM:

> Cullen Jennings wrote:
> >
> > I just read section 17 and, well, I'm certainly not clear how versioning
> > works.
> >
> > Is there a need for a client to do something different based on if it is
> > talking to a server that does all the MUST in 2518  and a server that does
> > all the MUST in bis. If so, the description in 17.1 may be problematic. If
>
> I don't think so. As a matter of fact, unless somebody can come up with
> as use case, defining a new compliance class seems to be completely useless.

I agree with Julian, and I haven't yet seen an even partially compelling
use case that motivates the introduction of a new compliance class.  I suggest
that unless such a compelling use case is identified very soon, this matter
be resolved by not introducing a new compliance class.

> > What is our take on Forced-Authenticate. Do we have a use case that requires
> > us to create a new class for this?
>
> As far as I can tell, the consensus was to remove it.

That was my understanding as well.

Cheers,
Geoff


--=_alternative 005FDCC9852570D7_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 12:41:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmadJ-00005O-CO for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 12:41:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00120 for ; Wed, 14 Dec 2005 12:40:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emac9-0003Yj-2w for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 17:40:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emac5-0003Xg-TN for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 17:40:26 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmaZW-0007Fq-Gb for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 17:40:24 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBEHbR3C024680 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Dec 2005 09:37:27 -0800 (PST) In-Reply-To: <439DE3DF.8030206@gmx.de> References: <4399DC7A.60209@gmx.de> <439A092F.6090806@cse.ucsc.edu> <439AEE34.2050604@gmx.de> <439DE3DF.8030206@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Jim Whitehead , WebDAV Content-Transfer-Encoding: 7bit From: Jim Whitehead Date: Wed, 14 Dec 2005 09:37:26 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmaZW-0007Fq-Gb c19ddaca26297166c1f185760b730870 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Review of RFC2518bis pre-draft X-Archived-At: http://www.w3.org/mid/DCE2929D-2514-485C-9B86-C1F412F43702@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11100 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 17:40:29 +0000 Content-Transfer-Encoding: 7bit Julian and I discussed the remaining issues during the 12/14/2005 teleconference. Resolution marked below. On Dec 12, 2005, at 12:55 PM, Julian Reschke wrote: > > Jim Whitehead wrote: > >>>>> - XML in example to be fixed, for instance whitespace in >>>>> D:getlastmodified >>>> Fixed the example. However, since DAV:get* properties are based >>>> upon definitions made in rfc2616, LWS may be found in some >>>> implementations -- explanatory text added to section 14. >>> >>> a) the date doesn't use rfc1123 syntax >> Um, my understanding is that we haven't decided to change the >> format of DAV:getlastmodified, which still uses rfc1123 date format. > > Yes, but the example doesn't use it. Agreed. The example in Section "Example - Using 'allprop'", in the propfind response, has a getlastmodified header returned. This header does not use the rfc1123 date format. I agree this should be modified to use the correct date format. >>> b) I object to that change, LWS is not part of the value of the >>> header, that is whitespace is not allowed here (any evidence of a >>> server adding this???). Do I need to open an issue for that? >> Well, the issue here is what to do concerning these statements in >> RFC 2616, section 4.2: >> The field value MAY be preceded by any amount of LWS, though a >> single SP is preferred. >> field-value = *( field-content | LWS ) >> So, if you view the contents of a header as anything to the right >> of the colon, then the LWS is part of the value, and we need to >> state something about it. >> Another position we could take is to state that the property >> values only include the field-content: >> field-content = > and consisting of either *TEXT or >> combinations >> of token, separators, and quoted-string> >> This is a stronger statement. However, it seemed to me that some >> server, somewhere, is bound to accidentally put in some LWS either >> before or after the field-content. As a result, the more >> interoperable approach was to put in the text stating that LWS >> might appear, and to be prepared to handle it. That said, the use >> of the word "value" in: >> For properties defined based on HTTP GET response headers (DAV:get*), >> the value could include LWS as defined in > target="RFC2616"/>, section 4.2. >> Is ambiguous. A better approach would be to say: >> For properties defined based on HTTP GET response headers >> (DAV:get*), the value of the property is intended to be the field- >> content (as defined in Section 4.2 of RFC2616) of the >> corresponding header. However, RFC 2616 does permit the protocol >> octet stream prior to the field-content to contain by LWS, and >> after the field-content to have LWS. As a result, server >> implementations SHOULD use just the field-content, and clients >> MUST be prepared to strip LWS. > > Do we have evidence of servers putting in LWS, and clients ignoring > it? Otherwise I'd prefer to stick with the most simple approach > (forbidding the LWS). Julian and I agreed to include language along the lines of servers SHOULD just use the field-content as the value of the property, and SHOULD NOT put LWS before or after the field-content as the value of the property. We decided that no statement about client behavior was needed (they'll strip the LWS if they ever see it anyway). > >>>>> 8.7 DELETE [...] This is still a lame way to introduce >>>>> DELETE. [...] >>>>> 8.9.5 Status Codes [...] 403 (Forbidden) [...] Confusing. >>>>> Servers may treat this as a nop, just returning 200. Just be >>>>> silent about it. >>>> Discussed this but left the text in, as the semantics were >>>> defined in 2518 (see similar comment below). >>> >>> Well, it was mentioned, but the spec never contained a >>> requirement for servers to reject this. >> I'm not following your reply. What is "this"? > > This = rejecting MOVE / COPY requests where source and destination > are the same. Julian and I agreed to change the language from RECOMMENDED use of 403 to "MAY occur" (MOVE - section 8.10.4). The section for COPY appears to be fine. > >>>>> 12.1 Response headers [...] This section doesn't provide any >>>>> useful information. In particular, the second sentence seems to >>>>> be completely out of context. >>>> Rewrote this section (originally added following discussion of >>>> issue 47). Second sentence has been removed. >>> >>> It now says: >>> >>> HTTP defines the Location header to indicate a preferred URL >>> for the >>> resource that was addressed in the Request-URI (e.g. in >>> response to >>> successful PUT requests or in redirect responses). However, >>> use of >>> this header creates ambiguity when there are URLs in the body >>> of the >>> response, as with Multi-Status. Thus, use of the Location header >>> with the Multi-Status response is intentionally undefined. >>> >>> I still don't understand this. How does the presence of a >>> Location header create an ambiguity here? The URLs in the >>> response mean exactly what this spec defines them to mean, and >>> there is absolutely no ambiguity here. >> As we have discussed in prior teleconferences, the potential >> ambiguity comes from this: When there is just the Request-URI, >> there is only ever one resource being discussed in the request or >> response. With the multistatus response, there are potentially may >> resources being discussed in the response. > > HTTP says ( rfc2616.html#rfc.section.14.30>): > > "The Location response-header field is used to redirect the > recipient to a location other than the Request-URI for completion > of the request or identification of a new resource. For 201 > (Created) responses, the Location is that of the new resource which > was created by the request. For 3xx responses, the location SHOULD > indicate the server's preferred URI for automatic redirection to > the resource." > > I'm not sure how anybody could come to the assumption that things > are different in case of a multistatus. > Julian and I agreed to keep the draft as-is on this issue. We agreed that there was a misunderstanding about the original issue (Content- Location vs Location), but that this confusion did lead us to make a clarification that at least Jim thought was a good idea. >>> the wire (see [RFC3986], section 2.1). For example, it is >>> illegal to >>> use a space character or double-quote in a URI. URIs >>> appearing in >>> PROPFIND or PROPPATCH XML bodies (or other XML marshalling >>> defined in >>> this specification) are still subject to all URI rules, including >>> forbidden characters. >>> >>> The last sentence doesn't seem to be useful; what we're saying >>> here applies to all uses of multistatus bodies, including error >>> responses, or extensions (REPORT...). >> I disagree. We're making it clear that, just because a URI appears >> in XML, doesn't mean existing rules don't apply to it. > > I'm not against making that cleat (thus the example in the text > proposed by me in webdav-rfc2518bis-latest.html#rfc.section.12.1.1>), I just find the > current wording confusing. The rule applies to *any* method (not > only PROPFIND or PROPPATCH), and to all kinds of XML (not only > multistatus). The text in section (12.2 - "URL Handling") URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in this specification) are still subject to all URI rules, including forbidden characters. Change to: URIs appearing in all XML elements are still subject to all URI rules, including forbidding characters (this applies to PROPFIND and PROPPATCH, among many methods). Agreed that we should include the example from Julian's draft in section 12.1.1, which clearly shows these rules in action. - Jim From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbWX-0001A3-So for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07373 for ; Wed, 14 Dec 2005 13:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbUt-0006Ic-LM for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:37:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmbUj-0006HN-CQ for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:36:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmbTy-0002AP-Hn for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:36:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIa2gF024872; Wed, 14 Dec 2005 10:36:02 -0800 Date: Wed, 14 Dec 2005 10:36:02 -0800 Message-Id: <200512141836.jBEIa2gF024872@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmbTy-0002AP-Hn 3dbcf26bb1c27d5bd987c2bd7ba0d6d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200512141836.jBEIa2gF024872@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11101 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:37:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 10:36 ------- This issue discussed in 12/14/2005 teleconference. Agreement there to: * Revert the List production to what it was in 2518 * Add a cross-reference to definition of Coded-URL (now in DAV header) * Remove the paragraph starting "Note that the absolute-URI production..." and put this cross reference actually in the ABNF section Julian's draft has all of these changes embedded within them. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbWX-0001A4-Tn for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07372 for ; Wed, 14 Dec 2005 13:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbUx-0006JY-BC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:37:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmbUv-0006Ir-4e for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:37:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmbUh-0002WS-5m for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:37:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIa3Jn024886; Wed, 14 Dec 2005 10:36:03 -0800 Date: Wed, 14 Dec 2005 10:36:03 -0800 Message-Id: <200512141836.jBEIa3Jn024886@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmbUh-0002WS-5m 0de2ea3fa2c83ef171cb443a909f6800 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512141836.jBEIa3Jn024886@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11102 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:37:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbWX-0001A3-So for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07373 for ; Wed, 14 Dec 2005 13:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbUt-0006Ic-LM for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:37:03 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmbUj-0006HN-CQ for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:36:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmbTy-0002AP-Hn for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:36:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIa2gF024872; Wed, 14 Dec 2005 10:36:02 -0800 Date: Wed, 14 Dec 2005 10:36:02 -0800 Message-Id: <200512141836.jBEIa2gF024872@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmbTy-0002AP-Hn 3dbcf26bb1c27d5bd987c2bd7ba0d6d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200512141836.jBEIa2gF024872@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11101 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:37:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 10:36 ------- This issue discussed in 12/14/2005 teleconference. Agreement there to: * Revert the List production to what it was in 2518 * Add a cross-reference to definition of Coded-URL (now in DAV header) * Remove the paragraph starting "Note that the absolute-URI production..." and put this cross reference actually in the ABNF section Julian's draft has all of these changes embedded within them. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbWX-0001A4-Tn for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07372 for ; Wed, 14 Dec 2005 13:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbUx-0006JY-BC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:37:07 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmbUv-0006Ir-4e for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:37:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmbUh-0002WS-5m for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:37:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIa3Jn024886; Wed, 14 Dec 2005 10:36:03 -0800 Date: Wed, 14 Dec 2005 10:36:03 -0800 Message-Id: <200512141836.jBEIa3Jn024886@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmbUh-0002WS-5m 0de2ea3fa2c83ef171cb443a909f6800 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512141836.jBEIa3Jn024886@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11102 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:37:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:41:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbZb-0001me-2g for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:41:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07554 for ; Wed, 14 Dec 2005 13:40:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbYZ-0007D2-J5 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:40:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmbYW-0007CU-Un for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:40:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmbYI-0002Cm-3g for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:40:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIeVfZ024920; Wed, 14 Dec 2005 10:40:31 -0800 Date: Wed, 14 Dec 2005 10:40:31 -0800 Message-Id: <200512141840.jBEIeVfZ024920@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmbYI-0002Cm-3g 938cb0d0cb8b9c3d3412a1727178143c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 160] IF_HEADERS_CAN_GET_LONG X-Archived-At: http://www.w3.org/mid/200512141840.jBEIeVfZ024920@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11103 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:40:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=160 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 10:40 ------- Discussed during 12/14/05 teleconference. We're not sure it's really even a problem. Servers that do have a policy on this allow the max length of all headers to be configured (64kbytes is typical for all headers combined). Hence, even if the IF header is split across multiple headers, this still doesn't address the maximum size of all headers combined. This doesn't appear to be an issue that we can fix in the specification. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:45:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbdB-000364-EH for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:45:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08241 for ; Wed, 14 Dec 2005 13:44:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Embc1-0007dt-CT for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:44:25 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Embbz-0007cq-1f for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:44:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Embbp-00066d-Tq for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:44:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIiDuw024959; Wed, 14 Dec 2005 10:44:13 -0800 Date: Wed, 14 Dec 2005 10:44:13 -0800 Message-Id: <200512141844.jBEIiDuw024959@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Embbp-00066d-Tq 92395383a6e35c2c8da670c09d591733 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512141844.jBEIiDuw024959@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11104 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:44:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |144 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-14 10:44 ------- related to issue 144 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Embdq-0003E5-Lx for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:46:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08339 for ; Wed, 14 Dec 2005 13:45:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Embci-0008Pg-AD for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:45:08 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Embcf-0008El-94 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:45:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Embca-0006XR-Lo for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:45:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIiE0p024973; Wed, 14 Dec 2005 10:44:14 -0800 Date: Wed, 14 Dec 2005 10:44:14 -0800 Message-Id: <200512141844.jBEIiE0p024973@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Embca-0006XR-Lo 4d6a7a5013d38472d8f7963fc9c0bb25 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200512141844.jBEIiE0p024973@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11105 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:45:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |18 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 13:55:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbmS-0006Dn-4S for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:55:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09489 for ; Wed, 14 Dec 2005 13:54:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmblH-0002rY-HX for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 18:53:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmblF-0002qV-IP for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 18:53:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmblA-0008EQ-HX for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 18:53:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEIr5jP025010; Wed, 14 Dec 2005 10:53:05 -0800 Date: Wed, 14 Dec 2005 10:53:05 -0800 Message-Id: <200512141853.jBEIr5jP025010@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmblA-0008EQ-HX 5bb386232a41020062046e6d9ac7e843 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200512141853.jBEIr5jP025010@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11106 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 18:53:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 10:53 ------- Discussed during 12/14/05 teleconference. Agreement on the call: * Should add a statement that authentication and authorization MUST be performed prior to evaluating If header. Evaluating the If header first might allow a client to discover information about the resource that he wouldn't ordinarily be able to find out without privileges. For example, a client could discover whether a resource exists, or has changed. Text to be added to the If header section. * There didn't seem to be a compelling reason to have If evaluated before/after If-Match, and hence no text needs to be added here. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:06:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbxU-0000Ks-70 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:06:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11030 for ; Wed, 14 Dec 2005 14:05:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbwE-0007Nj-GA for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:05:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Embw8-0007Md-Jy for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:05:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Embvt-0004cU-JJ for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:05:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJ4s6k025066; Wed, 14 Dec 2005 11:04:54 -0800 Date: Wed, 14 Dec 2005 11:04:54 -0800 Message-Id: <200512141904.jBEJ4s6k025066@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Embvt-0004cU-JJ f331977a62c414a6638349443086a752 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 161] EVALUATE_ALL_OF_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512141904.jBEJ4s6k025066@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11107 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:05:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=161 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:04 ------- Discussed during 12/14/2005 teleconference. There was some confusion over what the exact bug was in the specification. Jason's original email is the best source for this (the bug text is insufficiently descriptive). Very hard to discuss this issue without examples. Hard to think about these issues concretely during the call. Move to discuss on the mailing list. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:08:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbzN-0000s6-7N for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:08:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11419 for ; Wed, 14 Dec 2005 14:07:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmbyE-0007dj-TW for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:07:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmbyC-0007d6-HY for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:07:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emby4-0005Wa-Tc for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:07:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJ7CdJ025088; Wed, 14 Dec 2005 11:07:12 -0800 Date: Wed, 14 Dec 2005 11:07:12 -0800 Message-Id: <200512141907.jBEJ7CdJ025088@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Emby4-0005Wa-Tc fc1ef4768985e2d658918f4b317e4b8f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 162] REMOVE_UNTAGGED_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512141907.jBEJ7CdJ025088@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11108 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:07:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=162 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:07 ------- Discussed during the 12/14/2005 teleconference. Julian noted that by far the most common use of If header is to submit lock tokens, and most clients use the untagged production in If to do this. Making this change would break most existing clients. Closing the issue, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:12:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emc3C-0002AY-UM for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:12:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11862 for ; Wed, 14 Dec 2005 14:11:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emc1z-0008Np-ND for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:11:15 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emc1x-0008NG-HM for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:11:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emc1e-0001qq-Im for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:11:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJA58a025121; Wed, 14 Dec 2005 11:10:05 -0800 Date: Wed, 14 Dec 2005 11:10:05 -0800 Message-Id: <200512141910.jBEJA58a025121@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emc1e-0001qq-Im fb4579b00ede4a1b56f654761e9bdc83 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 163] REMOVE_NOT_SUPPORT_FROM_IF_HEADERS X-Archived-At: http://www.w3.org/mid/200512141910.jBEJA58a025121@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11109 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:11:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=163 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:10 ------- Discussed during the 12/14/2005. Consensus on the call that the Not capability is useful (Julian mentioned several potential use cases), and it should be kept in the specification. Closing the issue, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:16:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emc6u-0002v8-Mo for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:16:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12473 for ; Wed, 14 Dec 2005 14:15:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emc5k-0000kW-Lm for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:15:09 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emc5g-0000fJ-QN for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:15:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emc4m-0003M9-50 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:15:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJE7ug025146; Wed, 14 Dec 2005 11:14:07 -0800 Date: Wed, 14 Dec 2005 11:14:07 -0800 Message-Id: <200512141914.jBEJE7ug025146@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emc4m-0003M9-50 75a88483db11dff5f05ad668906489c5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512141914.jBEJE7ug025146@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11110 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:15:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:20:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcBN-0004lN-Pn for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:20:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13141 for ; Wed, 14 Dec 2005 14:19:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcAB-0002yn-3U for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:19:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcA4-0002we-Kl for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:19:36 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emc9t-0002Db-9B for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:19:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJJLht025173; Wed, 14 Dec 2005 11:19:21 -0800 Date: Wed, 14 Dec 2005 11:19:21 -0800 Message-Id: <200512141919.jBEJJLht025173@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Emc9t-0002Db-9B 40333067d51ce0cba666616392d5b823 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512141919.jBEJJLht025173@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11111 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:19:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:19 ------- Discussed during the 12/14/2005 teleconference. We noted that this semantic was found in the discussion of the Depth header. Julian to perform research to test COPY depth infinity & submit If-Match with etag for one of them. Requires server to fail the request, since the etag matches only one the resources. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:22:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcDK-0005US-20 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:22:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13303 for ; Wed, 14 Dec 2005 14:21:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcCF-0003eW-JY for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:21:51 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcCD-0003dV-DA for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:21:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcCA-0003G5-In for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:21:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJKs9n025233; Wed, 14 Dec 2005 11:20:54 -0800 Date: Wed, 14 Dec 2005 11:20:54 -0800 Message-Id: <200512141920.jBEJKs9n025233@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcCA-0003G5-In ef4d9cd7e017b7864886c63ac43d9459 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200512141920.jBEJKs9n025233@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11113 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:21:51 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:20 ------- *** Bug 159 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:23:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcDM-0005UR-Ij for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:23:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13301 for ; Wed, 14 Dec 2005 14:21:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcCD-0003dR-8N for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:21:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcCA-0003cX-44 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:21:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcC3-0003D0-E5 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:21:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJKrXv025219; Wed, 14 Dec 2005 11:20:53 -0800 Date: Wed, 14 Dec 2005 11:20:53 -0800 Message-Id: <200512141920.jBEJKrXv025219@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcC3-0003D0-E5 dfb211f8610f808d2223ba324247bc29 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 159] ORDER_OF_HEADER_EVALUATION X-Archived-At: http://www.w3.org/mid/200512141920.jBEJKrXv025219@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11112 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:21:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=159 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:20 ------- *** This bug has been marked as a duplicate of 144 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:23:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcDT-0005V2-6A for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:23:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13305 for ; Wed, 14 Dec 2005 14:21:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcCL-0003f5-Lh for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:21:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcCB-0003cy-CF for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:21:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcC8-0003FE-L3 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:21:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJLhml025267; Wed, 14 Dec 2005 11:21:43 -0800 Date: Wed, 14 Dec 2005 11:21:43 -0800 Message-Id: <200512141921.jBEJLhml025267@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcC8-0003FE-L3 fc4830b34ed0dbadad5a5afcbc0f004d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200512141921.jBEJLhml025267@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11114 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:21:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:25:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcFl-0005jk-MA for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:25:29 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13610 for ; Wed, 14 Dec 2005 14:24:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcEc-0003xT-Mn for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:24:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcEa-0003wp-Dx for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:24:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcEX-0004IN-JP for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:24:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJOBw7025292; Wed, 14 Dec 2005 11:24:11 -0800 Date: Wed, 14 Dec 2005 11:24:11 -0800 Message-Id: <200512141924.jBEJOBw7025292@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcEX-0004IN-JP 5db41a2ce566c2745b418a8ae1807c9b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512141924.jBEJOBw7025292@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11115 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:24:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:28:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcIg-0006Qv-NS for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:28:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13936 for ; Wed, 14 Dec 2005 14:27:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcHS-0004hA-FC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:27:14 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmcHQ-0004g9-7Q for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:27:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmcFJ-0000I1-U7 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:27:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJP0bC025314; Wed, 14 Dec 2005 11:25:00 -0800 Date: Wed, 14 Dec 2005 11:25:00 -0800 Message-Id: <200512141925.jBEJP0bC025314@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmcFJ-0000I1-U7 7a1688983eadfb314cf7fbd8d6f9c251 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 139] MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL X-Archived-At: http://www.w3.org/mid/200512141925.jBEJP0bC025314@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11116 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:27:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=139 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:25 ------- Discussed during the 12/14/2005 teleconference. This addresses the case where a client is performing lock discovery to find what has been locked. It used to be the case that such a client could not discover the lock root for a depth locked collection. Clients now can find this out using the new lockroot XML element in lock discovery. As a result, the fix suggested in this bug is no longer needed. closing the issue, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:32:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcMz-0008Af-St for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:32:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14235 for ; Wed, 14 Dec 2005 14:31:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcLz-0007qj-Pz for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:31:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcLp-0007of-Jc for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:31:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcLm-0007QT-SR for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:31:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJVe5d025370; Wed, 14 Dec 2005 11:31:40 -0800 Date: Wed, 14 Dec 2005 11:31:40 -0800 Message-Id: <200512141931.jBEJVe5d025370@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcLm-0007QT-SR 7fae303df8cf8cb70b7fb521edc08a53 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 157] REMOVE_ETAG_SUPPORT_FOR_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512141931.jBEJVe5d025370@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11118 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:31:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=157 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:31 ------- Discussed during 12/14/2005 teleconference: Use case for this: Client updating a resource that they locked, knowing that the lock may have gone away, but also possessing the Etag for the resource. In this case, the If header can represent the condition of: make the change if the Etag is still there OR the lock token is present. Using the If-Match header would have AND semantics, not OR semantics. Closing the issue, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:33:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcN2-00089f-FA for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:33:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14231 for ; Wed, 14 Dec 2005 14:31:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcLt-0007pB-9u for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:31:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcLm-0007oF-W7 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:31:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcLj-0007PN-7a for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:31:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJVcgc025354; Wed, 14 Dec 2005 11:31:38 -0800 Date: Wed, 14 Dec 2005 11:31:38 -0800 Message-Id: <200512141931.jBEJVcgc025354@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcLj-0007PN-7a a6a02ce103d5acf65e3c318d2252acfe X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200512141931.jBEJVcgc025354@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11117 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:31:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:34:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcNz-00007H-1J for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:34:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14428 for ; Wed, 14 Dec 2005 14:32:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcMk-0008BH-Tf for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:32:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcMi-00089e-UE for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:32:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcMf-0007oU-Hn for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:32:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJWaQe025396; Wed, 14 Dec 2005 11:32:36 -0800 Date: Wed, 14 Dec 2005 11:32:36 -0800 Message-Id: <200512141932.jBEJWaQe025396@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcMf-0007oU-Hn a58d1f0089672e3194b42303b740435c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512141932.jBEJWaQe025396@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11119 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:32:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:39:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcTk-0000lP-Dk for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:39:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15157 for ; Wed, 14 Dec 2005 14:38:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcSJ-0000h6-6l for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:38:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcSG-0000fx-RK for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:38:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcS7-0001gg-KD for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:38:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJbTBN025427; Wed, 14 Dec 2005 11:37:29 -0800 Date: Wed, 14 Dec 2005 11:37:29 -0800 Message-Id: <200512141937.jBEJbTBN025427@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcS7-0001gg-KD 3dba650bfa9e762e1e8880ebab2c3504 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 125] COPY_INTO_YOURSELF_CLARIFY X-Archived-At: http://www.w3.org/mid/200512141937.jBEJbTBN025427@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11120 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:38:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=125 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:37 ------- Discussed during the 12/14/2005 teleconference. Consensus on the call is to add an implementation note stating that servers should be aware that a copy depth infinity of /A/ into /A/B/ can lead to infinite recursion if not handled. Servers that handle this incorrectly might find that this can be used as a denial of service attack on the server. Assigning to Lisa to add text to the specification on this. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcVr-0001Tx-Ey for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:42:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15405 for ; Wed, 14 Dec 2005 14:41:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcUr-0001Jl-Bw for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:41:05 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmcUp-0001In-5n for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:41:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmcUh-0007EN-7p for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:41:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJernE025465; Wed, 14 Dec 2005 11:40:53 -0800 Date: Wed, 14 Dec 2005 11:40:53 -0800 Message-Id: <200512141940.jBEJernE025465@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmcUh-0007EN-7p 3c5d5af505c03f90a48631d264ede5d5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512141940.jBEJernE025465@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11121 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:41:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:42:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcWf-0001lf-81 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:42:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15442 for ; Wed, 14 Dec 2005 14:41:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcVV-0001Pg-HC for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:41:45 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmcVS-0001OQ-F9 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:41:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmcV7-0007Rc-Sb for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:41:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJfLHk025487; Wed, 14 Dec 2005 11:41:21 -0800 Date: Wed, 14 Dec 2005 11:41:21 -0800 Message-Id: <200512141941.jBEJfLHk025487@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmcV7-0007Rc-Sb e937785ad74db9afc3e26da406763d4f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 132] DEPTH_LOCK_AND_IF X-Archived-At: http://www.w3.org/mid/200512141941.jBEJfLHk025487@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11122 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:41:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=132 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:46:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emca8-0002wX-Lb for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:46:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15928 for ; Wed, 14 Dec 2005 14:45:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcZ3-0002pV-IT for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:45:25 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmcZ0-0002gE-Fl for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:45:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmcYq-0000dz-AF for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:45:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJjCDp025528; Wed, 14 Dec 2005 11:45:12 -0800 Date: Wed, 14 Dec 2005 11:45:12 -0800 Message-Id: <200512141945.jBEJjCDp025528@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmcYq-0000dz-AF 86e6bea0f18b505a7a7309cf6f00a340 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 127] PUT_ON_COLLECTION X-Archived-At: http://www.w3.org/mid/200512141945.jBEJjCDp025528@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11123 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:45:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=127 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:45 ------- Discussed during 12/14/2005 teleconference. Found that this is a duplication of bug #79, which has been resolved. *** This bug has been marked as a duplicate of 79 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:46:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcaC-0002yl-8q for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:46:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15961 for ; Wed, 14 Dec 2005 14:45:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcZC-0003Cg-Re for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:45:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmcZ2-0002ju-0x for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:45:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmcYr-0000eM-5A for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:45:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJjC8G025542; Wed, 14 Dec 2005 11:45:12 -0800 Date: Wed, 14 Dec 2005 11:45:12 -0800 Message-Id: <200512141945.jBEJjC8G025542@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmcYr-0000eM-5A f8fcefc6784764641b4f5fc5ac5e5d4d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 79] PUT for collections rationale X-Archived-At: http://www.w3.org/mid/200512141945.jBEJjC8G025542@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11124 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:45:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=79 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elias@cse.ucsc.edu ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:45 ------- *** Bug 127 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:47:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emcar-000384-QU for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:47:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16037 for ; Wed, 14 Dec 2005 14:46:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmcZn-0004LX-8F for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:46:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmcZi-0004HV-CS for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:46:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmcZc-00052R-Uw for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:46:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJk0tq025567; Wed, 14 Dec 2005 11:46:00 -0800 Date: Wed, 14 Dec 2005 11:46:00 -0800 Message-Id: <200512141946.jBEJk0tq025567@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EmcZc-00052R-Uw 8a1cfe1fe32f55690b840cea7bf061af X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 166] XML_GUIDELINES_CONFORMANCE X-Archived-At: http://www.w3.org/mid/200512141946.jBEJk0tq025567@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11125 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:46:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=166 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 14:49:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emcd6-0003OH-BC for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 14:49:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16266 for ; Wed, 14 Dec 2005 14:48:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emcc0-0004h2-D8 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 19:48:28 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emcbw-0004gA-Jt for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 19:48:24 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emcbq-00064B-Uh for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 19:48:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBEJlUjL025589; Wed, 14 Dec 2005 11:47:30 -0800 Date: Wed, 14 Dec 2005 11:47:30 -0800 Message-Id: <200512141947.jBEJlUjL025589@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Emcbq-00064B-Uh 681301ebaa0739d431d9a10b2ccfdaf2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 188] PROPFIND include-dead-props X-Archived-At: http://www.w3.org/mid/200512141947.jBEJlUjL025589@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11126 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 19:48:28 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 15:54:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmddR-0003QQ-ER for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 15:54:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23025 for ; Wed, 14 Dec 2005 15:52:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emdbr-0004nh-10 for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 20:52:23 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emdbe-0004mu-0U for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 20:52:10 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmdbQ-0005JA-T1 for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 20:52:08 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5DF7A142306; Wed, 14 Dec 2005 12:51:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18198-03; Wed, 14 Dec 2005 12:51:08 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AF308142304; Wed, 14 Dec 2005 12:50:56 -0800 (PST) In-Reply-To: <439E9115.50104@gmx.de> References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Tue, 13 Dec 2005 09:49:05 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmdbQ-0005JA-T1 4c2df05c7196cc9c4fbc728c0e6e7f58 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/d5500d4950f8bc0978ba1fe3c87ce246@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11127 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 20:52:23 +0000 Content-Transfer-Encoding: 7bit Well, I disagree with that model. I propose that all methods work the same on all bindings to a resource with respect to requiring the lock token, including DELETE. Lisa On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote: > > OK, > > this is really an important issue RFC2518bis has to solve (I'd say, if > we can't resolve it, we shouldn't publish a revision at all). > > So far I've seen two people agreeing that the semantics described by > GULP for this situation are indeed correct/desirable, and nobody > speaking against. I also note that this is what our server implements > (running code!), and nobody has so far made a proposal to define lock > semantics differently (not on a case-by-case basis, but with a > explanation spanning all methods/situations). > > So any additional feedback would be highly appreciated. > > Best regards, Julian > > > Julian Reschke wrote: >> Hi. >> yesterday's conference call resulted in kind of interesting >> news on this issues. >> As far as I can tell, the current authors of the draft for RFC2518bis >> took the position that the text called GULP - the Grand Unified >> Locking Proposal (see for instance [1]) - doesn't need to be >> incorporated into RFC2518bis because all it says is already covered >> over there. >> When we discussed BugZilla issue 54 [2], we discovered that there's >> indeed disagreement on locking semantics, and that we need to resolve >> that one way or another. >> So what we ended up are two separate questions, which are: >> (1) Should there be a single (normative) place in the doc which >> provides a high-level overview of locking, similar but not >> necessarily identical with GULP? >> As far as I can tell, the attendees of the conference call concluded >> that yes, we want that. >> (2) What are the semantics for a lock on a resource having multiple >> bindings (issue 54)? Consider: >> - A resource Z identified by URLs /foo/a and /foo/b. >> - Z gets locked by a LOCK request on /foo/a. >> In this situation, is a lock token required to DELETE /foo/b? GULP's >> answer to that one is that you don't need the lock token. Removing >> the URI /foo/b does not affect the state of resource Z, nor does it >> affect any URL that is protected by that lock (/foo/a and /foo/). A >> lock token would need to be provided if the resource /foo itself >> would be locked, but it isn't. >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will >> require the lock token because it affects the state of resource Z. >> This may be confusing, but follows from the fact that the URI of a >> resource is not part of it's lockable state. My assumption is that >> any other attempt to define this would be even more confusing. >> Feedback appreciated, >> Julian >> [1] >> > 1003.html> >> [2] > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@frink.w3.org Wed Dec 14 16:04:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emdns-0006mh-Rj for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 16:04:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25819 for ; Wed, 14 Dec 2005 16:03:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emdmm-0008Bf-2b for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 21:03:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emdmj-0008Av-NF for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 21:03:37 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Emdme-0002lw-EQ for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 21:03:35 +0000 Received: (qmail invoked by alias); 14 Dec 2005 20:56:47 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp037) with SMTP; 14 Dec 2005 21:56:47 +0100 X-Authenticated: #1915285 Message-ID: <43A086A8.4030807@gmx.de> Date: Wed, 14 Dec 2005 21:55:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Emdme-0002lw-EQ 9992d6dbe1d350a0f6606f6a7b338c53 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A086A8.4030807@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11128 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 21:03:40 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Well, I disagree with that model. I propose that all methods work the > same on all bindings to a resource with respect to requiring the lock > token, including DELETE. Hm. Trying to clarify...: are you also opposed to distinguish between resources being locked and URLs being protected? Or is this terminology you agree with that we can use in our discussions? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 16:07:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdqM-0007ZR-0v for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 16:07:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26234 for ; Wed, 14 Dec 2005 16:06:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmdpC-0000If-VU for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 21:06:10 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmdpA-0000Hx-Cp for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 21:06:08 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emdp6-0002OE-CU for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 21:06:07 +0000 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D3EB2142304; Wed, 14 Dec 2005 13:06:02 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27347-05; Wed, 14 Dec 2005 13:06:02 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AEAEA142301; Wed, 14 Dec 2005 13:06:01 -0800 (PST) In-Reply-To: <43A086A8.4030807@gmx.de> References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> <43A086A8.4030807@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Wed, 14 Dec 2005 13:05:47 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emdp6-0002OE-CU ac8026ca15784ee3cf80277d53c0b0c1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/edcf30bef01459e2315444d45167ecf5@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11129 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 21:06:10 +0000 Content-Transfer-Encoding: 7bit Good question, and I'm not sure -- it depends what the consequences are of assuming this distinction. It seemed like a useful distinction until it led to what, to me, were unexpected or undesired consequences. Do any servers implement multiple URLs, locking and DELETE (regardless of whether they support the exact model of BIND)? If so, what do existing implementations do? lisa On Dec 14, 2005, at 12:55 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Well, I disagree with that model. I propose that all methods work >> the same on all bindings to a resource with respect to requiring the >> lock token, including DELETE. > > Hm. Trying to clarify...: are you also opposed to distinguish between > resources being locked and URLs being protected? Or is this > terminology you agree with that we can use in our discussions? > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Wed Dec 14 16:18:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eme12-0005Lr-6J for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 16:18:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28050 for ; Wed, 14 Dec 2005 16:17:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emdzx-0004D8-Bb for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 21:17:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emdzr-0004CJ-5x for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 21:17:11 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Emdzn-0007zX-Ej for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 21:17:10 +0000 Received: (qmail invoked by alias); 14 Dec 2005 21:17:04 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp035) with SMTP; 14 Dec 2005 22:17:04 +0100 X-Authenticated: #1915285 Message-ID: <43A08B73.9050209@gmx.de> Date: Wed, 14 Dec 2005 22:15:31 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> <43A086A8.4030807@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Emdzn-0007zX-Ej 60af5f3e0bbf19a854ff5834292a0b8b X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A08B73.9050209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11130 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 21:17:17 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Good question, and I'm not sure -- it depends what the consequences are > of assuming this distinction. It seemed like a useful distinction until > it led to what, to me, were unexpected or undesired consequences. Well. If not using this term, how do you distinguish between the resources that are actually locked, and the URLs that are protected? So for instance, with a /a/b being lcoked (through a LOCK request on /a/b), how do you describe the fact that the URL is protected by the lock (that is, you'll need a lock-token to MOVE /a itself)? > Do any servers implement multiple URLs, locking and DELETE (regardless > of whether they support the exact model of BIND)? If so, what do > existing implementations do? Yes, we do, and of course we implement the model we discuss. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 16:26:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eme8e-0000f9-LC for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 16:26:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28988 for ; Wed, 14 Dec 2005 16:25:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eme7Z-0006Fz-2d for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 21:25:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eme7X-0006FA-0P for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 21:25:07 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eme7O-0002b1-HL for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 21:25:06 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F3F63142309; Wed, 14 Dec 2005 13:24:56 -0800 (PST) In-Reply-To: <43A08B73.9050209@gmx.de> References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> <43A086A8.4030807@gmx.de> <43A08B73.9050209@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0ae6246e6d42dec224062290182e8e5b@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Wed, 14 Dec 2005 13:24:48 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Eme7O-0002b1-HL 82f6520bd9fcf09e4695a9272dea4935 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/0ae6246e6d42dec224062290182e8e5b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11131 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 21:25:09 +0000 Content-Transfer-Encoding: 7bit One could imagine the lock applying to the resource and to all its bindings, considering the bindings to be part of the state of the resource. If I recall, I think this is the model I'd always assumed until GULP. With this model, if A and B are bindings to a resource, and a LOCK token to A is successful, then for the duration of the lock the token is required to change either A or B. In today's server implementations, does a LOCK of depth 0 on a collection prevent MOVE from being used to change resource names inside the collection? This is another possible case that might be different depending on whether bindings were considered part of the collection, part of the resource state, or both. Lisa On Dec 14, 2005, at 1:15 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Good question, and I'm not sure -- it depends what the consequences >> are of assuming this distinction. It seemed like a useful >> distinction until it led to what, to me, were unexpected or undesired >> consequences. > > Well. If not using this term, how do you distinguish between the > resources that are actually locked, and the URLs that are protected? > So for instance, with a > > /a/b > > being lcoked (through a LOCK request on /a/b), how do you describe the > fact that the URL is protected by the lock (that is, you'll need a > lock-token to MOVE /a itself)? > >> Do any servers implement multiple URLs, locking and DELETE >> (regardless of whether they support the exact model of BIND)? If >> so, what do existing implementations do? > > Yes, we do, and of course we implement the model we discuss. > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 16:35:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmeI0-00042P-V3 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 16:35:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00108 for ; Wed, 14 Dec 2005 16:34:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmeGl-0001S3-5J for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 21:34:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmeGe-0001Qx-67 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 21:34:32 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmeGX-00067k-0s for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 21:34:32 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C684514230C; Wed, 14 Dec 2005 13:34:23 -0800 (PST) In-Reply-To: <439F858B.1060505@gmx.de> References: <439F858B.1060505@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0ecaa3b8c38eb0ee4ae89cf659cbbcae@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav , Cullen Jennings From: Lisa Dusseault Date: Wed, 14 Dec 2005 13:34:16 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EmeGX-00067k-0s 157870d96c78f25358ef4749166c0cb6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/0ecaa3b8c38eb0ee4ae89cf659cbbcae@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11132 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 21:34:39 +0000 Content-Transfer-Encoding: 7bit Perhaps we should set a precedent for content-limited servers not to advertise themselves as being fully functional WebDAV servers. That would go for those CalDAV servers that can't handle non-event data in calendars too, at least that restriction could be advertised on those types of collections. There are probably a couple other restrictions I would consider major hurdles for clients expecting to "do their WebDAV thing" -- possibly some of the weak or no ETag cases or wierd creationdate cases we've discussed before. Lisa On Dec 13, 2005, at 6:38 PM, Julian Reschke wrote: > > Cullen Jennings wrote: >> On 12/13/05 2:33 PM, "Julian Reschke" wrote: >>> Cullen Jennings wrote: >>>> I have a questions for the WG. Can servers, within policy >>>> constraints, be >>>> expected to store arbitrary data. What I mean be the policy >>>> constraints is >>>> clearly a server might reject a request because it was too large, >>>> or it >>>> decided the file had a virus and it would not store it. But in >>>> general, can >>>> a client expect a WebDAV serve to be able to store say a HTML file? >>> In general, no it can't. There are servers that accept only >>> particular >>> types of content (such as something running on top of an XML >>> database). >>> >>> Would it be useful to allow clients to discover support for these >>> kinds >>> of things upfront? Sure, that's exactly I'd be happy to define a >>> profile >>> and give it a compliance class name for use in the DAV header (for >>> example). >>> >>> Best regards, Julian >> You keep mentioning the XML database but I would have expected them >> to save >> non XML data as more or less a BLOB. Am I missing something key here? > > You may or you may not. I can only provide hear-say here (I was > referring to Slide running on top of certain Tamino instances; that's > Software AG's XML database). > > Another example (as discussed before) would be a Calendar (CalDAV) or > a Newsfeed (Atompub) server. Both may restrict the type of content you > can put in specific places. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Wed Dec 14 17:07:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ememp-00049R-VA for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 17:07:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03968 for ; Wed, 14 Dec 2005 17:06:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmelQ-0001d3-Vg for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 22:06:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmelE-0001bE-2n; Wed, 14 Dec 2005 22:06:08 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emel8-00018g-PO; Wed, 14 Dec 2005 22:06:07 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBEM5x1f004701; Wed, 14 Dec 2005 17:06:00 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBEM5xBY123684; Wed, 14 Dec 2005 17:05:59 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBEM5xvg024130; Wed, 14 Dec 2005 17:05:59 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBEM5xal024123; Wed, 14 Dec 2005 17:05:59 -0500 In-Reply-To: To: Lisa Dusseault Cc: Julian Reschke , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 14 Dec 2005 17:06:06 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF60 | October 19, 2005) at 12/14/2005 17:05:58, Serialize complete at 12/14/2005 17:05:58 Content-Type: multipart/alternative; boundary="=_alternative 007966E5852570D7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Emel8-00018g-PO 58bb4e08852039775cdc92da58fd53f4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF3B48FFAA.7FF51A6A-ON852570D7.00736589-852570D7.00796793@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11133 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 22:06:20 +0000 This is a multipart message in MIME format. --=_alternative 007966E5852570D7_= Content-Type: text/plain; charset="US-ASCII" Note that we have discussed at great length on this mailing list as to whether all live properties must have the same value for all URL's that map to a given resource, and have concluded that they do not, therefore Lisa's proposed rule minimally does not apply to PROPFIND. It also does not apply to UNBIND and REBIND. And unless you want to argue against the previous consensus that a server is allowed to implement DELETE as UNBIND (if it so wishes), this also means that Lisa's proposed rule does not hold for DELETE. So I would conclude that this proposed rule would not be a valid basis for disagreeing with the GULP model, since the proposed rule does not hold for a variety of methods. Cheers, Geoff Lisa wrote on 12/13/2005 12:49:05 PM: > > Well, I disagree with that model. I propose that all methods work the > same on all bindings to a resource with respect to requiring the lock > token, including DELETE. > > Lisa > > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote: > > > > > OK, > > > > this is really an important issue RFC2518bis has to solve (I'd say, if > > we can't resolve it, we shouldn't publish a revision at all). > > > > So far I've seen two people agreeing that the semantics described by > > GULP for this situation are indeed correct/desirable, and nobody > > speaking against. I also note that this is what our server implements > > (running code!), and nobody has so far made a proposal to define lock > > semantics differently (not on a case-by-case basis, but with a > > explanation spanning all methods/situations). > > > > So any additional feedback would be highly appreciated. > > > > Best regards, Julian > > > > > > Julian Reschke wrote: > >> Hi. > >> yesterday's conference call resulted in kind of interesting > >> news on this issues. > >> As far as I can tell, the current authors of the draft for RFC2518bis > >> took the position that the text called GULP - the Grand Unified > >> Locking Proposal (see for instance [1]) - doesn't need to be > >> incorporated into RFC2518bis because all it says is already covered > >> over there. > >> When we discussed BugZilla issue 54 [2], we discovered that there's > >> indeed disagreement on locking semantics, and that we need to resolve > >> that one way or another. > >> So what we ended up are two separate questions, which are: > >> (1) Should there be a single (normative) place in the doc which > >> provides a high-level overview of locking, similar but not > >> necessarily identical with GULP? > >> As far as I can tell, the attendees of the conference call concluded > >> that yes, we want that. > >> (2) What are the semantics for a lock on a resource having multiple > >> bindings (issue 54)? Consider: > >> - A resource Z identified by URLs /foo/a and /foo/b. > >> - Z gets locked by a LOCK request on /foo/a. > >> In this situation, is a lock token required to DELETE /foo/b? GULP's > >> answer to that one is that you don't need the lock token. Removing > >> the URI /foo/b does not affect the state of resource Z, nor does it > >> affect any URL that is protected by that lock (/foo/a and /foo/). A > >> lock token would need to be provided if the resource /foo itself > >> would be locked, but it isn't. > >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will > >> require the lock token because it affects the state of resource Z. > >> This may be confusing, but follows from the fact that the URI of a > >> resource is not part of it's lockable state. My assumption is that > >> any other attempt to define this would be even more confusing. > >> Feedback appreciated, > >> Julian > >> [1] > >> >> 1003.html> > >> [2] > > > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > --=_alternative 007966E5852570D7_= Content-Type: text/html; charset="US-ASCII"
Note that we have discussed at great length on this mailing
list as to whether all live properties must have the same value
for all URL's that map to a given resource, and have concluded
that they do not, therefore Lisa's proposed rule minimally
does not apply to PROPFIND.

It also does not apply to UNBIND and REBIND.

And unless you want to argue against the previous consensus
that a server is allowed to implement DELETE as UNBIND
(if it so wishes), this also means that Lisa's proposed rule
does not hold for DELETE.

So I would conclude that this proposed rule would not be
a valid basis for disagreeing with the GULP model, since
the proposed rule does not hold for a variety of methods.

Cheers,
Geoff

Lisa wrote on 12/13/2005 12:49:05 PM:

>
> Well, I disagree with that model.  I propose that all methods work the  
> same on all bindings to a resource with respect to requiring the lock  
> token, including DELETE.
>
> Lisa
>
> On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote:
>
> >
> > OK,
> >
> > this is really an important issue RFC2518bis has to solve (I'd say, if  
> > we can't resolve it, we shouldn't publish a revision at all).
> >
> > So far I've seen two people agreeing that the semantics described by  
> > GULP for this situation are indeed correct/desirable, and nobody  
> > speaking against. I also note that this is what our server implements  
> > (running code!), and nobody has so far made a proposal to define lock  
> > semantics differently (not on a case-by-case basis, but with a  
> > explanation spanning all methods/situations).
> >
> > So any additional feedback would be highly appreciated.
> >
> > Best regards, Julian
> >
> >
> > Julian Reschke wrote:
> >> Hi.
> >> yesterday's conference call resulted in kind of interesting
> >> news on this issues.
> >> As far as I can tell, the current authors of the draft for RFC2518bis  
> >> took the position that the text called GULP - the Grand Unified  
> >> Locking Proposal (see for instance [1]) - doesn't need to be  
> >> incorporated into RFC2518bis because all it says is already covered  
> >> over there.
> >> When we discussed BugZilla issue 54 [2], we discovered that there's  
> >> indeed disagreement on locking semantics, and that we need to resolve  
> >> that one way or another.
> >> So what we ended up are two separate questions, which are:
> >> (1) Should there be a single (normative) place in the doc which  
> >> provides a high-level overview of locking, similar but not  
> >> necessarily identical with GULP?
> >> As far as I can tell, the attendees of the conference call concluded  
> >> that yes, we want that.
> >> (2) What are the semantics for a lock on a resource having multiple  
> >> bindings (issue 54)? Consider:
> >> - A resource Z identified by URLs /foo/a and /foo/b.
> >> - Z gets locked by a LOCK request on /foo/a.
> >> In this situation, is a lock token required to DELETE /foo/b? GULP's  
> >> answer to that one is that you don't need the lock token. Removing  
> >> the URI /foo/b does not affect the state of resource Z, nor does it  
> >> affect any URL that is protected by that lock (/foo/a and /foo/). A  
> >> lock token would need to be provided if the resource /foo itself  
> >> would be locked, but it isn't.
> >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will  
> >> require the lock token because it affects the state of resource Z.  
> >> This may be confusing, but follows from the fact that the URI of a  
> >> resource is not part of it's lockable state. My assumption is that  
> >> any other attempt to define this would be even more confusing.
> >> Feedback appreciated,
> >> Julian
> >> [1]  
> >> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
> >> 1003.html>
> >> [2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>
> >
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>
>
--=_alternative 007966E5852570D7_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 17:13:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emese-0005s6-Sf for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 17:13:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05000 for ; Wed, 14 Dec 2005 17:12:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emera-0002XB-8b for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 22:12:42 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmerX-0002WW-FV; Wed, 14 Dec 2005 22:12:40 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmerD-0004D9-GX; Wed, 14 Dec 2005 22:12:38 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A91E142309; Wed, 14 Dec 2005 14:11:04 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-6--475258055 Message-Id: <7a8e52d81feab8c375683771855f9a52@osafoundation.org> Cc: Julian Reschke , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org From: Lisa Dusseault Date: Wed, 14 Dec 2005 14:10:48 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmerD-0004D9-GX 434873a8eb649879af759ad1b5988567 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/7a8e52d81feab8c375683771855f9a52@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11134 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 22:12:42 +0000 --Apple-Mail-6--475258055 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Why wouldn't it hold for UNBIND -- or for DELETE implemented as UNBIND=20= which I agree is a good thing? How does my proposed rule affect PROPFIND at all? I suggested that=20 methods behave the same *with respect to requiring lock tokens*, thus=20 the proposal is about the lock model, not about property models. lisa On Dec 14, 2005, at 2:06 PM, Geoffrey M Clemm wrote: > > Note that we have discussed at great length on this mailing > list as to whether all live properties must have the same value > for all URL's that map to a given resource, and have concluded > that they do not, therefore Lisa's proposed rule minimally > does not apply to PROPFIND. > > It also does not apply to UNBIND and REBIND. > > And unless you want to argue against the previous consensus > that a server is allowed to implement DELETE as UNBIND > (if it so wishes), this also means that Lisa's proposed rule > does not hold for DELETE. > > So I would conclude that this proposed rule would not be > a valid basis for disagreeing with the GULP model, since > the proposed rule does not hold for a variety of methods. > > Cheers, > Geoff > > Lisa wrote on 12/13/2005 12:49:05 PM: > > > > > Well, I disagree with that model. =A0I propose that all methods = work=20 > the =A0 > > same on all bindings to a resource with respect to requiring the=20 > lock =A0 > > token, including DELETE. > > > > Lisa > > > > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote: > > > > > > > > OK, > > > > > > this is really an important issue RFC2518bis has to solve (I'd=20 > say, if =A0 > > > we can't resolve it, we shouldn't publish a revision at all). > > > > > > So far I've seen two people agreeing that the semantics described=20= > by =A0 > > > GULP for this situation are indeed correct/desirable, and nobody = =A0 > > > speaking against. I also note that this is what our server=20 > implements =A0 > > > (running code!), and nobody has so far made a proposal to define=20= > lock =A0 > > > semantics differently (not on a case-by-case basis, but with a =A0 > > > explanation spanning all methods/situations). > > > > > > So any additional feedback would be highly appreciated. > > > > > > Best regards, Julian > > > > > > > > > Julian Reschke wrote: > > >> Hi. > > >> yesterday's conference call resulted in kind of interesting > > >> news on this issues. > > >> As far as I can tell, the current authors of the draft for=20 > RFC2518bis =A0 > > >> took the position that the text called GULP - the Grand Unified = =A0 > > >> Locking Proposal (see for instance [1]) - doesn't need to be =A0 > > >> incorporated into RFC2518bis because all it says is already=20 > covered =A0 > > >> over there. > > >> When we discussed BugZilla issue 54 [2], we discovered that=20 > there's =A0 > > >> indeed disagreement on locking semantics, and that we need to=20 > resolve =A0 > > >> that one way or another. > > >> So what we ended up are two separate questions, which are: > > >> (1) Should there be a single (normative) place in the doc which = =A0 > > >> provides a high-level overview of locking, similar but not =A0 > > >> necessarily identical with GULP? > > >> As far as I can tell, the attendees of the conference call=20 > concluded =A0 > > >> that yes, we want that. > > >> (2) What are the semantics for a lock on a resource having=20 > multiple =A0 > > >> bindings (issue 54)? Consider: > > >> - A resource Z identified by URLs /foo/a and /foo/b. > > >> - Z gets locked by a LOCK request on /foo/a. > > >> In this situation, is a lock token required to DELETE /foo/b?=20 > GULP's =A0 > > >> answer to that one is that you don't need the lock token.=20 > Removing =A0 > > >> the URI /foo/b does not affect the state of resource Z, nor does=20= > it =A0 > > >> affect any URL that is protected by that lock (/foo/a and=20 > /foo/). A =A0 > > >> lock token would need to be provided if the resource /foo itself=20= > =A0 > > >> would be locked, but it isn't. > > >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will =A0= > > >> require the lock token because it affects the state of resource=20= > Z. =A0 > > >> This may be confusing, but follows from the fact that the URI of=20= > a =A0 > > >> resource is not part of it's lockable state. My assumption is=20 > that =A0 > > >> any other attempt to define this would be even more confusing. > > >> Feedback appreciated, > > >> Julian > > >> [1] =A0 > > >> > >> 1003.html> > > >> [2] > > > > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de --=20 > tel:+492512807760 > > > > > > > --Apple-Mail-6--475258055 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why wouldn't it hold for UNBIND -- or for DELETE implemented as UNBIND which I agree is a good thing? How does my proposed rule affect PROPFIND at all? I suggested that methods behave the same *with respect to requiring lock tokens*, thus the proposal is about the lock model, not about property models. =20 lisa On Dec 14, 2005, at 2:06 PM, Geoffrey M Clemm wrote: Note that we have discussed at great length on this mailing=20 list as to whether all live properties must have the same value=20 for all URL's that map to a given resource, and have concluded=20 that they do not, therefore Lisa's proposed rule minimally=20 does not apply to PROPFIND.=20 It also does not apply to UNBIND and REBIND.=20 And unless you want to argue against the previous consensus=20 that a server is allowed to implement DELETE as UNBIND=20 (if it so wishes), this also means that Lisa's proposed rule=20 does not hold for DELETE.=20 So I would conclude that this proposed rule would not be=20 a valid basis for disagreeing with the GULP model, since=20 the proposed rule does not hold for a variety of methods.=20 Cheers,=20 Geoff=20 Lisa wrote on 12/13/2005 12:49:05 = PM: > > Well, I disagree with that model. =A0I propose that all methods work the =A0 > same on all bindings to a resource with respect to requiring the lock =A0 > token, including = DELETE. > > Lisa > > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote: > > > > > OK, > > > > this is really an important issue RFC2518bis has to solve (I'd say, if =A0 > > we can't resolve it, we shouldn't publish a revision at all). > > > > So far I've seen two people agreeing that the semantics described by =A0 > > GULP for this situation are indeed correct/desirable, and nobody =A0 > > speaking against. I also note that this is what our server implements =A0 > > (running code!), and nobody has so far made a proposal to define lock =A0 > > semantics differently (not on a case-by-case basis, but with a =A0 > > explanation spanning all methods/situations). > > > > So any additional feedback would be highly appreciated. > > > > Best regards, Julian > > > > > > Julian Reschke wrote: > >> Hi. > >> yesterday's conference call resulted in kind of interesting > >> news on this issues. > >> As far as I can tell, the current authors of the draft for RFC2518bis =A0 > >> took the position that the text called GULP - the Grand Unified =A0 > >> Locking Proposal (see for instance [1]) - doesn't need to be =A0 > >> incorporated into RFC2518bis because all it says is already covered =A0 > >> over there. > >> When we discussed BugZilla issue 54 [2], we discovered that there's =A0 > >> indeed disagreement on locking semantics, and that we need to resolve =A0 > >> that one way or = another. > >> So what we ended up are two separate questions, which are: > >> (1) Should there be a single (normative) place in the doc which =A0 > >> provides a high-level overview of locking, similar but not =A0 > >> necessarily identical with = GULP? > >> As far as I can tell, the attendees of the conference call concluded =A0 > >> that yes, we want = that. > >> (2) What are the semantics for a lock on a resource having multiple =A0 > >> bindings (issue 54)? = Consider: > >> - A resource Z identified by URLs /foo/a and /foo/b. > >> - Z gets locked by a LOCK request on /foo/a. > >> In this situation, is a lock token required to DELETE /foo/b? GULP's =A0 > >> answer to that one is that you don't need the lock token. Removing =A0 > >> the URI /foo/b does not affect the state of resource Z, nor does it =A0 > >> affect any URL that is protected by that lock (/foo/a and /foo/). A =A0 > >> lock token would need to be provided if the resource /foo itself =A0 > >> would be locked, but it = isn't. > >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will =A0 > >> require the lock token because it affects the state of resource Z. =A0 > >> This may be confusing, but follows from the fact that the URI of a =A0 > >> resource is not part of it's lockable state. My assumption is that =A0 > >> any other attempt to define this would be even more confusing. > >> Feedback = appreciated, > >> Julian > >> [1] =A0 > >> = < > >> 1003.html> > >> [2] = < > > > > > > -- > > <bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > = --Apple-Mail-6--475258055-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 17:21:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emf02-0001wo-HK for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 17:21:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05821 for ; Wed, 14 Dec 2005 17:20:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emeyz-0004pD-Dn for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 22:20:21 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emeys-0004oX-Q5 for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 22:20:15 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EmeyK-0007Ax-IB for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 22:20:13 +0000 Received: (qmail invoked by alias); 14 Dec 2005 22:19:35 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp032) with SMTP; 14 Dec 2005 23:19:35 +0100 X-Authenticated: #1915285 Message-ID: <43A09A15.7080500@gmx.de> Date: Wed, 14 Dec 2005 23:17:57 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> <43A086A8.4030807@gmx.de> <43A08B73.9050209@gmx.de> <0ae6246e6d42dec224062290182e8e5b@osafoundation.org> In-Reply-To: <0ae6246e6d42dec224062290182e8e5b@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmeyK-0007Ax-IB 4787720addd7f1369188b43b1c6e1899 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A09A15.7080500@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11135 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 22:20:21 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > One could imagine the lock applying to the resource and to all its > bindings, considering the bindings to be part of the state of the > resource. If I recall, I think this is the model I'd always assumed Well, I'm not aware of a single server that supports multiple bindings to one resource, but which considers bindings as part of the state of the resource. Do you? I also note that this point of view is incompatible to the model used in RFC3744, where you need a DAV:unbind privilege on the parent collection to remove a binding (). > until GULP. With this model, if A and B are bindings to a resource, and > a LOCK token to A is successful, then for the duration of the lock the > token is required to change either A or B. Are you aware of a single implementation working that way? > In today's server implementations, does a LOCK of depth 0 on a > collection prevent MOVE from being used to change resource names inside > the collection? This is another possible case that might be different > depending on whether bindings were considered part of the collection, > part of the resource state, or both. I'll claim that all servers that implement depth 0 locks on collections work that way, and that RFC2518 requires them do work that way (): "A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection." Again, if you have evidence of servers working differently, please provide it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 17:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emf4K-0003RD-6y for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 17:25:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06313 for ; Wed, 14 Dec 2005 17:24:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emf3B-00054t-8P for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 22:24:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emf33-00054L-UP for w3c-dist-auth@listhub.w3.org; Wed, 14 Dec 2005 22:24:34 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1Emf2x-0000Ri-Nh for w3c-dist-auth@w3.org; Wed, 14 Dec 2005 22:24:32 +0000 Received: (qmail invoked by alias); 14 Dec 2005 22:24:25 -0000 Received: from p508FAA88.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.136] by mail.gmx.net (mp039) with SMTP; 14 Dec 2005 23:24:25 +0100 X-Authenticated: #1915285 Message-ID: <43A09B37.5090104@gmx.de> Date: Wed, 14 Dec 2005 23:22:47 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav , Cullen Jennings References: <439F858B.1060505@gmx.de> <0ecaa3b8c38eb0ee4ae89cf659cbbcae@osafoundation.org> In-Reply-To: <0ecaa3b8c38eb0ee4ae89cf659cbbcae@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emf2x-0000Ri-Nh 8fec53b74ee1b9a2d2ccf2724a76b6ed X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/43A09B37.5090104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11136 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 22:24:41 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Perhaps we should set a precedent for content-limited servers not to > advertise themselves as being fully functional WebDAV servers. That > would go for those CalDAV servers that can't handle non-event data in > calendars too, at least that restriction could be advertised on those > types of collections. There are probably a couple other restrictions I > would consider major hurdles for clients expecting to "do their WebDAV > thing" -- possibly some of the weak or no ETag cases or wierd > creationdate cases we've discussed before. I note that we seem to converge on this being something that clients should be able to discover. The question remains whether this is something RFC2518 allows today (my position). In this case, new requirements should be explicitly spelled out (Etags types, Etag returned upon PUT?, binary content allowed?, ...?) and given a name (potentially a discoverable compliance class). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 18:02:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmfeB-0004cH-45 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 18:02:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10130 for ; Wed, 14 Dec 2005 18:01:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emfcz-0006NA-HZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 14 Dec 2005 23:01:41 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emfcm-0006Lp-AT; Wed, 14 Dec 2005 23:01:28 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmfcP-00051U-Hs; Wed, 14 Dec 2005 23:01:27 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBEN10Rq025947; Wed, 14 Dec 2005 18:01:00 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBEN10Mh113536; Wed, 14 Dec 2005 18:01:00 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBEN0x94023416; Wed, 14 Dec 2005 18:01:00 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBEN0xHe023406; Wed, 14 Dec 2005 18:00:59 -0500 In-Reply-To: <7a8e52d81feab8c375683771855f9a52@osafoundation.org> To: Lisa Dusseault Cc: Julian Reschke , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 14 Dec 2005 18:01:06 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF60 | October 19, 2005) at 12/14/2005 18:00:58, Serialize complete at 12/14/2005 18:00:58 Content-Type: multipart/alternative; boundary="=_alternative 007E7019852570D7_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmfcP-00051U-Hs 25d90f9cbb0afce5911d046d20cf8bbe X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF118A5B76.7EC01BA1-ON852570D7.007A1746-852570D7.007E70A1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11137 X-Loop: w3c-dist-auth@w3.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, 14 Dec 2005 23:01:41 +0000 This is a multipart message in MIME format. --=_alternative 007E7019852570D7_= Content-Type: text/plain; charset="US-ASCII" I mentioned PROPFIND just to make the point that this rule doesn't hold in general, so there is no apriori requirement that it hold for locking and lock tokens. Cheers, Geoff Lisa Dusseault wrote on 12/14/2005 05:10:48 PM: > Why wouldn't it hold for UNBIND -- or for DELETE implemented as UNBIND > which I agree is a good thing? > > How does my proposed rule affect PROPFIND at all? I suggested that > methods behave the same *with respect to requiring lock tokens*, thus > the proposal is about the lock model, not about property models. > > lisa > > On Dec 14, 2005, at 2:06 PM, Geoffrey M Clemm wrote: > > > > > Note that we have discussed at great length on this mailing > > list as to whether all live properties must have the same value > > for all URL's that map to a given resource, and have concluded > > that they do not, therefore Lisa's proposed rule minimally > > does not apply to PROPFIND. > > > > It also does not apply to UNBIND and REBIND. > > > > And unless you want to argue against the previous consensus > > that a server is allowed to implement DELETE as UNBIND > > (if it so wishes), this also means that Lisa's proposed rule > > does not hold for DELETE. > > > > So I would conclude that this proposed rule would not be > > a valid basis for disagreeing with the GULP model, since > > the proposed rule does not hold for a variety of methods. > > > > Cheers, > > Geoff > > > > Lisa wrote on 12/13/2005 12:49:05 PM: > > > > > > > > Well, I disagree with that model. I propose that all methods work > > the > > > same on all bindings to a resource with respect to requiring the > > lock > > > token, including DELETE. > > > > > > Lisa > > > > > > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote: > > > > > > > > > > > OK, > > > > > > > > this is really an important issue RFC2518bis has to solve (I'd > > say, if > > > > we can't resolve it, we shouldn't publish a revision at all). > > > > > > > > So far I've seen two people agreeing that the semantics described > > by > > > > GULP for this situation are indeed correct/desirable, and nobody > > > > speaking against. I also note that this is what our server > > implements > > > > (running code!), and nobody has so far made a proposal to define > > lock > > > > semantics differently (not on a case-by-case basis, but with a > > > > explanation spanning all methods/situations). > > > > > > > > So any additional feedback would be highly appreciated. > > > > > > > > Best regards, Julian > > > > > > > > > > > > Julian Reschke wrote: > > > >> Hi. > > > >> yesterday's conference call resulted in kind of interesting > > > >> news on this issues. > > > >> As far as I can tell, the current authors of the draft for > > RFC2518bis > > > >> took the position that the text called GULP - the Grand Unified > > > >> Locking Proposal (see for instance [1]) - doesn't need to be > > > >> incorporated into RFC2518bis because all it says is already > > covered > > > >> over there. > > > >> When we discussed BugZilla issue 54 [2], we discovered that > > there's > > > >> indeed disagreement on locking semantics, and that we need to > > resolve > > > >> that one way or another. > > > >> So what we ended up are two separate questions, which are: > > > >> (1) Should there be a single (normative) place in the doc which > > > >> provides a high-level overview of locking, similar but not > > > >> necessarily identical with GULP? > > > >> As far as I can tell, the attendees of the conference call > > concluded > > > >> that yes, we want that. > > > >> (2) What are the semantics for a lock on a resource having > > multiple > > > >> bindings (issue 54)? Consider: > > > >> - A resource Z identified by URLs /foo/a and /foo/b. > > > >> - Z gets locked by a LOCK request on /foo/a. > > > >> In this situation, is a lock token required to DELETE /foo/b? > > GULP's > > > >> answer to that one is that you don't need the lock token. > > Removing > > > >> the URI /foo/b does not affect the state of resource Z, nor does > > it > > > >> affect any URL that is protected by that lock (/foo/a and > > /foo/). A > > > >> lock token would need to be provided if the resource /foo itself > > > > > >> would be locked, but it isn't. > > > >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will > > > >> require the lock token because it affects the state of resource > > Z. > > > >> This may be confusing, but follows from the fact that the URI of > > a > > > >> resource is not part of it's lockable state. My assumption is > > that > > > >> any other attempt to define this would be even more confusing. > > > >> Feedback appreciated, > > > >> Julian > > > >> [1] > > > >> > > >> 1003.html> > > > >> [2] > > > > > > > > > > > > -- > > > > bytes GmbH -- http://www.greenbytes.de -- > > tel:+492512807760 > > > > > > > > > > --=_alternative 007E7019852570D7_= Content-Type: text/html; charset="US-ASCII"
I mentioned PROPFIND just to make the point that this rule
doesn't hold in general, so there is no apriori requirement
that it hold for locking and lock tokens.

Cheers,
Geoff


Lisa Dusseault <lisa@osafoundation.org> wrote on 12/14/2005 05:10:48 PM:

> Why wouldn't it hold for UNBIND -- or for DELETE implemented as UNBIND
> which I agree is a good thing?
>
> How does my proposed rule affect PROPFIND at all?  I suggested that
> methods behave the same *with respect to requiring lock tokens*, thus
> the proposal is about the lock model, not about property models.
>
> lisa
>
> On Dec 14, 2005, at 2:06 PM, Geoffrey M Clemm wrote:
>
> >
> > Note that we have discussed at great length on this mailing
> > list as to whether all live properties must have the same value
> > for all URL's that map to a given resource, and have concluded
> > that they do not, therefore Lisa's proposed rule minimally
> > does not apply to PROPFIND.
> >
> > It also does not apply to UNBIND and REBIND.
> >
> > And unless you want to argue against the previous consensus
> > that a server is allowed to implement DELETE as UNBIND
> > (if it so wishes), this also means that Lisa's proposed rule
> > does not hold for DELETE.
> >
> > So I would conclude that this proposed rule would not be
> > a valid basis for disagreeing with the GULP model, since
> > the proposed rule does not hold for a variety of methods.
> >
> > Cheers,
> > Geoff
> >
> > Lisa wrote on 12/13/2005 12:49:05 PM:
> >
> >  >
> >  > Well, I disagree with that model.  I propose that all methods work
> > the  
> >  > same on all bindings to a resource with respect to requiring the
> > lock  
> >  > token, including DELETE.
> >  >
> >  > Lisa
> >  >
> >  > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote:
> >  >
> >  > >
> >  > > OK,
> >  > >
> >  > > this is really an important issue RFC2518bis has to solve (I'd
> > say, if  
> >  > > we can't resolve it, we shouldn't publish a revision at all).
> >  > >
> >  > > So far I've seen two people agreeing that the semantics described
> > by  
> >  > > GULP for this situation are indeed correct/desirable, and nobody  
> >  > > speaking against. I also note that this is what our server
> > implements  
> >  > > (running code!), and nobody has so far made a proposal to define
> > lock  
> >  > > semantics differently (not on a case-by-case basis, but with a  
> >  > > explanation spanning all methods/situations).
> >  > >
> >  > > So any additional feedback would be highly appreciated.
> >  > >
> >  > > Best regards, Julian
> >  > >
> >  > >
> >  > > Julian Reschke wrote:
> >  > >> Hi.
> >  > >> yesterday's conference call resulted in kind of interesting
> >  > >> news on this issues.
> >  > >> As far as I can tell, the current authors of the draft for
> > RFC2518bis  
> >  > >> took the position that the text called GULP - the Grand Unified  
> >  > >> Locking Proposal (see for instance [1]) - doesn't need to be  
> >  > >> incorporated into RFC2518bis because all it says is already
> > covered  
> >  > >> over there.
> >  > >> When we discussed BugZilla issue 54 [2], we discovered that
> > there's  
> >  > >> indeed disagreement on locking semantics, and that we need to
> > resolve  
> >  > >> that one way or another.
> >  > >> So what we ended up are two separate questions, which are:
> >  > >> (1) Should there be a single (normative) place in the doc which  
> >  > >> provides a high-level overview of locking, similar but not  
> >  > >> necessarily identical with GULP?
> >  > >> As far as I can tell, the attendees of the conference call
> > concluded  
> >  > >> that yes, we want that.
> >  > >> (2) What are the semantics for a lock on a resource having
> > multiple  
> >  > >> bindings (issue 54)? Consider:
> >  > >> - A resource Z identified by URLs /foo/a and /foo/b.
> >  > >> - Z gets locked by a LOCK request on /foo/a.
> >  > >> In this situation, is a lock token required to DELETE /foo/b?
> > GULP's  
> >  > >> answer to that one is that you don't need the lock token.
> > Removing  
> >  > >> the URI /foo/b does not affect the state of resource Z, nor does
> > it  
> >  > >> affect any URL that is protected by that lock (/foo/a and
> > /foo/). A  
> >  > >> lock token would need to be provided if the resource /foo itself
> >  
> >  > >> would be locked, but it isn't.
> >  > >> On the other hand, a PUT or a PROPPATCH applied to /foo/b will  
> >  > >> require the lock token because it affects the state of resource
> > Z.  
> >  > >> This may be confusing, but follows from the fact that the URI of
> > a  
> >  > >> resource is not part of it's lockable state. My assumption is
> > that  
> >  > >> any other attempt to define this would be even more confusing.
> >  > >> Feedback appreciated,
> >  > >> Julian
> >  > >> [1]  
> >  > >> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/
> >  > >> 1003.html>
> >  > >> [2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>
> >  > >
> >  > >
> >  > > --
> >  > > <green/>bytes GmbH -- http://www.greenbytes.de --
> > tel:+492512807760
> >  > >
> >  >
> >  >
 --=_alternative 007E7019852570D7_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:25:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgvc-0003oA-Bw for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:25:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18433 for ; Wed, 14 Dec 2005 19:24:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emgtx-0006P8-Hl for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:23:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emgtu-0006OF-H8 for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:23:15 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1Emgto-0004MH-3O for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:23:11 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 16:20:07 -0800 X-IronPort-AV: i="3.99,255,1131350400"; d="scan'208"; a="684743781:sNHT939421144" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0K4Me016766; Wed, 14 Dec 2005 16:20:05 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:20:04 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:20:12 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav Message-ID: Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcYBDVBMjuA9ZG0AEdqJKAARJEEJ/A== In-Reply-To: <43A09A15.7080500@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1Emgto-0004MH-3O 5abbac9560c0eb57d8b79133fe0978d4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/BFC5F6BC.65776%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11139 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:23:17 +0000 Content-Transfer-Encoding: 7bit On 12/14/05 2:17 PM, "Julian Reschke" wrote: > Lisa Dusseault wrote: >> >> One could imagine the lock applying to the resource and to all its >> bindings, considering the bindings to be part of the state of the >> resource. If I recall, I think this is the model I'd always assumed > > Well, I'm not aware of a single server that supports multiple bindings > to one resource, but which considers bindings as part of the state of > the resource. Do you? I was just sort of thinking, if one implemented a server using a XML database, and one used the database locks to implement the DAV LOCK, it seems like you would end up with the lock locking the resource not the URI. Perhaps that would just not be a legal way to implement it. I'm not making an argument one way or another, I was just sort of pondering this and wondering if my assumption that using the database lock to implement LOCK would result in this model. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:25:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgvc-0003oB-CO for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:25:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18434 for ; Wed, 14 Dec 2005 19:24:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emgtu-0006OT-4V for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:23:14 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emgti-0006MF-Rh for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:23:03 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmgtS-0006vC-MZ for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:23:01 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 14 Dec 2005 16:22:44 -0800 X-IronPort-AV: i="3.99,255,1131350400"; d="scan'208"; a="378426791:sNHT32465520" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0MfMe018019; Wed, 14 Dec 2005 16:22:42 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:22:41 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:22:50 -0800 From: Cullen Jennings To: Lisa Dusseault , Julian Reschke CC: WebDav Message-ID: Thread-Topic: Do server store arbitrary content Thread-Index: AcYBDa547PrqAW0AEdqJKAARJEEJ/A== In-Reply-To: <0ecaa3b8c38eb0ee4ae89cf659cbbcae@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.71.176.72 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmgtS-0006vC-MZ b6728ba75ae5216769d9d82599de9e74 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/BFC5F75A.65778%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11138 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:23:14 +0000 Content-Transfer-Encoding: 7bit I think any future RFC could define something that was an restricted version of DAV. On 12/14/05 1:34 PM, "Lisa Dusseault" wrote: > Perhaps we should set a precedent for content-limited servers not to > advertise themselves as being fully functional WebDAV servers. That > would go for those CalDAV servers that can't handle non-event data in > calendars too, at least that restriction could be advertised on those > types of collections. There are probably a couple other restrictions I > would consider major hurdles for clients expecting to "do their WebDAV > thing" -- possibly some of the weak or no ETag cases or wierd > creationdate cases we've discussed before. > > Lisa > > On Dec 13, 2005, at 6:38 PM, Julian Reschke wrote: > >> >> Cullen Jennings wrote: >>> On 12/13/05 2:33 PM, "Julian Reschke" wrote: >>>> Cullen Jennings wrote: >>>>> I have a questions for the WG. Can servers, within policy >>>>> constraints, be >>>>> expected to store arbitrary data. What I mean be the policy >>>>> constraints is >>>>> clearly a server might reject a request because it was too large, >>>>> or it >>>>> decided the file had a virus and it would not store it. But in >>>>> general, can >>>>> a client expect a WebDAV serve to be able to store say a HTML file? >>>> In general, no it can't. There are servers that accept only >>>> particular >>>> types of content (such as something running on top of an XML >>>> database). >>>> >>>> Would it be useful to allow clients to discover support for these >>>> kinds >>>> of things upfront? Sure, that's exactly I'd be happy to define a >>>> profile >>>> and give it a compliance class name for use in the DAV header (for >>>> example). >>>> >>>> Best regards, Julian >>> You keep mentioning the XML database but I would have expected them >>> to save >>> non XML data as more or less a BLOB. Am I missing something key here? >> >> You may or you may not. I can only provide hear-say here (I was >> referring to Slide running on top of certain Tamino instances; that's >> Software AG's XML database). >> >> Another example (as discussed before) would be a Calendar (CalDAV) or >> a Newsfeed (Atompub) server. Both may restrict the type of content you >> can put in specific places. >> >> Best regards, Julian >> From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:28:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgz1-0005cf-F5 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:28:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19093 for ; Wed, 14 Dec 2005 19:27:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emgxs-0007iE-0n for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:27:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emgxp-0007gv-QD for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:27:17 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emgxm-0005ue-EQ for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:27:17 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2005 16:27:14 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0RBpf008011 for ; Wed, 14 Dec 2005 16:27:12 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:27:11 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:27:19 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Was ... Re: [Bug 161] EVALUATE_ALL_OF_IF_HEADER Thread-Index: AcYBDk7PjYQsSm0BEdqJKAARJEEJ/A== In-Reply-To: <200512141904.jBEJ4s6k025066@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1Emgxm-0005ue-EQ f679164570f91f4d48f6d497ac7ea00a X-Original-To: w3c-dist-auth@w3.org Subject: Was ... Re: [Bug 161] EVALUATE_ALL_OF_IF_HEADER X-Archived-At: http://www.w3.org/mid/BFC5F867.65782%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11140 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:27:20 +0000 Content-Transfer-Encoding: 7bit Can someone take a stab as summarizing this one with an example on the list? On 12/14/05 11:04 AM, "bugzilla@soe.ucsc.edu" wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=161 > > > > > > ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-14 11:04 ------- > Discussed during 12/14/2005 teleconference. > > There was some confusion over what the exact bug was in the specification. > Jason's original email is the best source for this (the bug text is > insufficiently descriptive). > > Very hard to discuss this issue without examples. > > Hard to think about these issues concretely during the call. Move to discuss > on > the mailing list. > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:28:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emgz9-0005dG-4l for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:28:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19101 for ; Wed, 14 Dec 2005 19:27:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emgy5-0007k2-Qt for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:27:33 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emgy3-0007jU-JR for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:27:31 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emgxy-0000G0-VQ for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:27:30 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2005 16:25:07 -0800 X-IronPort-AV: i="3.99,255,1131350400"; d="scan'208"; a="241044559:sNHT30675390" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0P4pf006922; Wed, 14 Dec 2005 16:25:04 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:25:04 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:25:12 -0800 From: Cullen Jennings To: Julian Reschke , Lisa Dusseault CC: WebDav Message-ID: Thread-Topic: Do server store arbitrary content Thread-Index: AcYBDgMcQciSlm0BEdqJKAARJEEJ/A== In-Reply-To: <43A09B37.5090104@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emgxy-0000G0-VQ b9fa18eb950018533360696519c202fe X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/BFC5F7E8.6577F%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11141 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:27:33 +0000 Content-Transfer-Encoding: 7bit Sorry, another ignorant question ... Is there any text in 2518 that hints at or leads to the conclusion that arbitrary content is not supported? On 12/14/05 2:22 PM, "Julian Reschke" wrote: > Lisa Dusseault wrote: >> >> Perhaps we should set a precedent for content-limited servers not to >> advertise themselves as being fully functional WebDAV servers. That >> would go for those CalDAV servers that can't handle non-event data in >> calendars too, at least that restriction could be advertised on those >> types of collections. There are probably a couple other restrictions I >> would consider major hurdles for clients expecting to "do their WebDAV >> thing" -- possibly some of the weak or no ETag cases or wierd >> creationdate cases we've discussed before. > > I note that we seem to converge on this being something that clients > should be able to discover. > > The question remains whether this is something RFC2518 allows today (my > position). In this case, new requirements should be explicitly spelled > out (Etags types, Etag returned upon PUT?, binary content allowed?, > ...?) and given a name (potentially a discoverable compliance class). > > Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:32:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emh2x-0006Rw-RA for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:32:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19432 for ; Wed, 14 Dec 2005 19:31:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emh1t-0001i6-3U for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:31:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emh1q-0001hN-Mx for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:31:26 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emh1i-0001WH-8Q for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:31:25 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 16:31:16 -0800 X-IronPort-AV: i="3.99,255,1131350400"; d="scan'208"; a="684747703:sNHT58862006" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0VDMe021624 for ; Wed, 14 Dec 2005 16:31:14 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:31:13 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:31:22 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: [Bug 171] If header grammar Thread-Index: AcYBDt+lHfR7cm0CEdqJKAARJEEJ/A== In-Reply-To: <200512141836.jBEIa2gF024872@ietf.cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of fluffy@cisco.com designates 171.71.176.70 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emh1i-0001WH-8Q 3cb4b2ccabb039190d8294af06f76f9b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/BFC5F95A.6578B%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11142 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:31:29 +0000 Content-Transfer-Encoding: 7bit Note I view the point below as something we came to some conclusion on > * Revert the List production to what it was in 2518 While I view the points below as purely stylist > * Add a cross-reference to definition of Coded-URL (now in DAV header) > * Remove the paragraph starting "Note that the absolute-URI production..." and > put this cross reference actually in the ABNF section From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:35:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emh6B-0007Uk-Pv for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:35:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19624 for ; Wed, 14 Dec 2005 19:34:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emh4z-0001vo-7N for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:34:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emh4x-0001vA-5j for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:34:39 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emh4t-0008Ie-RP for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:34:39 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2005 16:34:35 -0800 X-IronPort-AV: i="3.99,255,1131350400"; d="scan'208"; a="241046551:sNHT30481088" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0YWMe022688; Wed, 14 Dec 2005 16:34:32 -0800 (PST) Received: from 128.107.139.242 ([128.107.139.242]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:34:32 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 16:34:40 -0800 From: Cullen Jennings To: Elias Sinderson CC: WebDav Message-ID: Thread-Topic: Concern about bugzilla SPAM Thread-Index: AcYBD1WqlDm7nm0CEdqJKAARJEEJ/A== In-Reply-To: <439FE574.3080302@cse.ucsc.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.4 X-W3C-Scan-Sig: lisa.w3.org 1Emh4t-0008Ie-RP ec9fdec100a118bc07026f294eb849c8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Concern about bugzilla SPAM X-Archived-At: http://www.w3.org/mid/BFC5FA20.6578F%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11143 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:34:41 +0000 Content-Transfer-Encoding: 7bit On 12/14/05 1:27 AM, "Elias Sinderson" wrote: > Unless anyone feels strongly otherwise, we can start removing the > mailing list as a contact for bugs as we update them during tomorrows' > telecon. > Let's try that (unless we hear some objections) and if it does not work, we can just go back to what we are doing now and I will beg people to just be patent with us for another month or so till we are finished. From w3c-dist-auth-request@frink.w3.org Wed Dec 14 19:57:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhQb-0005BJ-9U for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:57:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21458 for ; Wed, 14 Dec 2005 19:55:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmhPK-0006EA-Cr for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 00:55:42 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmhPD-0006DU-RN for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 00:55:36 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmhP5-0001HR-32 for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 00:55:35 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBF0scMK026234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2005 16:54:38 -0800 (PST) Message-ID: <43A0BED4.8060808@cse.ucsc.edu> Date: Wed, 14 Dec 2005 16:54:44 -0800 From: Elias Sinderson Reply-To: WebDav User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDav References: <439F8946.8080803@gmx.de> In-Reply-To: <439F8946.8080803@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmhP5-0001HR-32 7a7ba2b8358bbca7cf0e6536bef99017 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A0BED4.8060808@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11144 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 00:55:42 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Cullen Jennings wrote: > >> These are probably the wrong questions but what I am trying to do is >> separate this into two parts. 1 is how locks work, 2 is how we >> specify them in bis. On the topic of how it works, does anyone care >> to help me frame the >> really key question to decide how it works? > > I think the best starting point is indeed GULP, and to let people > raise potential problems they see with that model. In the absence of any other proposed text, I tend to agree with this approach -- at the very least it is a good starting point for further discussion. Due to the editorial overhead, I am opposed to moving all of the normative text on locking into one place, however desireable that may be otherwise. As such, I'm not averse to having normative text appear in the to-be-added discussion of the locking model that WebDAV employs. Best, Elias From w3c-dist-auth-request@frink.w3.org Wed Dec 14 21:35:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emiy6-00058w-5j for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 21:35:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00671 for ; Wed, 14 Dec 2005 21:34:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmiwL-00029L-1a for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 02:33:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Emiw9-00027e-3B; Thu, 15 Dec 2005 02:33:41 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1Emiw5-0003At-Nc; Thu, 15 Dec 2005 02:33:40 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBF2XYVg030234; Wed, 14 Dec 2005 21:33:34 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBF2XZMh114252; Wed, 14 Dec 2005 21:33:35 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBF2XYS7002318; Wed, 14 Dec 2005 21:33:34 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBF2XYY3002312; Wed, 14 Dec 2005 21:33:34 -0500 In-Reply-To: To: Cullen Jennings Cc: Julian Reschke , Lisa Dusseault , WebDav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 14 Dec 2005 21:33:40 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF60 | October 19, 2005) at 12/14/2005 21:33:33, Serialize complete at 12/14/2005 21:33:33 Content-Type: multipart/alternative; boundary="=_alternative 000E109C852570D8_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Emiw5-0003At-Nc a8feddc78e6444530cca50bd02a48d77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF3F27B658.BBC71B32-ON852570D8.000D814E-852570D8.000E10FB@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11145 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 02:33:53 +0000 This is a multipart message in MIME format. --=_alternative 000E109C852570D8_= Content-Type: text/plain; charset="US-ASCII" I'm not aware of XML providing a mechanism for defining multiple bindings to the same resource, so I don't see how an XML database implementation bears on this discussion. Cheers, Geoff Cullen wrote on 12/14/2005 07:20:12 PM: > > On 12/14/05 2:17 PM, "Julian Reschke" wrote: > > > Lisa Dusseault wrote: > >> > >> One could imagine the lock applying to the resource and to all its > >> bindings, considering the bindings to be part of the state of the > >> resource. If I recall, I think this is the model I'd always assumed > > > > Well, I'm not aware of a single server that supports multiple bindings > > to one resource, but which considers bindings as part of the state of > > the resource. Do you? > > I was just sort of thinking, if one implemented a server using a XML > database, and one used the database locks to implement the DAV LOCK, it > seems like you would end up with the lock locking the resource not the URI. > Perhaps that would just not be a legal way to implement it. I'm not making > an argument one way or another, I was just sort of pondering this and > wondering if my assumption that using the database lock to implement LOCK > would result in this model. > --=_alternative 000E109C852570D8_= Content-Type: text/html; charset="US-ASCII"
I'm not aware of XML providing a mechanism for defining multiple bindings
to the same resource, so I don't see how an XML database implementation
bears on this discussion.

Cheers,
Geoff
 

Cullen wrote on 12/14/2005 07:20:12 PM:
>
> On 12/14/05 2:17 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
>
> > Lisa Dusseault wrote:
> >>
> >> One could imagine the lock applying to the resource and to all its
> >> bindings, considering  the bindings to be part of the state of the
> >> resource.  If I recall, I think this is the model I'd always assumed
> >
> > Well, I'm not aware of a single server that supports multiple bindings
> > to one resource, but which considers bindings as part of the state of
> > the resource. Do you?
>
> I was just sort of thinking, if one implemented a server using a XML
> database, and one used the database locks to implement the DAV LOCK, it
> seems like you would end up with the lock locking the resource not the URI.
> Perhaps that would just not be a legal way to implement it. I'm not making
> an argument one way or another, I was just sort of pondering this and
> wondering if my assumption that using the database lock to implement LOCK
> would result in this model.
>
--=_alternative 000E109C852570D8_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 14 23:24:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emkf0-0005yJ-96 for webdav-archive@megatron.ietf.org; Wed, 14 Dec 2005 23:24:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09379 for ; Wed, 14 Dec 2005 23:23:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emkda-0008J8-NY for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 04:22:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EmkdQ-0008HT-DU for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 04:22:28 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EmkdO-0003XU-1x for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 04:22:28 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2005 20:17:16 -0800 X-IronPort-AV: i="3.99,256,1131350400"; d="scan'208,217"; a="241106324:sNHT750836582" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBF4Gwpf015309; Wed, 14 Dec 2005 20:17:03 -0800 (PST) Received: from 10.82.225.164 ([10.82.225.164]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 04:16:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 14 Dec 2005 20:17:04 -0800 From: Cullen Jennings To: Geoffrey M Clemm CC: Julian Reschke , Lisa Dusseault , WebDav Message-ID: Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcYBLmdPph/l0G0hEdqe+gARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3217436225_8070875" Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EmkdO-0003XU-1x 245d4890447bb49eccb1371a897d9527 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/BFC62E40.65802%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11146 X-Loop: w3c-dist-auth@w3.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, 15 Dec 2005 04:22:38 +0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3217436225_8070875 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Perhaps you could explain how one gets multiple bindings when not using an XML database? On 12/14/05 6:33 PM, "Geoffrey M Clemm" wrote: > > I'm not aware of XML providing a mechanism for defining multiple bindings > to the same resource, so I don't see how an XML database implementation > bears on this discussion. > > Cheers, > Geoff > > > Cullen wrote on 12/14/2005 07:20:12 PM: >> > >> > On 12/14/05 2:17 PM, "Julian Reschke" wrote: >> > >>> > > Lisa Dusseault wrote: >>>> > >> >>>> > >> One could imagine the lock applying to the resource and to all its >>>> > >> bindings, considering the bindings to be part of the state of the >>>> > >> resource. If I recall, I think this is the model I'd always assumed >>> > > >>> > > Well, I'm not aware of a single server that supports multiple bindings >>> > > to one resource, but which considers bindings as part of the state of >>> > > the resource. Do you? >> > >> > I was just sort of thinking, if one implemented a server using a XML >> > database, and one used the database locks to implement the DAV LOCK, it >> > seems like you would end up with the lock locking the resource not the URI. >> > Perhaps that would just not be a legal way to implement it. I'm not making >> > an argument one way or another, I was just sort of pondering this and >> > wondering if my assumption that using the database lock to implement LOCK >> > would result in this model. >> > > --B_3217436225_8070875 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'><BR> Perhaps you could explain how one gets multiple bindings when not using an = XML database? <BR> <BR> <BR> On 12/14/05 6:33 PM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm= .com> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>I'm not aware of XML providing a mechanism for defining mu= ltiple bindings</SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:12.0px'> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>to the same resource, so I don't see how an XML database i= mplementation</SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SP= AN STYLE=3D'font-size:12.0px'> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>bears on this discussion.</SPAN></FONT></FONT><FONT FACE=3D"= Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'> <BR> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>Cheers,</SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica= , Arial"><SPAN STYLE=3D'font-size:12.0px'> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>Geoff</SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, = Arial"><SPAN STYLE=3D'font-size:12.0px'> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>Cullen wrote on 12/14/2005 07:20:12 PM:<BR> > <BR> > On 12/14/05 2:17 PM, "Julian Reschke" <julian.reschke@gmx= .de> wrote:<BR> > <BR> > > Lisa Dusseault wrote:<BR> > >> <BR> > >> One could imagine the lock applying to the resource and to al= l its<BR> > >> bindings, considering  the bindings to be part of the st= ate of the<BR> > >> resource.  If I recall, I think this is the model I'd al= ways assumed<BR> > > <BR> > > Well, I'm not aware of a single server that supports multiple bin= dings<BR> > > to one resource, but which considers bindings as part of the stat= e of<BR> > > the resource. Do you?<BR> > <BR> > I was just sort of thinking, if one implemented a server using a XML<B= R> > database, and one used the database locks to implement the DAV LOCK, i= t<BR> > seems like you would end up with the lock locking the resource not the= URI.<BR> > Perhaps that would just not be a legal way to implement it. I'm not ma= king<BR> > an argument one way or another, I was just sort of pondering this and<= BR> > wondering if my assumption that using the database lock to implement L= OCK<BR> > would result in this model.<BR> > <BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:12.0px'><BR> </SPAN></FONT> </BODY> </HTML> --B_3217436225_8070875-- From jmorey@glendalechurch.org Thu Dec 15 02:09:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmnFX-0006Xc-3j for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 02:09:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24640 for <webdav-archive@ietf.org>; Thu, 15 Dec 2005 02:08:47 -0500 (EST) Received: from d2c66416.tcat.ne.jp ([210.198.100.22] helo=-188303256) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmnGc-0004zQ-QE for webdav-archive@ietf.org; Thu, 15 Dec 2005 02:11:10 -0500 Received: from glendalechurch.org (-188242696 [-188155944]) by d2c66416.tcat.ne.jp (Qmailv1) with ESMTP id CDBEA85E19 for <webdav-archive@ietf.org>; Mon, 05 Apr 1999 08:49:07 -0500 Date: Mon, 05 Apr 1999 08:49:07 -0500 From: Doctor <jmorey@glendalechurch.org> X-Mailer: The Bat! (v2.00.8) Personal X-Priority: 3 Message-ID: <0562987295.19990405084907@glendalechurch.org> To: Webdav <webdav-archive@ietf.org> Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------E3199FC6F2148B1" X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. X-Spam-Score: 2.4 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------E3199FC6F2148B1 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlzagra $3.3 Lervitra $3.3 Cibalis $3.7 Imiotrex $16.4 Flozmax $2.2 Ultlram $0.78 Vifoxx $4.75 Amfbien $2.2 Valivum $0.97 Xaxnax $1.09 Somfa $3 Merjidia $2.2 visit our website http://veryleak.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ertytyjiklg RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------E3199FC6F2148B1 Content-Type: text/html Content-Transfer-Encoding: 7bit <html> <body> <b>Vliagra - $3.3 <br> Leovitra - $3.3<br> Ciyalis - $3.7<br> Imiotrex - $16.4<br> Flolmax - $2.2<br> Ultjram - $0.78<br> Vinoxx - $4.75 <br> Amebien - $2.2<br> Valivum - $0.97 <br> Xawnax - $1.09<br> Sompa - $3 <br> Merqidia - $2.2</b><br> <br> <br> <a href="http://veryleak.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ="><strong>visit our website</strong></a><br> <br> <br> Best regards,<br> Online Pharmaceuticals <br> <br> ertytyjiklg RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= </body> </html> ------------E3199FC6F2148B1-- From w3c-dist-auth-request@frink.w3.org Thu Dec 15 04:06:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emp3r-0000X4-Oh for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 04:06:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05772 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 04:05:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emp1W-0007yt-Eu for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 09:03:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Emp1I-0007qJ-JI for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 09:03:24 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Emp1F-0007zm-A3 for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 09:03:24 +0000 Received: (qmail invoked by alias); 15 Dec 2005 09:02:59 -0000 Received: from p508FAAEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.236] by mail.gmx.net (mp017) with SMTP; 15 Dec 2005 10:02:59 +0100 X-Authenticated: #1915285 Message-ID: <43A130F1.1010203@gmx.de> Date: Thu, 15 Dec 2005 10:01:37 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> CC: Lisa Dusseault <lisa@osafoundation.org>, WebDav <w3c-dist-auth@w3.org> References: <BFC5F6BC.65776%fluffy@cisco.com> In-Reply-To: <BFC5F6BC.65776%fluffy@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Emp1F-0007zm-A3 f30a6da0f62b4a4b30378819078a7bf9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A130F1.1010203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11147 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Emp1W-0007yt-Eu@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 09:03:38 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 12/14/05 2:17 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > >> Lisa Dusseault wrote: >>> One could imagine the lock applying to the resource and to all its >>> bindings, considering the bindings to be part of the state of the >>> resource. If I recall, I think this is the model I'd always assumed >> Well, I'm not aware of a single server that supports multiple bindings >> to one resource, but which considers bindings as part of the state of >> the resource. Do you? > > I was just sort of thinking, if one implemented a server using a XML > database, and one used the database locks to implement the DAV LOCK, it > seems like you would end up with the lock locking the resource not the URI. If an implementor would expose database locks directly as WebDAV locks, then this would probably the case. However, that wouldn't be compliant to RFC2518. > Perhaps that would just not be a legal way to implement it. I'm not making > an argument one way or another, I was just sort of pondering this and > wondering if my assumption that using the database lock to implement LOCK > would result in this model. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 15 04:06:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emp4a-0000hx-AY for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 04:06:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05807 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 04:05:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emp41-0000e3-Gx for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 09:06:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Emp3z-0000dG-74 for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 09:06:11 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Emp3m-0000WC-IA for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 09:06:10 +0000 Received: (qmail invoked by alias); 15 Dec 2005 09:05:32 -0000 Received: from p508FAAEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.236] by mail.gmx.net (mp036) with SMTP; 15 Dec 2005 10:05:32 +0100 X-Authenticated: #1915285 Message-ID: <43A1318F.3060503@gmx.de> Date: Thu, 15 Dec 2005 10:04:15 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Lisa Dusseault <lisa@osafoundation.org>, WebDav <w3c-dist-auth@w3.org> References: <BFC62E40.65802%fluffy@cisco.com> In-Reply-To: <BFC62E40.65802%fluffy@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Emp3m-0000WC-IA f94cbe2d5308b5854b800fabe3a2d987 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A1318F.3060503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11148 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Emp41-0000e3-Gx@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 09:06:13 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Perhaps you could explain how one gets multiple bindings when not using > an XML database? As Geoff, I really don't see what this would have to do with an XML database. You can get multiple bindings if - you support BIND and/or - if your underlying store supports something similar, such as a filesystem supporting hard links Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 15 04:10:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emp8M-0002iI-CU for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 04:10:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06208 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 04:09:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emp7h-0001ds-1l for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 09:10:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Emp7e-0001d2-OG for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 09:09:58 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Emp7N-0001ql-A9 for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 09:09:58 +0000 Received: (qmail invoked by alias); 15 Dec 2005 09:09:31 -0000 Received: from p508FAAEC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.170.236] by mail.gmx.net (mp035) with SMTP; 15 Dec 2005 10:09:31 +0100 X-Authenticated: #1915285 Message-ID: <43A13278.7030207@gmx.de> Date: Thu, 15 Dec 2005 10:08:08 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> CC: Lisa Dusseault <lisa@osafoundation.org>, WebDav <w3c-dist-auth@w3.org> References: <BFC5F7E8.6577F%fluffy@cisco.com> In-Reply-To: <BFC5F7E8.6577F%fluffy@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Emp7N-0001ql-A9 381b40de632e7fc997adcb5adfab000e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Do server store arbitrary content X-Archived-At: http://www.w3.org/mid/43A13278.7030207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11149 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Emp7h-0001ds-1l@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 09:10:01 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > Sorry, another ignorant question ... Is there any text in 2518 that hints at > or leads to the conclusion that arbitrary content is not supported? No. On the other hand, there's also no text hinting into the other direction. We're talking here about PUT, and that really is normatively defined in RFC2616. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 15 08:40:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmtL5-0004lS-Hb for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 08:40:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07514 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 08:39:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmtJl-0004Ae-32 for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 13:38:45 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmtJZ-00048o-PP for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 13:38:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmtJ9-00082m-4g for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 13:38:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBFDc5gF026802; Thu, 15 Dec 2005 05:38:05 -0800 Date: Thu, 15 Dec 2005 05:38:05 -0800 Message-Id: <200512151338.jBFDc5gF026802@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmtJ9-00082m-4g fec10946a0147d79738e336a90db57ef X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200512151338.jBFDc5gF026802@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11150 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EmtJl-0004Ae-32@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 13:38:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-15 05:38 ------- Another change not described in the Changes section: * Changes in LOCK refresh (not implicit anymore, uses LOCK without body with Lock-Token request header) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 15 09:06:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emtkv-0003HC-7o for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 09:06:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10822 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 09:05:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Emtk9-0004RB-Tf for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 14:06:01 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1Emtjy-0004QP-2b for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 14:05:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1Emtjs-0004ED-80 for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 14:05:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBFE5fH8026841; Thu, 15 Dec 2005 06:05:41 -0800 Date: Thu, 15 Dec 2005 06:05:41 -0800 Message-Id: <200512151405.jBFE5fH8026841@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1Emtjs-0004ED-80 ff737cc1aa8a009fc9199434a5e46cd1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 207] New: Compliance class descriptions for "1" and "2" X-Archived-At: http://www.w3.org/mid/200512151405.jBFE5fH8026841@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11151 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Emtk9-0004RB-Tf@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 14:06:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=207 Summary: Compliance class descriptions for "1" and "2" Product: WebDAV-RFC2518-bis Version: -08 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2005OctDec/1227.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org The description for compliance classes "1" and "2" seem to be broken; in particular, class "1" requires support for all MUST level reqs of the spec, and I'm pretty sure we have MUST-level requirements for locking. See also http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1227.html. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 15 10:26:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emuzv-0006lr-Km for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 10:26:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20982 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 10:24:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmuyM-0002mP-40 for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 15:24:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EmuyA-0002kI-Ps for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 15:24:35 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Emuq3-0004vT-WB for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 15:24:32 +0000 Received: (qmail invoked by alias); 15 Dec 2005 15:16:01 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 15 Dec 2005 16:16:01 +0100 X-Authenticated: #1915285 Message-ID: <43A1884C.5050402@gmx.de> Date: Thu, 15 Dec 2005 16:14:20 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> CC: Lisa Dusseault <lisa@osafoundation.org>, w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> <439E9115.50104@gmx.de> <d5500d4950f8bc0978ba1fe3c87ce246@osafoundation.org> <43A086A8.4030807@gmx.de> <edcf30bef01459e2315444d45167ecf5@osafoundation.org> <43A08B73.9050209@gmx.de> <0ae6246e6d42dec224062290182e8e5b@osafoundation.org> <43A09A15.7080500@gmx.de> In-Reply-To: <43A09A15.7080500@gmx.de> Content-Type: multipart/mixed; boundary="------------050604070307040405090105" X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Emuq3-0004vT-WB 7282a1e0b38cef1ab0a3d946b18f55e5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A1884C.5050402@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11152 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EmuyM-0002mP-40@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 15:24:46 +0000 This is a multi-part message in MIME format. --------------050604070307040405090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Reschke wrote: >> In today's server implementations, does a LOCK of depth 0 on a >> collection prevent MOVE from being used to change resource names >> inside the collection? This is another possible case that might be >> different depending on whether bindings were considered part of the >> collection, part of the resource state, or both. > > I'll claim that all servers that implement depth 0 locks on collections > work that way, and that RFC2518 requires them do work that way > (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>): > > "A write lock on a collection, whether created by a "Depth: 0" or > "Depth: infinity" lock request, prevents the addition or removal of > member URIs of the collection by non-lock owners. As a consequence, when > a principal issues a PUT or POST request to create a new resource under > a URI which needs to be an internal member of a write locked collection > to maintain HTTP namespace consistency, or issues a DELETE to remove a > resource which has a URI which is an existing internal member URI of a > write locked collection, this request MUST fail if the principal does > not have a write lock on the collection." > > Again, if you have evidence of servers working differently, please > provide it. > > Best regards, Julian For the record, I just tested with all servers that do support collection locks (SAP Netweaver, Apache/moddav, Xythos), and all of them require the lock token when moving things inside a locked collection (test case attached). So unless there's any new evidence, it would be nice if we could stop arguing about this topic... Best regards, Julian --------------050604070307040405090105 Content-Type: application/x-javascript; name="collection_lock_vs_rename.js" Content-Disposition: inline; filename="collection_lock_vs_rename.js" Content-Transfer-Encoding: 7bit var req = new ActiveXObject ("MSXML2.ServerXMLHTTP"); var uri = WScript.Arguments(0); var user = null; var pwd = null; if (WScript.Arguments.length > 1) { user = WScript.Arguments(1); } if (WScript.Arguments.length > 2) { pwd = WScript.Arguments(2); } function dumpResponse(r) { WScript.Echo(r.status); WScript.Echo(r.getAllResponseHeaders()); WScript.Echo(r.responseText); } // create collection WScript.Echo("MKCOL " + uri); req.open("MKCOL", uri, false, user, pwd); req.send(); if ((req.status < 200 || req.status >= 300) && req.status != 405) { WScript.Echo("unexpected status upon MKCOL:" + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); // put content WScript.Echo("PUT " + uri + "/a"); req.open("PUT", uri + "/a", false, user, pwd); req.send("foobar"); if (req.status < 200 || req.status >= 300) { WScript.Echo("unexpected status upon PUT: " + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); WScript.Echo("LOCK " + uri); req.open("LOCK", uri, false, user, pwd); req.setRequestHeader("Depth", "infinity"); req.setRequestHeader("Timeout", "Second-60"); req.send("<D:lockinfo xmlns:D='DAV:'><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype></D:lockinfo>"); dumpResponse(req); var locktoken = null; try { locktoken = req.getResponseHeader("lock-token"); } catch (x) {} if (req.status == 200 || req.status == 201) { WScript.Echo("locktoken: " + locktoken); } else { WScript.Echo("resource not locked, status: " + req.status + " " + req.responseText); WScript.Quit(2); } // attempt MOVE inside locked collection without If header WScript.Echo("MOVE " + uri + "/a to " + uri + "/b"); req.open("MOVE", uri + "/a", false, user, pwd); req.setRequestHeader("Destination", uri + "/b"); req.send(); dumpResponse(req); // attempt MOVE inside locked collection with If header WScript.Echo("MOVE " + uri + "/a to " + uri + "/b with If header"); req.open("MOVE", uri + "/a", false, user, pwd); req.setRequestHeader("If", "<" + uri + "> (" + locktoken + ")"); req.setRequestHeader("Destination", uri + "/b"); req.send(); dumpResponse(req); // UNLOCK WScript.Echo("UNLOCK " + uri); req.open("UNLOCK", uri, false, user, pwd); req.setRequestHeader("Lock-Token", locktoken); req.send(); dumpResponse(req); --------------050604070307040405090105-- From w3c-dist-auth-request@frink.w3.org Thu Dec 15 10:45:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmvIC-00036L-W4 for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 10:45:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24085 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 10:44:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EmvHL-000075-G2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 15:44:23 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EmvHA-0008R1-Lb for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 15:44:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EmvH4-0004jn-Vu for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 15:44:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBFFi5sv026909; Thu, 15 Dec 2005 07:44:05 -0800 Date: Thu, 15 Dec 2005 07:44:05 -0800 Message-Id: <200512151544.jBFFi5sv026909@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EmvH4-0004jn-Vu 8e1b451f21b5891f59c9e02d8637ec90 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 105] COPY for Collection Resources vs infinite loops X-Archived-At: http://www.w3.org/mid/200512151544.jBFFi5sv026909@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11153 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EmvHL-000075-G2@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 15:44:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=105 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-15 07:44 ------- I just did a test, copying /a into /a/a, and 4 out of 4 servers got this right, rejecting the request (that is, they avoided recursion, but didn't follow the new advice in the spec). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 15 15:52:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En05c-0006Vr-9n for webdav-archive@megatron.ietf.org; Thu, 15 Dec 2005 15:52:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03553 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2005 15:51:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1En03g-0003X4-Nl for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2005 20:50:36 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1En03S-0003Tm-4J for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2005 20:50:22 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by maggie.w3.org with esmtp (Exim 4.50) id 1En03F-0002b2-06 for w3c-dist-auth@w3.org; Thu, 15 Dec 2005 20:50:21 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1En038-0001Os-Aw; Thu, 15 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Message-Id: <E1En038-0001Os-Aw@newodin.ietf.org> Date: Thu, 15 Dec 2005 15:50:02 -0500 Received-SPF: none (maggie.w3.org: domain of mlee@newodin.ietf.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1En03F-0002b2-06 a65384ac228cf17b8a24ac0f6c478c55 X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-09.txt X-Archived-At: http://www.w3.org/mid/E1En038-0001Os-Aw@newodin.ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11154 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1En03g-0003X4-Nl@frink.w3.org> Resent-Date: Thu, 15 Dec 2005 20:50:36 +0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : HTTP Extensions for Distributed Authoring - WebDAV Author(s) : L. Dusseault Filename : draft-ietf-webdav-rfc2518bis-09.txt Pages : 129 Date : 2005-12-15 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1999, and this specification makes minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-rfc2518bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-15144610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-15144610.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@frink.w3.org Fri Dec 16 03:48:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBGr-0002X5-AY for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 03:48:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18828 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 03:47:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnBF4-0003xy-DO for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 08:47:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnBEt-0003wV-O1 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 08:46:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnBEg-0002QX-MW for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 08:46:54 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBG8kepW027467; Fri, 16 Dec 2005 00:46:40 -0800 Date: Fri, 16 Dec 2005 00:46:40 -0800 Message-Id: <200512160846.jBG8kepW027467@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnBEg-0002QX-MW b292c0afcfd943fe7503671ef342419a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 47] 3xx in multistatus X-Archived-At: http://www.w3.org/mid/200512160846.jBG8kepW027467@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11155 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnBF4-0003xy-DO@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 08:47:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=47 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC|w3c-dist-auth@w3.org | Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 03:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBI1-000340-A8 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 03:50:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18859 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 03:49:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnBHS-0004QV-KK for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 08:49:34 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnBHQ-0004Pf-Eb for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 08:49:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnBGz-0003TW-UK for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 08:49:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBG8n2NN027489; Fri, 16 Dec 2005 00:49:02 -0800 Date: Fri, 16 Dec 2005 00:49:02 -0800 Message-Id: <200512160849.jBG8n2NN027489@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnBGz-0003TW-UK 1a0e91c8d3e911d41759e583ca901aa6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 48] XML extensibility description X-Archived-At: http://www.w3.org/mid/200512160849.jBG8n2NN027489@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11156 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnBHS-0004QV-KK@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 08:49:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC|w3c-dist-auth@w3.org | Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 03:57:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnBP8-0004Nx-VT for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 03:57:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19343 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 03:56:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnBOU-0006RK-1Q for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 08:56:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnBOR-0006QZ-I3 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 08:56:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnBON-0006p3-LA for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 08:56:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBG8uhvX027549; Fri, 16 Dec 2005 00:56:43 -0800 Date: Fri, 16 Dec 2005 00:56:43 -0800 Message-Id: <200512160856.jBG8uhvX027549@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnBON-0006p3-LA 4c2903161a31f3d20840c7c1fa464ef8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 44] OPTIONS * X-Archived-At: http://www.w3.org/mid/200512160856.jBG8uhvX027549@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11157 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnBOU-0006RK-1Q@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 08:56:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:21:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJGa-0005QA-3L for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:21:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18354 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:20:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJFI-0007LC-K2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:19:52 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJF6-0007JE-3H for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:19:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJF2-0000cF-B7 for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:19:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHJLb4028079; Fri, 16 Dec 2005 09:19:21 -0800 Date: Fri, 16 Dec 2005 09:19:21 -0800 Message-Id: <200512161719.jBGHJLb4028079@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJF2-0000cF-B7 9dfa67f62021d2ee467cb789b985c046 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 115] INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/200512161719.jBGHJLb4028079@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11158 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJFI-0007LC-K2@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:19:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=115 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:30:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJPP-00044g-LE for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:30:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19813 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:29:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJOi-0000SX-09 for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:29:36 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnJOf-0000Rw-G1 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:29:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnJOW-0000Ql-Nn for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:29:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHTLaU028105; Fri, 16 Dec 2005 09:29:21 -0800 Date: Fri, 16 Dec 2005 09:29:21 -0800 Message-Id: <200512161729.jBGHTLaU028105@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnJOW-0000Ql-Nn 8c7265423a0f29080cfa3fd245aa80c3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 115] INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/200512161729.jBGHTLaU028105@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJOi-0000SX-09@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:29:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=115 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:29 ------- Discussed during 12/16/2005 teleconference. Consensus on the call is the following: * A complete failure of a DELETE request MAY result in the return of a 4xx status code. * A partial success/partial failure (depending on your worldview) MUST result in the return of a 207 Multi-Status response. Lisa has already made this change in the specification. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:31:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJQv-0004QB-G2 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:31:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20055 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:30:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJQK-00021v-Si for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:31:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJQI-000211-Ci for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:31:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnJQB-0001VM-1C for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:31:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHV6H3028154; Fri, 16 Dec 2005 09:31:06 -0800 Date: Fri, 16 Dec 2005 09:31:06 -0800 Message-Id: <200512161731.jBGHV6H3028154@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnJQB-0001VM-1C 487cf61a34950978982dd9415d1a1029 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 115] INTEROP_DELETE_AND_MULTISTATUS X-Archived-At: http://www.w3.org/mid/200512161731.jBGHV6H3028154@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11160 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJQK-00021v-Si@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:31:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=115 ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:31 ------- *** Bug 117 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:32:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJR2-0004Qr-0t for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:32:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20075 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:31:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJQS-00026F-J1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:31:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJQI-000212-DP for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:31:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnJQA-0001UL-Sq for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:31:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHV6Bb028140; Fri, 16 Dec 2005 09:31:06 -0800 Date: Fri, 16 Dec 2005 09:31:06 -0800 Message-Id: <200512161731.jBGHV6Bb028140@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnJQA-0001UL-Sq edb6347e16161c1bb56421b9faed2a18 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 117] WHEN_TO_MULTISTATUS_FOR_DELETE_1 X-Archived-At: http://www.w3.org/mid/200512161731.jBGHV6Bb028140@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11161 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJQS-00026F-J1@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:31:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=117 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:31 ------- We resolved this issue when we resolved issue #115. *** This bug has been marked as a duplicate of 115 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:40:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJZG-0005WX-1o for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:40:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21463 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:39:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJYc-0004jI-Ty for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:39:50 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnJYa-0004ie-Bc for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:39:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnJYW-0004jg-VL for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:39:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHdiMK028184; Fri, 16 Dec 2005 09:39:44 -0800 Date: Fri, 16 Dec 2005 09:39:44 -0800 Message-Id: <200512161739.jBGHdiMK028184@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnJYW-0004jg-VL b09705379fec85130856b65256239d20 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 118] WHEN_TO_MULTISTATUS_FOR_DELETE_2 X-Archived-At: http://www.w3.org/mid/200512161739.jBGHdiMK028184@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11162 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJYc-0004jI-Ty@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:39:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=118 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- Additional Comments From elias@cse.ucsc.edu 2005-12-16 09:39 ------- Julian volunteered to construct a test case and report the results back to the list. This issue is recognized as an unlikely edge case, but may in fact occur. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:40:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJZY-0005YF-6u for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:40:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21487 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:39:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJYu-0005DL-HF for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:40:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJYs-0005Ce-4C for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:40:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJYp-0000Uu-2T for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:40:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHdtlM028200; Fri, 16 Dec 2005 09:39:55 -0800 Date: Fri, 16 Dec 2005 09:39:55 -0800 Message-Id: <200512161739.jBGHdtlM028200@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJYp-0000Uu-2T 9d4a8b4b54edbaf2db0d43d8b3c02f2e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512161739.jBGHdtlM028200@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11163 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJYu-0005DL-HF@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:40:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:42:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJaz-0005bX-9x for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:42:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21736 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:41:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJaN-0005Sr-At for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:41:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJaL-0005RQ-4d for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:41:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJaH-00014B-JR for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:41:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHfUVf028216; Fri, 16 Dec 2005 09:41:30 -0800 Date: Fri, 16 Dec 2005 09:41:30 -0800 Message-Id: <200512161741.jBGHfUVf028216@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJaH-00014B-JR ca1d940752b3d475528c6b4effffee25 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 118] WHEN_TO_MULTISTATUS_FOR_DELETE_2 X-Archived-At: http://www.w3.org/mid/200512161741.jBGHfUVf028216@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11164 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJaN-0005Sr-At@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:41:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=118 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:44:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJcm-00063E-OR for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:44:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21933 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:43:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJcD-0005gw-CY for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:43:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJc9-0005gO-36 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:43:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnJc6-0006Xp-B5 for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:43:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHhPPD028239; Fri, 16 Dec 2005 09:43:25 -0800 Date: Fri, 16 Dec 2005 09:43:25 -0800 Message-Id: <200512161743.jBGHhPPD028239@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnJc6-0006Xp-B5 884b6924707d903c86526fba77a13dd5 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512161743.jBGHhPPD028239@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11165 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJcD-0005gw-CY@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:43:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-16 09:43 ------- Julian to testn what is currently implemented by servers. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:46:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJf4-00089H-CK for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:46:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22203 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:45:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJeK-0007qb-0H for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:45:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJeD-0007pz-IF for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:45:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJeA-0002du-1P for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:45:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHjQKG028255; Fri, 16 Dec 2005 09:45:26 -0800 Date: Fri, 16 Dec 2005 09:45:26 -0800 Message-Id: <200512161745.jBGHjQKG028255@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJeA-0002du-1P f9052be79271fa11b03f85ba99d29a89 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 123] MULTISTATUS_FROM_MKCOL X-Archived-At: http://www.w3.org/mid/200512161745.jBGHjQKG028255@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11166 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJeK-0007qb-0H@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:45:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=123 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:45 ------- Discussed during 12/16/2005 teleconference. Consensus on the call is that we wish to be silent on the entire subject of MKCOL with request bodies, to leave the field open for a subsequent specification. As a result, we do not wish to specify error reporting behavior at this time. There is nothing in the specification currently that forbids specification of MKCOL with body in the future. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:49:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJiC-0000i1-JD for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:49:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22632 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:48:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJha-0008JD-K1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:49:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJhY-0008Ib-6Y for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:49:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJhO-00040S-JT for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:49:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHmnjO028294; Fri, 16 Dec 2005 09:48:49 -0800 Date: Fri, 16 Dec 2005 09:48:49 -0800 Message-Id: <200512161748.jBGHmnjO028294@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJhO-00040S-JT ec02d4b30414df88e49c6bdcb3256575 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 114] PUT_AND_INTERMEDIATE_COLLECTIONS X-Archived-At: http://www.w3.org/mid/200512161748.jBGHmnjO028294@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11167 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJha-0008JD-K1@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:49:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=114 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:48 ------- Discussed during the 12/16/2005 teleconference. Consensus that we do not want to change the specification because of this issue. Several reasons: * We do not like the side-effect behavior of PUT creating a number of collections. * We don't believe that WebDAV is, in fact, in violation of the HTTP specification on this issue. Resolving, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 12:52:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJl0-0001Or-1c for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:52:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22931 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 12:51:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnJkL-0000yo-1r for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 17:51:57 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnJkI-0000xz-Iq for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 17:51:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnJkD-00057G-9r for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 17:51:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGHpXvi028326; Fri, 16 Dec 2005 09:51:33 -0800 Date: Fri, 16 Dec 2005 09:51:33 -0800 Message-Id: <200512161751.jBGHpXvi028326@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnJkD-00057G-9r f649ef3f457974f4f75f55cde11eac77 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 134] PROPFIND_INFINITY X-Archived-At: http://www.w3.org/mid/200512161751.jBGHpXvi028326@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11168 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnJkL-0000yo-1r@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 17:51:57 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=134 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 09:51 ------- Discussed during the 12/16/2005 teleconference. During the teleconference, Lisa added a note about this to the changes section of the specification. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 13:10:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnK1u-0004d3-4r for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 13:10:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25305 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 13:09:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnK19-0005Yt-Qf for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 18:09:19 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnK17-0005X0-27 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 18:09:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnK0y-0003Vi-0Y for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 18:09:16 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGI8ebs028379; Fri, 16 Dec 2005 10:08:40 -0800 Date: Fri, 16 Dec 2005 10:08:40 -0800 Message-Id: <200512161808.jBGI8ebs028379@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnK0y-0003Vi-0Y 750e31cada05e2f5d19ffceee9083694 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 112] MKCOL_AND_302 X-Archived-At: http://www.w3.org/mid/200512161808.jBGI8ebs028379@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11169 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnK19-0005Yt-Qf@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 18:09:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 10:08 ------- Discussed during the 12/16/2005 teleconference. Agreed that this issue should be discussed just in one place in the specification, and should address all 3xx status code behavior. Elias noted that there is already a statement in the specification concerning the applicability of 3xx for all webdav methods. There was some discussion concerning whether the specification should explicitly state that if a server returns a 301 oor 302, then the server should not have created a resource (or made a state change) to the Request-URI for PUT, PROPPATCH, and MKCOL. We decided that the best course would be to just say nothing here. Closing the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 13:37:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKSW-00055w-9d for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 13:37:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29070 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 13:36:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnKRP-0003wE-0K for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 18:36:27 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnKRI-0003vB-HA for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 18:36:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnKRC-0004D3-LS for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 18:36:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGIaBdM028424; Fri, 16 Dec 2005 10:36:11 -0800 Date: Fri, 16 Dec 2005 10:36:11 -0800 Message-Id: <200512161836.jBGIaBdM028424@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnKRC-0004D3-LS c554227fb41e8020976bbae7b8cc55f0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512161836.jBGIaBdM028424@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11170 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnKRP-0003wE-0K@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 18:36:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|elias@cse.ucsc.edu |lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 10:36 ------- Discussed during 12/16/2005 teleconference. Resolved during the call to have Lisa put together a query to existing implementors of WebDAV servers concerning their opinions on the lock and multiple bindings to resources issue. Lisa would like additional input from implementors before agreeing to any resolution on this issue. Lisa has agreed to draft the text going to the list and/or implementors, to query them on this issue. Telecon felt it would be good for the query email sent to implementors to include a link to the GULP document (for broader context), and a link to the start of the recent email thread on this issue (in case implementors wanted to read the most recent discussion). Assigning the issue to Lisa. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 13:53:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKi5-00083I-PS for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 13:53:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00402 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 13:52:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnKhJ-00089H-ET for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 18:52:53 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnKhH-00088j-6M for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 18:52:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnKft-0002EY-9U for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 18:52:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGIpOsm028481; Fri, 16 Dec 2005 10:51:24 -0800 Date: Fri, 16 Dec 2005 10:51:24 -0800 Message-Id: <200512161851.jBGIpOsm028481@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnKft-0002EY-9U 4349aed91e3bddc3d65ffac50575904a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 156] HOW_ARE_TRAILING_SLASHES_USED X-Archived-At: http://www.w3.org/mid/200512161851.jBGIpOsm028481@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11171 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnKhJ-00089H-ET@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 18:52:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=156 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 10:51 ------- Discussed during the 12/16/2005 teleconference. Parts of this issue were resolved in issue #16. The other questions raised are addressed by RFC 3986, which clearly explains rules for determining the equivalence of URIs, and for handling multiple slashes. Closing the issue, WONTFIX. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 14:06:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKuu-0002rP-Fn for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 14:06:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01789 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 14:05:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnKuF-0004Nz-M4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 19:06:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnKu3-0004Mj-0k for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 19:06:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnKtx-0008AT-Me for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 19:06:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGJ4ucq028527; Fri, 16 Dec 2005 11:04:56 -0800 Date: Fri, 16 Dec 2005 11:04:56 -0800 Message-Id: <200512161904.jBGJ4ucq028527@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnKtx-0008AT-Me 1e07c9746bf3e5c3c8495a16e4f6fb1b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200512161904.jBGJ4ucq028527@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11172 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnKuF-0004Nz-M4@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 19:06:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 14:11:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnKzN-0004ax-Gm for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 14:11:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02388 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 14:10:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnKyl-0005kI-Kd for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 19:10:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnKyj-0005jK-Cg for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 19:10:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnKyf-0000wZ-9H for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 19:10:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGJAm35028553; Fri, 16 Dec 2005 11:10:48 -0800 Date: Fri, 16 Dec 2005 11:10:48 -0800 Message-Id: <200512161910.jBGJAm35028553@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnKyf-0000wZ-9H b1e1c00666d002153f19bd55d573e7c2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200512161910.jBGJAm35028553@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnKyl-0005kI-Kd@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 19:10:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From ejw@cs.ucsc.edu 2005-12-16 11:10 ------- Discussed during the 12/16/2005 teleconference. We noted that the driving case for implementing this feature is the desire to replicate file system semantics for delete on a collection, in which the delete succeeds only if the collection is entirely empty. It is currently difficult to achieve these semantics with WebDAV right now. One problem with simply introducing Depth 0 DELETE into the specification is that clients would then need a way to discover that this capability was supported. On the other hand, RFC 2518 explicitly states that servers MUST only allow Depth with value of infinity. This means that if 2518 servers receive a Depth 0 DELETE they should reject it, opening the possibility that 2518bis servers could allow it. There was also some discussion concerning whether we would want to address this problem using a state token for the collection, and then use the existing If header to test the state token. This might also have the benefit of supporting synchronization of collections as well. Julian will perform research on whether servers consistly implement the rejection semantics. Since this is part of a larger design space, and since we don't currently have a mandate to add new features, consensus was to resolve, WONTFIX. We encourage Julian to perform this research. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 14:45:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLWI-0004gV-65 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 14:45:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05681 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 14:44:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnLVF-00070M-Nm for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 19:44:29 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnLV8-0006zj-Lj for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 19:44:23 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EnLV3-0007UA-Uu for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 19:44:21 +0000 Received: (qmail invoked by alias); 16 Dec 2005 19:44:11 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp014) with SMTP; 16 Dec 2005 20:44:11 +0100 X-Authenticated: #1915285 Message-ID: <43A31895.9090205@gmx.de> Date: Fri, 16 Dec 2005 20:42:13 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> CC: w3c-dist-auth@w3.org References: <200512071926.jB7JQrST002262@ietf.cse.ucsc.edu> <4398472E.2020600@gmx.de> In-Reply-To: <4398472E.2020600@gmx.de> Content-Type: multipart/mixed; boundary="------------000608070504090505080207" X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnLV3-0007UA-Uu 38003393bac6b0fb627cbc142cb1313e X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A31895.9090205@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11174 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnLVF-00070M-Nm@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 19:44:29 +0000 This is a multi-part message in MIME format. --------------000608070504090505080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit During today's teleconference, we came across another disagreement, where it was questioned that GULP's [1] statement about URLs being protected by a LOCK: " - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request." indeed reflects what servers do. I just tested a MOVE on a collection containing one locked child resource, and 4 out of 4 tested servers (Xythos, Apache, MS IIS 5.1, SAP KM) rejected the request. All except IIS returned a 423 (IIS returned a 207 with a 423 status contained). Thus I'll conclude that GULP here indeed describes what servers do (test case attached). We can probably go on like this for a long time, but at this point I don't see any way to make progress here unless those who dislike GULP come up with concrete examples of where it fails to describe running code, and then optimally make suggestions about how to fix this. Best regards, Julian [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html> --------------000608070504090505080207 Content-Type: application/x-javascript; name="url_protection.js" Content-Disposition: inline; filename="url_protection.js" Content-Transfer-Encoding: 7bit var req = new ActiveXObject ("MSXML2.ServerXMLHTTP"); var uri = WScript.Arguments(0); var user = null; var pwd = null; if (WScript.Arguments.length > 1) { user = WScript.Arguments(1); } if (WScript.Arguments.length > 2) { pwd = WScript.Arguments(2); } function dumpResponse(r) { WScript.Echo(r.status); WScript.Echo(r.getAllResponseHeaders()); WScript.Echo(r.responseText); } // create collection WScript.Echo("MKCOL " + uri); req.open("MKCOL", uri, false, user, pwd); req.send(); if ((req.status < 200 || req.status >= 300) && req.status != 405) { WScript.Echo("unexpected status upon MKCOL:" + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); // put content WScript.Echo("PUT " + uri + "/a"); req.open("PUT", uri + "/a", false, user, pwd); req.send("foobar"); if (req.status < 200 || req.status >= 300) { WScript.Echo("unexpected status upon PUT: " + req.status + " " + req.responseText); WScript.Quit(2); } dumpResponse(req); WScript.Echo("LOCK " + uri + "/a") ; req.open("LOCK", uri + "/a", false, user, pwd); req.setRequestHeader("Depth", "infinity"); req.setRequestHeader("Timeout", "Second-60"); req.send("<D:lockinfo xmlns:D='DAV:'><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype></D:lockinfo>"); dumpResponse(req); var locktoken = null; try { locktoken = req.getResponseHeader("lock-token"); } catch (x) {} if (req.status == 200 || req.status == 201) { WScript.Echo("locktoken: " + locktoken); } else { WScript.Echo("resource not locked, status: " + req.status + " " + req.responseText); WScript.Quit(2); } // attempt MOVE parent collection without If header //WScript.Echo("MOVE " + uri + " to " + uri + "2"); //req.open("MOVE", uri + "/a", false, user, pwd); //req.setRequestHeader("Destination", uri + "2"); //req.send(); //dumpResponse(req); // attempt MOVE parent collection with If header WScript.Echo("MOVE " + uri + " to " + uri + "2"); req.open("MOVE", uri + "/a", false, user, pwd); req.setRequestHeader("Destination", uri + "2"); req.setRequestHeader("If", "<" + uri + "/a> (" + locktoken + ")"); req.send(); dumpResponse(req); --------------000608070504090505080207-- From w3c-dist-auth-request@frink.w3.org Fri Dec 16 14:50:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLaa-00062z-AQ for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 14:50:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06204 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 14:48:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnLa0-00015B-9y for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 19:49:24 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnLZx-000145-TX for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 19:49:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnLZs-0001Xm-A0 for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 19:49:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBGJnDrn028579; Fri, 16 Dec 2005 11:49:13 -0800 Date: Fri, 16 Dec 2005 11:49:13 -0800 Message-Id: <200512161949.jBGJnDrn028579@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnLZs-0001Xm-A0 4c28c406506d03b6b1f8f165f4944ebd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 154] ADD_DEPTH_ZERO_DELETE X-Archived-At: http://www.w3.org/mid/200512161949.jBGJnDrn028579@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11175 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnLa0-00015B-9y@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 19:49:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=154 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-16 11:49 ------- I checked with 4 servers, 3 of which rejected a Depth: 0 DELETE with 400 as expected. Only Xythos was ignoring the request, doing the DELETE anyway (I'll send them a bug report). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 16 15:03:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnLnT-0001t7-9N for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 15:03:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07912 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 15:02:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnLmn-0004OZ-FS for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 20:02:37 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnLme-0004Mq-C7 for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 20:02:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnLmb-0005Km-DH for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 20:02:28 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BC9721422F1; Fri, 16 Dec 2005 12:02:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <00282f8bf53f6b5e1efc4a2cb95d801b@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Eric Sedlar <eric.sedlar@oracle.com>, greg stein <gstein@lyra.org>, Helge Hess <helge.hess@opengroupware.org>, Barry Lind <blind@xythos.com>, WebDav WG <w3c-dist-auth@w3.org>, Larry Masinter <LMM@acm.org>, Dan Brotsky <dbrotsky@adobe.com>, Chris Sharp <csharp@apple.com>, Jim Luther <luther.j@apple.com>, Stanley Guan <stanley.guan@oracle.com>, Kevin Wiggen <kwiggen@xythos.com> From: Lisa Dusseault <lisa@osafoundation.org> Date: Fri, 16 Dec 2005 12:02:15 -0800 X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EnLmb-0005Km-DH 4200ec83755ad65d4ce49f0337aacf23 X-Original-To: w3c-dist-auth@w3.org Subject: Question for implementors: definition of Lock with bindings X-Archived-At: http://www.w3.org/mid/00282f8bf53f6b5e1efc4a2cb95d801b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11176 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnLmn-0004OZ-FS@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 20:02:37 +0000 Content-Transfer-Encoding: 7bit In the current proposed model of locking and binding (GULP -- several emails recently with pointers), it's defined that a lock covers the binding that the LOCK request that was sent to and the resource that the binding maps to. Another possible definition of the scope of a lock could be that the lock would cover the resource that the binding maps to and ALL bindings. One consequence of choosing between these two models is the cases in which DELETE of a locked resource requires the lock token. According to the first definition, DELETE requires a lock token only if the locked binding is addressed; all other bindings can be removed without needing a lock token. According to the second definition, DELETE of a locked resource always requires the lock token. Please answer with your model preference and reasoning so that we can close this issue. We'd particularly like to know if this affects an implementation -- an implementation that supports BIND, or has custom bindings through file system links (mod_dav?), or could otherwise be affected. Thanks! Lisa Dusseault From w3c-dist-auth-request@frink.w3.org Fri Dec 16 15:51:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMYZ-0003ZW-J6 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 15:51:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12898 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 15:50:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnMX4-0000Lr-4L for w3c-dist-auth-dist@listhub.w3.org; Fri, 16 Dec 2005 20:50:26 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnMWs-0000L9-HD for w3c-dist-auth@listhub.w3.org; Fri, 16 Dec 2005 20:50:14 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.mag.keio.ac.jp with smtp (Exim 4.50) id 1EnMWj-0000Ls-51 for w3c-dist-auth@w3.org; Fri, 16 Dec 2005 20:50:13 +0000 Received: (qmail invoked by alias); 16 Dec 2005 20:50:01 -0000 Received: from p508FA1DE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.161.222] by mail.gmx.net (mp035) with SMTP; 16 Dec 2005 21:50:01 +0100 X-Authenticated: #1915285 Message-ID: <43A32828.6000301@gmx.de> Date: Fri, 16 Dec 2005 21:48:40 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault <lisa@osafoundation.org> CC: Eric Sedlar <eric.sedlar@oracle.com>, greg stein <gstein@lyra.org>, Helge Hess <helge.hess@opengroupware.org>, Barry Lind <blind@xythos.com>, WebDav WG <w3c-dist-auth@w3.org>, Larry Masinter <LMM@acm.org>, Dan Brotsky <dbrotsky@adobe.com>, Chris Sharp <csharp@apple.com>, Jim Luther <luther.j@apple.com>, Stanley Guan <stanley.guan@oracle.com>, Kevin Wiggen <kwiggen@xythos.com> References: <00282f8bf53f6b5e1efc4a2cb95d801b@osafoundation.org> In-Reply-To: <00282f8bf53f6b5e1efc4a2cb95d801b@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnMWj-0000Ls-51 17fcb3bb49f8dea2410bc018f196b79b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question for implementors: definition of Lock with bindings X-Archived-At: http://www.w3.org/mid/43A32828.6000301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnMX4-0000Lr-4L@frink.w3.org> Resent-Date: Fri, 16 Dec 2005 20:50:26 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > In the current proposed model of locking and binding (GULP -- several > emails recently with pointers), it's defined that a lock covers the Rather then letting people search for these messages, why not include a link??? GULP: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html> > binding that the LOCK request that was sent to and the resource that the > binding maps to. Actually, the URL, not the binding: " - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request." > Another possible definition of the scope of a lock could be that the > lock would cover the resource that the binding maps to and ALL bindings. Previously discussed in <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1042.html>... > One consequence of choosing between these two models is the cases in > which DELETE of a locked resource requires the lock token. According to > the first definition, DELETE requires a lock token only if the locked > binding is addressed; all other bindings can be removed without needing > a lock token. According to the second definition, DELETE of a locked > resource always requires the lock token. > > Please answer with your model preference and reasoning so that we can > close this issue. We'd particularly like to know if this affects an > implementation -- an implementation that supports BIND, or has custom > bindings through file system links (mod_dav?), or could otherwise be > affected. The effect of requiring all URLs to be protected by the lock are: - more complexity in server - loss of symmetry (why is it possible to add a binding without having the lock token, but not to remove the same binding later?) - questionable client semantics (exactly why would a client care?? please provide a use case that justifies the additional requirements). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 16 19:15:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnPj1-0004Nc-45 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 19:15:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04853 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 19:13:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnPhl-0007Wo-19 for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 00:13:41 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnPhZ-0007W5-Oi for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 00:13:29 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnPhV-0005vu-4X for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 00:13:28 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 400C514228D for <w3c-dist-auth@w3.org>; Fri, 16 Dec 2005 16:13:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <6838cd252ee223d014909300aeddea4c@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDav WG <w3c-dist-auth@w3.org> From: Lisa Dusseault <lisa@osafoundation.org> Date: Fri, 16 Dec 2005 16:13:21 -0800 X-Mailer: Apple Mail (2.623) Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EnPhV-0005vu-4X 069f6e7e2fc4ddb63afa7fb789979c13 X-Original-To: w3c-dist-auth@w3.org Subject: Bindings and permissions X-Archived-At: http://www.w3.org/mid/6838cd252ee223d014909300aeddea4c@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11178 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnPhl-0007Wo-19@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 00:13:41 +0000 Content-Transfer-Encoding: 7bit I was thinking about the bindings and permissions stuff today. I've discussed it before but this may be a new take on the subject. Recall we don't really know what the behavior is with dynamically inherited ACLs (when a parent's ACLs automatically apply to its child resources) when some of those children are bindings to resources that also have bindings. Some of the possible solutions to this: 1. Directory permissions are not dynamically applicable to children or at least to bindings. 2. You can't bind resources into directories that have different ACLs than where they're bound already - server returns 403 or something 3. Permissions are path-dependent. 4. Not all bindings are first-class -- there's a "real name" and then there are aliases. The collection containing the "real name" is the one that inherits permissions 5. There's some algorithm for "summing" or "intersecting" the permissions according to the parents of all the bindings. There may be other possible models. It seems to me clients have no way of knowing which solution the server has chosen and behavior can be quite unpredictable. Is there some way to advertise the server's model? Are some of these choices forbidden? Of those that aren't forbidden, is one of them recommended? It would be extremely surprising if the 'bind' privilege grants somebody the ability to make a new mapping of a resource into a new directory, AND that a consequence of that 'bind' operation is to change the permissions on the underlying resource -- without requiring 'writeacl' privilege. Since that's a possible security hole, what should that be -- a MUST NOT? A security consideration? Lisa From w3c-dist-auth-request@frink.w3.org Fri Dec 16 21:31:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnRqv-0006Gq-J9 for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 21:31:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19559 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 21:30:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnRpV-00067E-QH for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 02:29:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnRpK-00060g-1b; Sat, 17 Dec 2005 02:29:38 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnRpA-0001SZ-UU; Sat, 17 Dec 2005 02:29:36 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBH2TRLk004029; Fri, 16 Dec 2005 21:29:27 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBH2TRb1123210; Fri, 16 Dec 2005 21:29:27 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBH2TRPq018217; Fri, 16 Dec 2005 21:29:27 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBH2TRrR018214; Fri, 16 Dec 2005 21:29:27 -0500 In-Reply-To: <6838cd252ee223d014909300aeddea4c@osafoundation.org> To: Lisa Dusseault <lisa@osafoundation.org> Cc: WebDav WG <w3c-dist-auth@w3.org>, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> Message-ID: <OFC5D7588D.795A2117-ON852570DA.000D628D-852570DA.000DAC65@us.ibm.com> Date: Fri, 16 Dec 2005 21:29:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/16/2005 21:29:27, Serialize complete at 12/16/2005 21:29:27 Content-Type: multipart/alternative; boundary="=_alternative 000DABED852570DA_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EnRpA-0001SZ-UU d8ecb0dc35fc9b1cbf69d977d845fd03 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bindings and permissions X-Archived-At: http://www.w3.org/mid/OFC5D7588D.795A2117-ON852570DA.000D628D-852570DA.000DAC65@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11179 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnRpV-00067E-QH@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 02:29:49 +0000 This is a multipart message in MIME format. --=_alternative 000DABED852570DA_= Content-Type: text/plain; charset="US-ASCII" There are ways to model this kind of thing, but the guidance we received for the ACL spec is that the resulting ACL model is too complicated, which is why we ended up with a much simpler model (that cannot model this kind of thing). So I think the simple answer is "no, there is no way for a client to find out about complex ACL situations such as the ones you describe" (unless the IESG changes its mind about how complex an ACL model is acceptable). Cheers, Geoff Lisa wrote on 12/16/2005 07:13:21 PM: > > > I was thinking about the bindings and permissions stuff today. I've > discussed it before but this may be a new take on the subject. Recall > we don't really know what the behavior is with dynamically inherited > ACLs (when a parent's ACLs automatically apply to its child resources) > when some of those children are bindings to resources that also have > bindings. Some of the possible solutions to this: > > 1. Directory permissions are not dynamically applicable to children or > at least to bindings. > 2. You can't bind resources into directories that have different ACLs > than where they're bound already - server returns 403 or something > 3. Permissions are path-dependent. > 4. Not all bindings are first-class -- there's a "real name" and then > there are aliases. The collection containing the "real name" is the > one that inherits permissions > 5. There's some algorithm for "summing" or "intersecting" the > permissions according to the parents of all the bindings. > > There may be other possible models. > > It seems to me clients have no way of knowing which solution the server > has chosen and behavior can be quite unpredictable. Is there some way > to advertise the server's model? Are some of these choices forbidden? > Of those that aren't forbidden, is one of them recommended? > > It would be extremely surprising if the 'bind' privilege grants > somebody the ability to make a new mapping of a resource into a new > directory, AND that a consequence of that 'bind' operation is to change > the permissions on the underlying resource -- without requiring > 'writeacl' privilege. Since that's a possible security hole, what > should that be -- a MUST NOT? A security consideration? > > Lisa > > --=_alternative 000DABED852570DA_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>There are ways to model this kind of thing, but the guidance we</tt></font> <br><font size=2><tt>received for the ACL spec is that the resulting ACL model is too</tt></font> <br><font size=2><tt>complicated, which is why we ended up with a much simpler model</tt></font> <br><font size=2><tt>(that cannot model this kind of thing).  So I think the simple answer</tt></font> <br><font size=2><tt>is "no, there is no way for a client to find out about complex</tt></font> <br><font size=2><tt>ACL situations such as the ones you describe" (unless the IESG</tt></font> <br><font size=2><tt>changes its mind about how complex an ACL model is acceptable).</tt></font> <br> <br><font size=2><tt>Cheers,</tt></font> <br><font size=2><tt>Geoff</tt></font> <br> <br> <br><font size=2><tt>Lisa wrote on 12/16/2005 07:13:21 PM:<br> <br> > <br> > <br> > I was thinking about the bindings and permissions stuff today.  I've <br> > discussed it before but this may be a new take on the subject.  Recall <br> > we don't really know what the behavior is with dynamically inherited <br> > ACLs (when a parent's ACLs automatically apply to its child resources) <br> > when some of those children are bindings to resources that also have <br> > bindings.  Some of the possible solutions to this:<br> > <br> > 1.  Directory permissions are not dynamically applicable to children or <br> > at least to bindings.<br> > 2.  You can't bind resources into directories that have different ACLs <br> > than where they're bound already - server returns 403 or something<br> > 3.  Permissions are path-dependent.<br> > 4.  Not all bindings are first-class -- there's a "real name" and then <br> > there are aliases.  The collection containing the "real name" is the <br> > one that inherits permissions<br> > 5.  There's some algorithm for "summing" or "intersecting" the <br> > permissions according to the parents of all the bindings.<br> > <br> > There may be other possible models.<br> > <br> > It seems to me clients have no way of knowing which solution the server <br> > has chosen and behavior can be quite unpredictable.  Is there some way <br> > to advertise the server's model? Are some of these choices forbidden?  <br> > Of those that aren't forbidden, is one of them recommended?<br> > <br> > It would be extremely surprising if the 'bind' privilege grants <br> > somebody the ability to make a new mapping of a resource into a new <br> > directory, AND that a consequence of that 'bind' operation is to change <br> > the permissions on the underlying resource -- without requiring <br> > 'writeacl' privilege.  Since that's a possible security hole, what <br> > should that be -- a MUST NOT?  A security consideration?<br> > <br> > Lisa<br> > <br> > <br> </tt></font> --=_alternative 000DABED852570DA_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 16 21:39:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnRyP-0007ze-Vj for webdav-archive@megatron.ietf.org; Fri, 16 Dec 2005 21:39:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20170 for <webdav-archive@lists.ietf.org>; Fri, 16 Dec 2005 21:37:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnRxj-0000kD-35 for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 02:38:19 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnRxg-0000jL-7Y; Sat, 17 Dec 2005 02:38:16 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnRxb-0001rG-UE; Sat, 17 Dec 2005 02:38:15 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBH2c8mM018445; Fri, 16 Dec 2005 21:38:08 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBH2c87O123130; Fri, 16 Dec 2005 21:38:08 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBH2c7LR006887; Fri, 16 Dec 2005 21:38:08 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBH2c7dY006882; Fri, 16 Dec 2005 21:38:07 -0500 In-Reply-To: <43A31895.9090205@gmx.de> To: Julian Reschke <julian.reschke@gmx.de> Cc: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> Message-ID: <OF4339235C.8B26470A-ON852570DA.000E1684-852570DA.000E77D3@us.ibm.com> Date: Fri, 16 Dec 2005 21:38:07 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/16/2005 21:38:07, Serialize complete at 12/16/2005 21:38:07 Content-Type: multipart/alternative; boundary="=_alternative 000E775C852570DA_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnRxb-0001rG-UE 409583163144b592cff70f106d952ad6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF4339235C.8B26470A-ON852570DA.000E1684-852570DA.000E77D3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11180 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnRxj-0000kD-35@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 02:38:19 +0000 This is a multipart message in MIME format. --=_alternative 000E775C852570DA_= Content-Type: text/plain; charset="US-ASCII" +1 for Julian's suggestion about how to make progress. In particular, I suggest we provide some kind of deadline for identifying such instances of where GULP incorrectly describes current locking behavior of the majority of current implementations. If no such instances are identified I suggest we just adopt the GULP text as currently written, so that we can close down this thread and make progress on the remaining other issues. Cheers, Geoff Julian wrote on 12/16/2005 02:42:13 PM: > During today's teleconference, we came across another disagreement, > where it was questioned that GULP's [1] statement about URLs being > protected by a LOCK: > > " - If a request causes a directly locked resource to no longer be > mapped to the lock-root of that lock, then the request MUST > fail unless the lock-token for that lock is submitted in the > request. If the request succeeds, then that lock MUST have been > deleted by that request." > > indeed reflects what servers do. > > I just tested a MOVE on a collection containing one locked child > resource, and 4 out of 4 tested servers (Xythos, Apache, MS IIS 5.1, SAP > KM) rejected the request. All except IIS returned a 423 (IIS returned a > 207 with a 423 status contained). > > Thus I'll conclude that GULP here indeed describes what servers do (test > case attached). > > We can probably go on like this for a long time, but at this point I > don't see any way to make progress here unless those who dislike GULP > come up with concrete examples of where it fails to describe running > code, and then optimally make suggestions about how to fix this. > > Best regards, Julian > > > [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html> > [attachment "url_protection.js" deleted by Geoffrey M Clemm/Lexington/IBM] --=_alternative 000E775C852570DA_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>+1 for Julian's suggestion about how to make progress.</tt></font> <br> <br><font size=2><tt>In particular, I suggest we provide some kind of deadline for</tt></font> <br><font size=2><tt>identifying such instances of where GULP incorrectly describes</tt></font> <br><font size=2><tt>current locking behavior of the majority of current implementations.</tt></font> <br><font size=2><tt>If no such instances are identified I suggest we just adopt</tt></font> <br><font size=2><tt>the GULP text as currently written, so that we can close down</tt></font> <br><font size=2><tt>this thread and make progress on the remaining other issues.</tt></font> <br> <br><font size=2><tt>Cheers,</tt></font> <br><font size=2><tt>Geoff</tt></font> <br> <br><font size=2><tt>Julian wrote on 12/16/2005 02:42:13 PM:<br> <br> > During today's teleconference, we came across another disagreement, <br> > where it was questioned that GULP's [1] statement about URLs being <br> > protected by a LOCK:<br> > <br> > " - If a request causes a directly locked resource to no longer be<br> >      mapped to the lock-root of that lock, then the request MUST<br> >      fail unless the lock-token for that lock is submitted in the<br> >      request.  If the request succeeds, then that lock MUST have been<br> >      deleted by that request."<br> > <br> > indeed reflects what servers do.<br> > <br> > I just tested a MOVE on a collection containing one locked child <br> > resource, and 4 out of 4 tested servers (Xythos, Apache, MS IIS 5.1, SAP <br> > KM) rejected the request. All except IIS returned a 423 (IIS returned a <br> > 207 with a 423 status contained).<br> > <br> > Thus I'll conclude that GULP here indeed describes what servers do (test <br> > case attached).<br> > <br> > We can probably go on like this for a long time, but at this point I <br> > don't see any way to make progress here unless those who dislike GULP <br> > come up with concrete examples of where it fails to describe running <br> > code, and then optimally make suggestions about how to fix this.<br> > <br> > Best regards, Julian<br> > <br> > <br> > [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html><br> > [attachment "url_protection.js" deleted by Geoffrey M Clemm/Lexington/IBM] </tt></font> --=_alternative 000E775C852570DA_=-- From w3c-dist-auth-request@frink.w3.org Sat Dec 17 06:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnaE8-0006SM-TI for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 06:27:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11750 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 06:26:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnaCV-0006FI-12 for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 11:26:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnaCK-0006ED-88 for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 11:25:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnaCG-0005gO-HF for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 11:25:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHBPkuS029078; Sat, 17 Dec 2005 03:25:46 -0800 Date: Sat, 17 Dec 2005 03:25:46 -0800 Message-Id: <200512171125.jBHBPkuS029078@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnaCG-0005gO-HF 1eb5ac5be9579d5a387681df30198559 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512171125.jBHBPkuS029078@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11181 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnaCV-0006FI-12@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 11:26:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 03:25 ------- OK, I believe I have completed my changes. As usual, see them in context at <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz085> In Section 8, NEW: 8.1.6 Impacts of Namespace Operations on Cacheability Note that the HTTP response headers "Etag" and "Last-Modified" (see [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per resource), and are used by clients for caching. Therefore servers must ensure that executing any operation that affects the URL namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve their semantics, in particular: o For any given URL, the "Last-Modified" value must increment every time the representation returned upon GET changes (within the limits of timestamp resolution). o For any given URL, no "ETag" value must ever be re-used for different representations returned by GET. In practice this means that servers o may have to increment "Last-Modified" timestamps for every resource inside the destination namespace of a namespace operation, and o similarily, may have to re-assign "ETag" values for these resources (unless the server allocates entity tags in a way so that they are unique across the whole URL namespace managed by the server). Note that these considerations also apply to specific use cases, such as using PUT creating a new resource at a URL that has been mapped before, but has been deleted since then. Finally, WebDAV properties (such as DAV:getetag and DAV: getlastmodified) that inherit their semantics from HTTP headers must behave accordingly. In the description for DAV:getetag: OLD: COPY/MOVE behaviour: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. NEW: COPY/MOVE behaviour: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. Also note the cacheability considerations in Section 8.1.6. In the description for DAV:getlastmodified: Section 14., para. 56: OLD: COPY/MOVE behaviour: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this is preserved in a MOVE even when the HTTP Last-Modified value SHOULD change. Thus, clients cannot rely on this value for caching and SHOULD use ETags. NEW: COPY/MOVE behaviour: This property value is dependent on the last modified date of the destination resource, not the value of the property on the source resource. Also note the cacheability considerations in Section 8.1.6. Note that tis particular change removes language that contradicts RFC2616 (we can't simply tell people that RFC2616 doesn't count anymore, at least not without strong WG consensus). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 06:43:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnaTM-0001PT-Cn for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 06:43:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13206 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 06:42:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnaSY-00012N-Sj for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 11:42:42 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnaSW-00011i-1K for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 11:42:40 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EnaSS-00033f-7Y for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 11:42:39 +0000 Received: (qmail invoked by alias); 17 Dec 2005 11:42:10 -0000 Received: from p508F9D0E.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.157.14] by mail.gmx.net (mp037) with SMTP; 17 Dec 2005 12:42:10 +0100 X-Authenticated: #1915285 Message-ID: <43A3F936.6040309@gmx.de> Date: Sat, 17 Dec 2005 12:40:38 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512171125.jBHBPkuS029078@ietf.cse.ucsc.edu> In-Reply-To: <200512171125.jBHBPkuS029078@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnaSS-00033f-7Y fa791300413dd78dc86ec796b3885153 X-Original-To: w3c-dist-auth@w3.org Subject: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/43A3F936.6040309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11182 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnaSY-00012N-Sj@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 11:42:42 +0000 Content-Transfer-Encoding: 7bit Hi. With the inclusion of the proposed text below in RFC2518bius, we'd be closing an issue that was raised in spring while discussing BIND. In the subsequent discussion (summarized in <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-properties-latest.html>) we found that it's not a problem specific to BIND at all, because it applies to any operation that creates new resources or moves them. Since then BIND has passed (a third!) working group last call, with no new issues raised. So here's my current understanding of where we stand with BIND. Feedback appreciated. 1) BIND is finished, however it's currently on hold because we're busy with RFC2518bis. 2) Should the working group manage to complete RFC2518bis as planned, we can slightly revise the current BIND draft, taking out stuff that's not needed anymore, namely <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.html#rfc.section.1.3> ("preconditions and postconditions"), parts of <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.html#rfc.section.2.4> (discussion of broken DELETE semantics of RFC2518bis), and parts of <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.html#rfc.section.8.2> (introduction of "DAV" request header). As these changes would be purely editorial, I'll assume we wouldn't want to do another WGLC. 3) On the other hand, should the working group fail to finish RFC2518bis, we'll submit BIND as is. Best regards, Julian bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 03:25 ------- > OK, I believe I have completed my changes. As usual, see them in context at > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz085> > > > In Section 8, NEW: > > 8.1.6 Impacts of Namespace Operations on Cacheability > > Note that the HTTP response headers "Etag" and "Last-Modified" (see > [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per > resource), and are used by clients for caching. Therefore servers > must ensure that executing any operation that affects the URL > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve > their semantics, in particular: > > o For any given URL, the "Last-Modified" value must increment every > time the representation returned upon GET changes (within the > limits of timestamp resolution). > > o For any given URL, no "ETag" value must ever be re-used for > different representations returned by GET. > > In practice this means that servers > > o may have to increment "Last-Modified" timestamps for every > resource inside the destination namespace of a namespace > operation, and > > o similarily, may have to re-assign "ETag" values for these > resources (unless the server allocates entity tags in a way so > that they are unique across the whole URL namespace managed by the > server). > > Note that these considerations also apply to specific use cases, such > as using PUT creating a new resource at a URL that has been mapped > before, but has been deleted since then. > > Finally, WebDAV properties (such as DAV:getetag and DAV: > getlastmodified) that inherit their semantics from HTTP headers must > behave accordingly. > > In the description for DAV:getetag: > > OLD: > > COPY/MOVE behaviour: This property value is dependent on the final > state of the destination resource, not the value of the property > on the source resource. > > NEW: > > COPY/MOVE behaviour: This property value is dependent on the final > state of the destination resource, not the value of the property > on the source resource. Also note the cacheability considerations > in Section 8.1.6. > > In the description for DAV:getlastmodified: > > Section 14., para. 56: > OLD: > > COPY/MOVE behaviour: This property value is dependent on the last > modified date of the destination resource, not the value of the > property on the source resource. Note that some server > implementations use the file system date modified value for the > DAV:getlastmodified value, and this is preserved in a MOVE even > when the HTTP Last-Modified value SHOULD change. Thus, clients > cannot rely on this value for caching and SHOULD use ETags. > > NEW: > > COPY/MOVE behaviour: This property value is dependent on the last > modified date of the destination resource, not the value of the > property on the source resource. Also note the cacheability > considerations in Section 8.1.6. > > Note that tis particular change removes language that contradicts RFC2616 (we > can't simply tell people that RFC2616 doesn't count anymore, at least not > without strong WG consensus). From w3c-dist-auth-request@frink.w3.org Sat Dec 17 07:39:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnbLb-0005sn-7v for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 07:39:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18464 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 07:38:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnbKR-0004jV-EX for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 12:38:23 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnbKJ-0004iV-2E for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 12:38:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnbKE-0007Hm-1a for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 12:38:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHCc8vu029325; Sat, 17 Dec 2005 04:38:08 -0800 Date: Sat, 17 Dec 2005 04:38:08 -0800 Message-Id: <200512171238.jBHCc8vu029325@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnbKE-0007Hm-1a 4f71f12c7db08c32c7a3e1cc698d6670 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512171238.jBHCc8vu029325@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11183 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnbKR-0004jV-EX@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 12:38:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 04:38 ------- Created an attachment (id=1) --> (http://ietf.cse.ucsc.edu:8080/bugzilla/attachment.cgi?id=1&action=view) test case ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 07:41:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnbNZ-0006OM-O3 for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 07:41:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18951 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 07:40:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnbN1-0005Ot-37 for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 12:41:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnbMy-0005O9-QC for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 12:41:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnbMw-0003ox-5z for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 12:41:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHCeu4Y029341; Sat, 17 Dec 2005 04:40:56 -0800 Date: Sat, 17 Dec 2005 04:40:56 -0800 Message-Id: <200512171240.jBHCeu4Y029341@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnbMw-0003ox-5z c2f117fc03b81d9be9e36baf76aefee2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512171240.jBHCeu4Y029341@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11184 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnbN1-0005Ot-37@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 12:41:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 04:40 ------- I tested with Xythos, IIS, Apache and SAP NW. All of them returned a multistatus body with one entry for the resource causing the request to fail. All returned this with 207 except Apache which returned it with a 424. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 10:44:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EneEm-0007qd-S8 for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 10:44:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07452 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 10:43:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EneDO-0001hj-HR for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 15:43:18 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EneDD-0001fi-4h; Sat, 17 Dec 2005 15:43:07 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EneCr-00072p-5n; Sat, 17 Dec 2005 15:43:05 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBHFggQv026623; Sat, 17 Dec 2005 10:42:42 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBHFggUN105320; Sat, 17 Dec 2005 10:42:42 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBHFggtG030184; Sat, 17 Dec 2005 10:42:42 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBHFggoQ030181; Sat, 17 Dec 2005 10:42:42 -0500 In-Reply-To: <43A3F936.6040309@gmx.de> To: Julian Reschke <julian.reschke@gmx.de> Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> Message-ID: <OFC71F26D6.D01A0850-ON852570DA.005646C2-852570DA.00565086@us.ibm.com> Date: Sat, 17 Dec 2005 10:42:52 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/17/2005 10:42:41, Serialize complete at 12/17/2005 10:42:41 Content-Type: multipart/alternative; boundary="=_alternative 00564F89852570DA_=" Received-SPF: pass (aji.w3.mag.keio.ac.jp: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EneCr-00072p-5n bb89369391d4431c20287229bf77b4d8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/OFC71F26D6.D01A0850-ON852570DA.005646C2-852570DA.00565086@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11185 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EneDO-0001hj-HR@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 15:43:18 +0000 This is a multipart message in MIME format. --=_alternative 00564F89852570DA_= Content-Type: text/plain; charset="US-ASCII" Sounds good to me. Cheers, Geoff Julian wrote on 12/17/2005 06:40:38 AM: > > Hi. > > With the inclusion of the proposed text below in RFC2518bius, we'd be > closing an issue that was raised in spring while discussing BIND. In the > subsequent discussion (summarized in > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs- > properties-latest.html>) > we found that it's not a problem specific to BIND at all, because it > applies to any operation that creates new resources or moves them. > > Since then BIND has passed (a third!) working group last call, with no > new issues raised. So here's my current understanding of where we stand > with BIND. Feedback appreciated. > > 1) BIND is finished, however it's currently on hold because we're busy > with RFC2518bis. > > 2) Should the working group manage to complete RFC2518bis as planned, we > can slightly revise the current BIND draft, taking out stuff that's not > needed anymore, namely > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > html#rfc.section.1.3> > ("preconditions and postconditions"), parts of > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > html#rfc.section.2.4> > (discussion of broken DELETE semantics of RFC2518bis), and parts of > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > html#rfc.section.8.2> > (introduction of "DAV" request header). As these changes would be purely > editorial, I'll assume we wouldn't want to do another WGLC. > > 3) On the other hand, should the working group fail to finish > RFC2518bis, we'll submit BIND as is. > > > Best regards, Julian > > > > > > > bugzilla@soe.ucsc.edu wrote: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-12-17 03:25 ------- > > OK, I believe I have completed my changes. As usual, see them in context at > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis- > latest.html#rfc.issue.bz085> > > > > > > In Section 8, NEW: > > > > 8.1.6 Impacts of Namespace Operations on Cacheability > > > > Note that the HTTP response headers "Etag" and "Last-Modified" (see > > [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per > > resource), and are used by clients for caching. Therefore servers > > must ensure that executing any operation that affects the URL > > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve > > their semantics, in particular: > > > > o For any given URL, the "Last-Modified" value must increment every > > time the representation returned upon GET changes (within the > > limits of timestamp resolution). > > > > o For any given URL, no "ETag" value must ever be re-used for > > different representations returned by GET. > > > > In practice this means that servers > > > > o may have to increment "Last-Modified" timestamps for every > > resource inside the destination namespace of a namespace > > operation, and > > > > o similarily, may have to re-assign "ETag" values for these > > resources (unless the server allocates entity tags in a way so > > that they are unique across the whole URL namespace managed by the > > server). > > > > Note that these considerations also apply to specific use cases, such > > as using PUT creating a new resource at a URL that has been mapped > > before, but has been deleted since then. > > > > Finally, WebDAV properties (such as DAV:getetag and DAV: > > getlastmodified) that inherit their semantics from HTTP headers must > > behave accordingly. > > > > In the description for DAV:getetag: > > > > OLD: > > > > COPY/MOVE behaviour: This property value is dependent on the final > > state of the destination resource, not the value of the property > > on the source resource. > > > > NEW: > > > > COPY/MOVE behaviour: This property value is dependent on the final > > state of the destination resource, not the value of the property > > on the source resource. Also note the cacheability considerations > > in Section 8.1.6. > > > > In the description for DAV:getlastmodified: > > > > Section 14., para. 56: > > OLD: > > > > COPY/MOVE behaviour: This property value is dependent on the last > > modified date of the destination resource, not the value of the > > property on the source resource. Note that some server > > implementations use the file system date modified value for the > > DAV:getlastmodified value, and this is preserved in a MOVE even > > when the HTTP Last-Modified value SHOULD change. Thus, clients > > cannot rely on this value for caching and SHOULD use ETags. > > > > NEW: > > > > COPY/MOVE behaviour: This property value is dependent on the last > > modified date of the destination resource, not the value of the > > property on the source resource. Also note the cacheability > > considerations in Section 8.1.6. > > > > Note that tis particular change removes language that contradicts > RFC2616 (we > > can't simply tell people that RFC2616 doesn't count anymore, at least not > > without strong WG consensus). > --=_alternative 00564F89852570DA_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>Sounds good to me.</tt></font> <br> <br><font size=2><tt>Cheers,</tt></font> <br><font size=2><tt>Geoff</tt></font> <br> <br><font size=2><tt>Julian wrote on 12/17/2005 06:40:38 AM:<br> <br> > <br> > Hi.<br> > <br> > With the inclusion of the proposed text below in RFC2518bius, we'd be <br> > closing an issue that was raised in spring while discussing BIND. In the <br> > subsequent discussion (summarized in <br> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-<br> > properties-latest.html>) <br> > we found that it's not a problem specific to BIND at all, because it <br> > applies to any operation that creates new resources or moves them.<br> > <br> > Since then BIND has passed (a third!) working group last call, with no <br> > new issues raised. So here's my current understanding of where we stand <br> > with BIND. Feedback appreciated.<br> > <br> > 1) BIND is finished, however it's currently on hold because we're busy <br> > with RFC2518bis.<br> > <br> > 2) Should the working group manage to complete RFC2518bis as planned, we <br> > can slightly revise the current BIND draft, taking out stuff that's not <br> > needed anymore, namely <br> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.<br> > html#rfc.section.1.3> <br> > ("preconditions and postconditions"), parts of <br> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.<br> > html#rfc.section.2.4> <br> > (discussion of broken DELETE semantics of RFC2518bis), and parts of <br> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.<br> > html#rfc.section.8.2> <br> > (introduction of "DAV" request header). As these changes would be purely <br> > editorial, I'll assume we wouldn't want to do another WGLC.<br> > <br> > 3) On the other hand, should the working group fail to finish <br> > RFC2518bis, we'll submit BIND as is.<br> > <br> > <br> > Best regards, Julian<br> > <br> > <br> > <br> > <br> > <br> > <br> > bugzilla@soe.ucsc.edu wrote:<br> > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85<br> > > <br> > > <br> > > <br> > > <br> > > <br> > > ------- Additional Comments From julian.reschke@greenbytes.de  <br> > 2005-12-17 03:25 -------<br> > > OK, I believe I have completed my changes. As usual, see them in context at<br> > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-<br> > latest.html#rfc.issue.bz085><br> > > <br> > > <br> > > In Section 8, NEW:<br> > > <br> > >  8.1.6  Impacts of Namespace Operations on Cacheability<br> > >  <br> > >     Note that the HTTP response headers "Etag" and "Last-Modified" (see<br> > >     [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per<br> > >     resource), and are used by clients for caching.  Therefore servers<br> > >     must ensure that executing any operation that affects the URL<br> > >     namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve<br> > >     their semantics, in particular:<br> > >  <br> > >     o  For any given URL, the "Last-Modified" value must increment every<br> > >        time the representation returned upon GET changes (within the<br> > >        limits of timestamp resolution).<br> > >  <br> > >     o  For any given URL, no "ETag" value must ever be re-used for<br> > >        different representations returned by GET.<br> > >  <br> > >     In practice this means that servers<br> > >  <br> > >     o  may have to increment "Last-Modified" timestamps for every<br> > >        resource inside the destination namespace of a namespace<br> > >        operation, and<br> > >  <br> > >     o  similarily, may have to re-assign "ETag" values for these<br> > >        resources (unless the server allocates entity tags in a way so<br> > >        that they are unique across the whole URL namespace managed by the<br> > >        server).<br> > >  <br> > >     Note that these considerations also apply to specific use cases, such<br> > >     as using PUT creating a new resource at a URL that has been mapped<br> > >     before, but has been deleted since then.<br> > >  <br> > >     Finally, WebDAV properties (such as DAV:getetag and DAV:<br> > >     getlastmodified) that inherit their semantics from HTTP headers must<br> > >     behave accordingly.<br> > > <br> > > In the description for DAV:getetag:<br> > > <br> > > OLD:<br> > > <br> > >     COPY/MOVE behaviour:  This property value is dependent on the final<br> > >        state of the destination resource, not the value of the property<br> > >        on the source resource.<br> > > <br> > > NEW:<br> > > <br> > >     COPY/MOVE behaviour:  This property value is dependent on the final<br> > >        state of the destination resource, not the value of the property<br> > >        on the source resource.  Also note the cacheability considerations<br> > >        in Section 8.1.6.<br> > > <br> > > In the description for DAV:getlastmodified:<br> > > <br> > > Section 14., para. 56:<br> > > OLD:<br> > > <br> > >     COPY/MOVE behaviour:  This property value is dependent on the last<br> > >        modified date of the destination resource, not the value of the<br> > >        property on the source resource.  Note that some server<br> > >        implementations use the file system date modified value for the<br> > >        DAV:getlastmodified value, and this is preserved in a MOVE even<br> > >        when the HTTP Last-Modified value SHOULD change.  Thus, clients<br> > >        cannot rely on this value for caching and SHOULD use ETags.<br> > > <br> > > NEW:<br> > > <br> > >     COPY/MOVE behaviour:  This property value is dependent on the last<br> > >        modified date of the destination resource, not the value of the<br> > >        property on the source resource.  Also note the cacheability<br> > >        considerations in Section 8.1.6.<br> > > <br> > > Note that tis particular change removes language that contradicts <br> > RFC2616 (we<br> > > can't simply tell people that RFC2616 doesn't count anymore, at least not<br> > > without strong WG consensus).<br> > <br> </tt></font> --=_alternative 00564F89852570DA_=-- From w3c-dist-auth-request@frink.w3.org Sat Dec 17 14:03:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnhLD-0007r9-UK for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 14:03:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29263 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 14:02:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnhJw-0002gD-Id for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 19:02:16 +0000 Received: from aji.w3.org ([133.27.228.225] helo=aji.w3.mag.keio.ac.jp) by frink.w3.org with esmtp (Exim 4.50) id 1EnhJl-0002eC-CP for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 19:02:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.mag.keio.ac.jp with esmtp (Exim 4.50) id 1EnhJf-0002Py-QU for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 19:02:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHJ1wMG029559; Sat, 17 Dec 2005 11:01:58 -0800 Date: Sat, 17 Dec 2005 11:01:58 -0800 Message-Id: <200512171901.jBHJ1wMG029559@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.mag.keio.ac.jp: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.mag.keio.ac.jp 1EnhJf-0002Py-QU 3d86f2899b8ebaef5e19477ab417bcde X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512171901.jBHJ1wMG029559@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11186 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnhJw-0002gD-Id@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 19:02:16 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 11:01 ------- Created an attachment (id=2) --> (http://ietf.cse.ucsc.edu:8080/bugzilla/attachment.cgi?id=2&action=view) test case ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 14:05:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnhMt-00085S-B8 for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 14:05:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29350 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 14:04:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnhMK-0002y9-83 for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 19:04:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnhMH-0002xb-PG for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 19:04:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnhMF-0000Q7-CH for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 19:04:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHJ4clp029573; Sat, 17 Dec 2005 11:04:38 -0800 Date: Sat, 17 Dec 2005 11:04:38 -0800 Message-Id: <200512171904.jBHJ4clp029573@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnhMF-0000Q7-CH f9de1d6c46f7b5e9b0b7f459ea231ba9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512171904.jBHJ4clp029573@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11187 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnhMK-0002y9-83@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 19:04:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 11:04 ------- I have tested with Apache, Xythos, IIS and SAP KM. Results vary widely, between If -Match always ignored (COPY executed independent If-Match), If-Match always rejected (even when correct), and seemingly correct behaviour. We clearly need to discuss this and cope with the fact that we currently don't have interoperability for this. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 14:06:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnhNf-0008AW-7l for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 14:06:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29442 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 14:05:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnhN7-0003QA-Gy for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 19:05:33 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EnhN5-0003PX-6P for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 19:05:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EnhN1-0004Xs-Pc for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 19:05:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHJ5PPC029589; Sat, 17 Dec 2005 11:05:25 -0800 Date: Sat, 17 Dec 2005 11:05:25 -0800 Message-Id: <200512171905.jBHJ5PPC029589@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EnhN1-0004Xs-Pc 7fd2fae59cd0c6028ff418c0852f9690 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512171905.jBHJ5PPC029589@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11188 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnhN7-0003QA-Gy@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 19:05:33 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-07 |-09 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 15:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EniPP-0006Vn-AX for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 15:11:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05779 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 15:10:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EniOM-0000IY-SH for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 20:10:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EniOG-0000GZ-GW for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 20:10:48 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EniOB-0007in-G7 for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 20:10:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHKAgPf029639; Sat, 17 Dec 2005 12:10:42 -0800 Date: Sat, 17 Dec 2005 12:10:42 -0800 Message-Id: <200512172010.jBHKAgPf029639@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EniOB-0007in-G7 81264d48e02b7d797229495748c03e7d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 208] New: spec contradictory in ETag requirements X-Archived-At: http://www.w3.org/mid/200512172010.jBHKAgPf029639@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11189 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EniOM-0000IY-SH@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 20:10:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=208 Summary: spec contradictory in ETag requirements Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.8.1.4 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org >From Section 8.1.4 (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.8.1.4>): "If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the DAV:getetag property." DAV:getetag explicitly says that Accept headers are not taken into account, so this must either be relaxed or clarified. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 15:13:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EniQk-0006nE-OD for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 15:13:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05904 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 15:12:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EniQA-0000dx-DY for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 20:12:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EniQ8-0000c4-42 for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 20:12:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EniQ4-00025m-Gd for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 20:12:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHKCbcI029658; Sat, 17 Dec 2005 12:12:37 -0800 Date: Sat, 17 Dec 2005 12:12:37 -0800 Message-Id: <200512172012.jBHKCbcI029658@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EniQ4-00025m-Gd 7683ccdeb08fe3c596aaddd440579dbc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 209] New: invalid etag in example X-Archived-At: http://www.w3.org/mid/200512172012.jBHKCbcI029658@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11190 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EniQA-0000dx-DY@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 20:12:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=209 Summary: invalid etag in example Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.8.2.6 OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org >From 8.2.6 (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.8.2.6>): <D:getetag>zzyzx</D:getetag> ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 17 15:16:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EniUF-0007ea-5O for webdav-archive@megatron.ietf.org; Sat, 17 Dec 2005 15:16:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06319 for <webdav-archive@lists.ietf.org>; Sat, 17 Dec 2005 15:15:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EniTd-0002UC-8p for w3c-dist-auth-dist@listhub.w3.org; Sat, 17 Dec 2005 20:16:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EniTa-0002Tc-Qt for w3c-dist-auth@listhub.w3.org; Sat, 17 Dec 2005 20:16:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EniTU-0003Br-Cv for w3c-dist-auth@w3.org; Sat, 17 Dec 2005 20:16:17 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBHKG4HF029680; Sat, 17 Dec 2005 12:16:04 -0800 Date: Sat, 17 Dec 2005 12:16:04 -0800 Message-Id: <200512172016.jBHKG4HF029680@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EniTU-0003Br-Cv b8e7c69d2dd9b71b3949adde80721867 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200512172016.jBHKG4HF029680@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11191 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EniTd-0002UC-8p@frink.w3.org> Resent-Date: Sat, 17 Dec 2005 20:16:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-17 12:16 ------- Still in draft 09 (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.14.6>) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 08:52:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnyxF-0007o3-Jc for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 08:52:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12527 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 08:51:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnyvS-0005Cy-Aa for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 13:50:10 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EnyvH-0004qw-1J for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 13:49:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Enyv7-0001J2-3g for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 13:49:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIDnkST008625; Sun, 18 Dec 2005 05:49:46 -0800 Date: Sun, 18 Dec 2005 05:49:46 -0800 Message-Id: <200512181349.jBIDnkST008625@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Enyv7-0001J2-3g ca084f4bb86a0a359ae48628076a9392 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512181349.jBIDnkST008625@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11192 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnyvS-0005Cy-Aa@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 13:50:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-18 05:49 ------- I feel it would be better if the spec would adopt the definitions from <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.4>, in particular: - to avoid confusion (the draft currently seems to say "protected" when RFC3253 would say "computed"), - to enable subsequent specification not to have choose with one particular variant of the terminology. Thus I'll make a proposal for text change, including the RFC3253 definitions and adapting the live property definitions where necessary. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 09:13:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnzIG-0003Aa-Cb for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 09:13:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14252 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 09:12:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EnzHU-0000Ww-DP for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 14:12:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EnzHR-0000WM-Pv for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 14:12:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EnzHP-00071L-0Y for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 14:12:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIECmgX008676; Sun, 18 Dec 2005 06:12:48 -0800 Date: Sun, 18 Dec 2005 06:12:48 -0800 Message-Id: <200512181412.jBIECmgX008676@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EnzHP-00071L-0Y 3b52dc2a012c8126128e6679553d58d6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 210] New: incorrect statement on PROPPATCH and property recurrence X-Archived-At: http://www.w3.org/mid/200512181412.jBIECmgX008676@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11193 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EnzHU-0000Ww-DP@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 14:12:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=210 Summary: incorrect statement on PROPPATCH and property recurrence Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.14 OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 14. DAV Properties AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org See <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.14>: "Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses or PROPPATCH requests." As far as PROPPATCH is concerned, this is incorrect (PROPPATCH is defined to execute "set" and "remove" statements in document order, so whatver was the last occurence of a given property name will define the result). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 10:25:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo0Pw-0008Mk-Ir for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 10:25:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21605 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 10:24:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo0Od-0005cq-Qi for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 15:24:23 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo0OV-0005an-UX for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 15:24:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eo0OO-0000gG-RS for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 15:24:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIFO54l008716; Sun, 18 Dec 2005 07:24:05 -0800 Date: Sun, 18 Dec 2005 07:24:05 -0800 Message-Id: <200512181524.jBIFO54l008716@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo0OO-0000gG-RS 594120984dad127aaee71e5f2c602c4f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512181524.jBIFO54l008716@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11194 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo0Od-0005cq-Qi@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 15:24:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-18 07:24 ------- Here's the proposed change (see also <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz050>): Section 14., para. 2: OLD: Some property values are calculated by the server and it is not appropriate to allow client changes, thus they are protected. Existing server implementations already have different sets of RFC2518 properties protected, but clients can have some expectations which properties are normally protected. The value of a protected property may not be changed even by a user with permission to edit other properties. The value of an unprotected property may be changed by some users with appropriate permissions. NEW: When a property of a specific kind of resource is "protected", the property value cannot be updated on that kind of resource except by a method explicitly defined as updating that specific property. In particular, a protected property cannot be updated with a PROPPATCH request. Note that a given property can be protected on one kind of resource, but not protected on another kind of resource. When a property is "computed", its value is defined in terms of a computation based on the content and other properties of that resource, or even of some other resource. A computed property is always a protected property. Section 14., para. 17: OLD: Protected: SHOULD NOT be protected NEW: Protected: SHOULD NOT be protected. Section 14., para. 24: OLD: Value: language-tag (language-tag is defined in section 14.13 of [RFC2616]) Protected: SHOULD NOT be protected, so that clients can reset the language. NEW: Value: language-tag (language-tag is defined in section 14.13 of [RFC2616]) Protected: SHOULD NOT be protected, so that clients can reset the language. Section 14., para. 32: OLD: Protected: SHOULD be protected so clients cannot set to misleading values NEW: Protected: This property is computed, thus protected. Section 14., para. 39: OLD: Protected: SHOULD NOT be protected, so clients may fix this value NEW: Protected: SHOULD NOT be protected, so clients may fix this value. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 10:30:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo0UQ-0000hs-Da for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 10:30:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21926 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 10:29:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo0Tq-0006Gr-Nx for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 15:29:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo0To-0006GF-A5 for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 15:29:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo0TY-00079y-Th for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 15:29:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIFTPA8008750; Sun, 18 Dec 2005 07:29:25 -0800 Date: Sun, 18 Dec 2005 07:29:25 -0800 Message-Id: <200512181529.jBIFTPA8008750@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eo0TY-00079y-Th fb732b1fa514b1ef4baa49da0a1b984a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512181529.jBIFTPA8008750@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo0Tq-0006Gr-Nx@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 15:29:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-09 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 13:58:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo3jU-0004eP-0Q for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 13:58:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11191 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 13:57:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo3hv-0005iz-NW for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 18:56:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo3hl-0005iP-8e for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 18:56:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo3hi-0002SE-1o for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 18:56:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIIuCS8008861; Sun, 18 Dec 2005 10:56:12 -0800 Date: Sun, 18 Dec 2005 10:56:12 -0800 Message-Id: <200512181856.jBIIuCS8008861@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eo3hi-0002SE-1o 29730dff6e38c53dc26f7eb7156c694d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512181856.jBIIuCS8008861@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11196 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo3hv-0005iz-NW@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 18:56:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-18 10:56 ------- Note that there's also some overlap with section 8.5.1, with partly conflicting requirements. My suggestion here is to put normative text about the mechanism into 8.5.1, and let section 15 only contain the individual condition code definitions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 14:19:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo44U-0008OP-T3 for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 14:19:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12928 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 14:18:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo43l-0002uf-Ow for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 19:19:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo43j-0002u7-J7 for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 19:19:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo43g-0007eS-3P for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 19:19:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIJIw26008901; Sun, 18 Dec 2005 11:18:58 -0800 Date: Sun, 18 Dec 2005 11:18:58 -0800 Message-Id: <200512181918.jBIJIw26008901@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eo43g-0007eS-3P aa26c6e4cd0e571fd6423b30bd37757b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512181918.jBIJIw26008901@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11197 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo43l-0002uf-Ow@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 19:19:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-18 11:18 ------- Looks good. Minor wording fix: replace "creating" with "to create" OLD: Note that these considerations also apply to specific use cases, such as using PUT creating a new resource at a URL that has been mapped before, but has been deleted since then. NEW: Note that these considerations also apply to specific use cases, such as using PUT to create a new resource at a URL that has been mapped before, but has been deleted since then. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 14:33:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo4Hl-00021e-6v for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 14:33:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13875 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 14:32:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo4H0-0006dP-1d for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 19:32:46 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo4Gx-0006cX-9i for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 19:32:43 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1Eo4GS-00035w-6W for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 19:32:42 +0000 Received: (qmail invoked by alias); 18 Dec 2005 19:32:07 -0000 Received: from p508F8112.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.18] by mail.gmx.net (mp009) with SMTP; 18 Dec 2005 20:32:07 +0100 X-Authenticated: #1915285 Message-ID: <43A5B8CB.5080006@gmx.de> Date: Sun, 18 Dec 2005 20:30:19 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512181918.jBIJIw26008901@ietf.cse.ucsc.edu> In-Reply-To: <200512181918.jBIJIw26008901@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo4GS-00035w-6W 69e9ee81f9ddbdfc50fc1636a2ba6c05 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/43A5B8CB.5080006@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11198 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo4H0-0006dP-1d@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 19:32:46 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > ... > ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-18 11:18 ------- > Looks good. Minor wording fix: replace "creating" with "to create" > > OLD: > Note that these considerations also apply to specific use cases, such > as using PUT creating a new resource at a URL that has been mapped > before, but has been deleted since then. > > NEW: > Note that these considerations also apply to specific use cases, such > as using PUT to create a new resource at a URL that has been mapped > before, but has been deleted since then. > ... Thanks, done. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Dec 18 17:55:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7RJ-0005Iv-P1 for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 17:55:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03196 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 17:54:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7Q4-0003y9-Tj for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 22:54:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7Pt-0003xM-Mu for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 22:54:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo7Pq-0001Lr-6U for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 22:54:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIMs0qC009043; Sun, 18 Dec 2005 14:54:00 -0800 Date: Sun, 18 Dec 2005 14:54:00 -0800 Message-Id: <200512182254.jBIMs0qC009043@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eo7Pq-0001Lr-6U a86c0160720db3b68e86b0466f78dd4a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 30] incorrect XML in example X-Archived-At: http://www.w3.org/mid/200512182254.jBIMs0qC009043@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11199 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7Q4-0003y9-Tj@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 22:54:20 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=30 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 17:56:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7Rx-0005SP-I5 for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 17:56:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03253 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 17:55:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7RN-0004Vq-B2 for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 22:55:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7RK-0004Tk-LG for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 22:55:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo7RE-0001aP-LP for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 22:55:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIMtUlt009063; Sun, 18 Dec 2005 14:55:30 -0800 Date: Sun, 18 Dec 2005 14:55:30 -0800 Message-Id: <200512182255.jBIMtUlt009063@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eo7RE-0001aP-LP 449f44f3c548e32f4dd5d479f36c5679 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 57] incorrect section reference X-Archived-At: http://www.w3.org/mid/200512182255.jBIMtUlt009063@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11200 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7RN-0004Vq-B2@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 22:55:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=57 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 17:57:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7T8-0005oA-Py for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 17:57:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03386 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 17:56:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7SX-0005KL-Ke for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 22:56:53 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7SV-0005Jn-9w for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 22:56:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo7SS-00028t-02 for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 22:56:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIMuegF009084; Sun, 18 Dec 2005 14:56:40 -0800 Date: Sun, 18 Dec 2005 14:56:40 -0800 Message-Id: <200512182256.jBIMuegF009084@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eo7SS-00028t-02 fd43ef572fdc73bc3f471675c3e58a2e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 63] typo in 13.16 "name" line X-Archived-At: http://www.w3.org/mid/200512182256.jBIMuegF009084@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11201 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7SX-0005KL-Ke@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 22:56:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=63 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 17:59:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7V0-0006Ee-FC for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 17:59:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03576 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 17:58:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7UN-0005dU-6s for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 22:58:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7UJ-0005cp-Cy for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 22:58:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo7UG-00035H-JU for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 22:58:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIMwU90009102; Sun, 18 Dec 2005 14:58:30 -0800 Date: Sun, 18 Dec 2005 14:58:30 -0800 Message-Id: <200512182258.jBIMwU90009102@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eo7UG-00035H-JU 4220b1f106a9246ff90d679634711729 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 68] Reference to XML spec X-Archived-At: http://www.w3.org/mid/200512182258.jBIMwU90009102@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11202 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7UN-0005dU-6s@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 22:58:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=68 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:00:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7Vq-0006S9-6q for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:00:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03776 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 17:59:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7VD-0005lW-Hz for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 22:59:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7V8-0005kN-Qz for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 22:59:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo7V6-0003V8-3e for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 22:59:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIMxSSZ009121; Sun, 18 Dec 2005 14:59:28 -0800 Date: Sun, 18 Dec 2005 14:59:28 -0800 Message-Id: <200512182259.jBIMxSSZ009121@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eo7V6-0003V8-3e e9991e813820eecb8c162e3a4529c4dc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 88] typo in list X-Archived-At: http://www.w3.org/mid/200512182259.jBIMxSSZ009121@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11203 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7VD-0005lW-Hz@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 22:59:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:02:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7Xq-0006j8-Ku for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:02:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04025 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 18:01:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7XD-0007SV-Qi for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 23:01:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7X2-0007RK-V8 for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:01:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo7X0-0004BH-R1 for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 23:01:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIN1U6F009157; Sun, 18 Dec 2005 15:01:30 -0800 Date: Sun, 18 Dec 2005 15:01:30 -0800 Message-Id: <200512182301.jBIN1U6F009157@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eo7X0-0004BH-R1 b580c1294248f45313021a4b8702f3a9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 168] Revert to original reference style X-Archived-At: http://www.w3.org/mid/200512182301.jBIN1U6F009157@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11204 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7XD-0007SV-Qi@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 23:01:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=168 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:05:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7aZ-0007SH-96 for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:05:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04224 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 18:04:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7Zw-0007hB-MD for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 23:04:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7Zs-0007gd-Ph for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:04:28 +0000 Received: from aji.w3.org ([133.27.228.225]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo7Zr-0005K8-0F for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:04:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eo7Zh-0004rm-P7 for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 23:04:22 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIN4Dsj009178; Sun, 18 Dec 2005 15:04:13 -0800 Date: Sun, 18 Dec 2005 15:04:13 -0800 Message-Id: <200512182304.jBIN4Dsj009178@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo7Zh-0004rm-P7 c05004cce85c2a14dde6a9b5a08e793f Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 180] Typo in 13.18, enhance reference X-Archived-At: http://www.w3.org/mid/200512182304.jBIN4Dsj009178@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11205 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7Zw-0007hB-MD@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 23:04:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=180 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:05:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7bI-0007bH-9p for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:05:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04404 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 18:04:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7af-00088E-MX for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 23:05:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7ac-00087a-OW for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:05:14 +0000 Received: from aji.w3.org ([133.27.228.225]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo7ac-0005kM-1q for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:05:14 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eo7aU-0005C3-Ih for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 23:05:09 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIN55Qw009198; Sun, 18 Dec 2005 15:05:05 -0800 Date: Sun, 18 Dec 2005 15:05:05 -0800 Message-Id: <200512182305.jBIN55Qw009198@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo7aU-0005C3-Ih dc8d6bd26b00c9a792d75453864d48c0 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 182] whitespace in lock token in example X-Archived-At: http://www.w3.org/mid/200512182305.jBIN55Qw009198@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11206 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7af-00088E-MX@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 23:05:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=182 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:09:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7eO-00087k-FR for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:09:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04647 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 18:08:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7do-0008Qm-HO for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 23:08:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7dm-0008QC-3r for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:08:30 +0000 Received: from aji.w3.org ([133.27.228.225]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eo7dl-0006wq-Al for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:08:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eo7dh-0006Pp-A7 for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 23:08:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIN8Omp009220; Sun, 18 Dec 2005 15:08:24 -0800 Date: Sun, 18 Dec 2005 15:08:24 -0800 Message-Id: <200512182308.jBIN8Omp009220@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo7dh-0006Pp-A7 ca203d13830cb28ad79cf2730391d7b8 Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 185] Missing interpunction in "previous authors" subsection X-Archived-At: http://www.w3.org/mid/200512182308.jBIN8Omp009220@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11207 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7do-0008Qm-HO@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 23:08:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=185 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-18 15:08 ------- looks good ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sun Dec 18 18:10:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo7fP-0008Qm-D6 for webdav-archive@megatron.ietf.org; Sun, 18 Dec 2005 18:10:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04703 for <webdav-archive@lists.ietf.org>; Sun, 18 Dec 2005 18:09:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eo7eq-000075-Pj for w3c-dist-auth-dist@listhub.w3.org; Sun, 18 Dec 2005 23:09:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eo7eo-00006Q-KO for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:09:34 +0000 Received: from aji.w3.org ([133.27.228.225]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eo7eo-0007O0-2A for w3c-dist-auth@listhub.w3.org; Sun, 18 Dec 2005 23:09:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eo7ei-0006pv-SW for w3c-dist-auth@w3.org; Sun, 18 Dec 2005 23:09:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBIN9Sv1009240; Sun, 18 Dec 2005 15:09:28 -0800 Date: Sun, 18 Dec 2005 15:09:28 -0800 Message-Id: <200512182309.jBIN9Sv1009240@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eo7ei-0006pv-SW a475913559e1a015542cd0e0c6b1a466 Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 187] Changes section organization X-Archived-At: http://www.w3.org/mid/200512182309.jBIN9Sv1009240@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eo7eq-000075-Pj@frink.w3.org> Resent-Date: Sun, 18 Dec 2005 23:09:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=187 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 12:32:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoOsO-00087a-Jy for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 12:32:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16383 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 12:31:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoOpr-0005YT-Ku for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 17:30:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoOpc-00057b-Pv; Mon, 19 Dec 2005 17:29:53 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EoOpT-0002UX-0q; Mon, 19 Dec 2005 17:29:52 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBJHSw5f005807 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Dec 2005 09:28:59 -0800 (PST) In-Reply-To: <OFC71F26D6.D01A0850-ON852570DA.005646C2-852570DA.00565086@us.ibm.com> References: <OFC71F26D6.D01A0850-ON852570DA.005646C2-852570DA.00565086@us.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1--60168450 Message-Id: <A1A8EE58-3E69-4664-928C-DE66E608A39F@cs.ucsc.edu> Cc: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org From: Jim Whitehead <ejw@soe.ucsc.edu> Date: Mon, 19 Dec 2005 09:28:57 -0800 To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1EoOpT-0002UX-0q 39b1466f0f1000e01316812af1421318 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/A1A8EE58-3E69-4664-928C-DE66E608A39F@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11209 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoOpr-0005YT-Ku@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 17:30:07 +0000 --Apple-Mail-1--60168450 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I agree with this as well. - Jim On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote: > > Sounds good to me. > > Cheers, > Geoff > > Julian wrote on 12/17/2005 06:40:38 AM: > > > > > Hi. > > > > With the inclusion of the proposed text below in RFC2518bius, > we'd be > > closing an issue that was raised in spring while discussing BIND. > In the > > subsequent discussion (summarized in > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs- > > properties-latest.html>) > > we found that it's not a problem specific to BIND at all, because it > > applies to any operation that creates new resources or moves them. > > > > Since then BIND has passed (a third!) working group last call, > with no > > new issues raised. So here's my current understanding of where we > stand > > with BIND. Feedback appreciated. > > > > 1) BIND is finished, however it's currently on hold because we're > busy > > with RFC2518bis. > > > > 2) Should the working group manage to complete RFC2518bis as > planned, we > > can slightly revise the current BIND draft, taking out stuff > that's not > > needed anymore, namely > > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > > html#rfc.section.1.3> > > ("preconditions and postconditions"), parts of > > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > > html#rfc.section.2.4> > > (discussion of broken DELETE semantics of RFC2518bis), and parts of > > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. > > html#rfc.section.8.2> > > (introduction of "DAV" request header). As these changes would be > purely > > editorial, I'll assume we wouldn't want to do another WGLC. > > > > 3) On the other hand, should the working group fail to finish > > RFC2518bis, we'll submit BIND as is. > > > > > > Best regards, Julian > > > > > > > > > > > > > > bugzilla@soe.ucsc.edu wrote: > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 > > > > > > > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > 2005-12-17 03:25 ------- > > > OK, I believe I have completed my changes. As usual, see them > in context at > > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis- > > latest.html#rfc.issue.bz085> > > > > > > > > > In Section 8, NEW: > > > > > > 8.1.6 Impacts of Namespace Operations on Cacheability > > > > > > Note that the HTTP response headers "Etag" and "Last- > Modified" (see > > > [RFC2616], Sections 14.19 and 14.29) are defined per URL > (not per > > > resource), and are used by clients for caching. Therefore > servers > > > must ensure that executing any operation that affects the URL > > > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does > preserve > > > their semantics, in particular: > > > > > > o For any given URL, the "Last-Modified" value must > increment every > > > time the representation returned upon GET changes > (within the > > > limits of timestamp resolution). > > > > > > o For any given URL, no "ETag" value must ever be re-used for > > > different representations returned by GET. > > > > > > In practice this means that servers > > > > > > o may have to increment "Last-Modified" timestamps for every > > > resource inside the destination namespace of a namespace > > > operation, and > > > > > > o similarily, may have to re-assign "ETag" values for these > > > resources (unless the server allocates entity tags in a > way so > > > that they are unique across the whole URL namespace > managed by the > > > server). > > > > > > Note that these considerations also apply to specific use > cases, such > > > as using PUT creating a new resource at a URL that has been > mapped > > > before, but has been deleted since then. > > > > > > Finally, WebDAV properties (such as DAV:getetag and DAV: > > > getlastmodified) that inherit their semantics from HTTP > headers must > > > behave accordingly. > > > > > > In the description for DAV:getetag: > > > > > > OLD: > > > > > > COPY/MOVE behaviour: This property value is dependent on > the final > > > state of the destination resource, not the value of the > property > > > on the source resource. > > > > > > NEW: > > > > > > COPY/MOVE behaviour: This property value is dependent on > the final > > > state of the destination resource, not the value of the > property > > > on the source resource. Also note the cacheability > considerations > > > in Section 8.1.6. > > > > > > In the description for DAV:getlastmodified: > > > > > > Section 14., para. 56: > > > OLD: > > > > > > COPY/MOVE behaviour: This property value is dependent on > the last > > > modified date of the destination resource, not the value > of the > > > property on the source resource. Note that some server > > > implementations use the file system date modified value > for the > > > DAV:getlastmodified value, and this is preserved in a > MOVE even > > > when the HTTP Last-Modified value SHOULD change. Thus, > clients > > > cannot rely on this value for caching and SHOULD use ETags. > > > > > > NEW: > > > > > > COPY/MOVE behaviour: This property value is dependent on > the last > > > modified date of the destination resource, not the value > of the > > > property on the source resource. Also note the > cacheability > > > considerations in Section 8.1.6. > > > > > > Note that tis particular change removes language that contradicts > > RFC2616 (we > > > can't simply tell people that RFC2616 doesn't count anymore, at > least not > > > without strong WG consensus). > > --Apple-Mail-1--60168450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; ">I agree with this as = well.<DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>- = Jim<BR><DIV><DIV>On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm = wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE = type=3D"cite"><BR><FONT size=3D"2"><TT>Sounds good to me.</TT></FONT> = <BR> <BR><FONT size=3D"2"><TT>Cheers,</TT></FONT> <BR><FONT = size=3D"2"><TT>Geoff</TT></FONT> <BR> <BR><FONT size=3D"2"><TT>Julian = wrote on 12/17/2005 06:40:38 AM:<BR> <BR> > <BR> > Hi.<BR> > = <BR> > With the inclusion of the proposed text below in RFC2518bius, = we'd be <BR> > closing an issue that was raised in spring while = discussing BIND. In the <BR> > subsequent discussion (summarized in = <BR> > <<A = href=3D"http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs= -">http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-</A>= <BR> > properties-latest.html>) <BR> > we found that it's not a = problem specific to BIND at all, because it <BR> > applies to any = operation that creates new resources or moves them.<BR> > <BR> > = Since then BIND has passed (a third!) working group last call, with no = <BR> > new issues raised. So here's my current understanding of where = we stand <BR> > with BIND. Feedback appreciated.<BR> > <BR> > = 1) BIND is finished, however it's currently on hold because we're busy = <BR> > with RFC2518bis.<BR> > <BR> > 2) Should the working = group manage to complete RFC2518bis as planned, we <BR> > can = slightly revise the current BIND draft, taking out stuff that's not <BR> = > needed anymore, namely <BR> > <<A = href=3D"http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12">http:/= /greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12</A>.<BR> > = html#rfc.section.1.3> <BR> > ("preconditions and postconditions"), = parts of <BR> > <<A = href=3D"http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12">http:/= /greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12</A>.<BR> > = html#rfc.section.2.4> <BR> > (discussion of broken DELETE = semantics of RFC2518bis), and parts of <BR> > <<A = href=3D"http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12">http:/= /greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12</A>.<BR> > = html#rfc.section.8.2> <BR> > (introduction of "DAV" request = header). As these changes would be purely <BR> > editorial, I'll = assume we wouldn't want to do another WGLC.<BR> > <BR> > 3) On the = other hand, should the working group fail to finish <BR> > = RFC2518bis, we'll submit BIND as is.<BR> > <BR> > <BR> > Best = regards, Julian<BR> > <BR> > <BR> > <BR> > <BR> > <BR> = > <BR> > <A = href=3D"mailto:bugzilla@soe.ucsc.edu">bugzilla@soe.ucsc.edu</A> = wrote:<BR> > > <A = href=3D"http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D85">http:= //ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D85</A><BR> > > = <BR> > > <BR> > > <BR> > > <BR> > > <BR> > = > ------- Additional Comments =46rom <A = href=3D"mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de<= /A> =A0<BR> > 2005-12-17 03:25 -------<BR> > > OK, I believe I = have completed my changes. As usual, see them in context at<BR> > = > <<A = href=3D"http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-"= >http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-</A><BR>= > latest.html#rfc.issue.bz085><BR> > > <BR> > > <BR> = > > In Section 8, NEW:<BR> > > <BR> > > =A08.1.6 = =A0Impacts of Namespace Operations on Cacheability<BR> > > =A0<BR> = > > =A0 =A0 Note that the HTTP response headers "Etag" and = "Last-Modified" (see<BR> > > =A0 =A0 [RFC2616], Sections 14.19 and = 14.29) are defined per URL (not per<BR> > > =A0 =A0 resource), and = are used by clients for caching. =A0Therefore servers<BR> > > =A0 = =A0 must ensure that executing any operation that affects the URL<BR> = > > =A0 =A0 namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) = does preserve<BR> > > =A0 =A0 their semantics, in particular:<BR> = > > =A0<BR> > > =A0 =A0 o =A0For any given URL, the = "Last-Modified" value must increment every<BR> > > =A0 =A0 =A0 = =A0time the representation returned upon GET changes (within the<BR> = > > =A0 =A0 =A0 =A0limits of timestamp resolution).<BR> > > = =A0<BR> > > =A0 =A0 o =A0For any given URL, no "ETag" value must = ever be re-used for<BR> > > =A0 =A0 =A0 =A0different = representations returned by GET.<BR> > > =A0<BR> > > =A0 =A0 = In practice this means that servers<BR> > > =A0<BR> > > =A0 = =A0 o =A0may have to increment "Last-Modified" timestamps for every<BR> = > > =A0 =A0 =A0 =A0resource inside the destination namespace of a = namespace<BR> > > =A0 =A0 =A0 =A0operation, and<BR> > > = =A0<BR> > > =A0 =A0 o =A0similarily, may have to re-assign "ETag" = values for these<BR> > > =A0 =A0 =A0 =A0resources (unless the = server allocates entity tags in a way so<BR> > > =A0 =A0 =A0 =A0that= they are unique across the whole URL namespace managed by the<BR> > = > =A0 =A0 =A0 =A0server).<BR> > > =A0<BR> > > =A0 =A0 = Note that these considerations also apply to specific use cases, = such<BR> > > =A0 =A0 as using PUT creating a new resource at a URL = that has been mapped<BR> > > =A0 =A0 before, but has been deleted = since then.<BR> > > =A0<BR> > > =A0 =A0 Finally, WebDAV = properties (such as DAV:getetag and DAV:<BR> > > =A0 =A0 = getlastmodified) that inherit their semantics from HTTP headers must<BR> = > > =A0 =A0 behave accordingly.<BR> > > <BR> > > In = the description for DAV:getetag:<BR> > > <BR> > > OLD:<BR> = > > <BR> > > =A0 =A0 COPY/MOVE behaviour: =A0This property = value is dependent on the final<BR> > > =A0 =A0 =A0 =A0state of = the destination resource, not the value of the property<BR> > > =A0 = =A0 =A0 =A0on the source resource.<BR> > > <BR> > > NEW:<BR> = > > <BR> > > =A0 =A0 COPY/MOVE behaviour: =A0This property = value is dependent on the final<BR> > > =A0 =A0 =A0 =A0state of = the destination resource, not the value of the property<BR> > > =A0 = =A0 =A0 =A0on the source resource. =A0Also note the cacheability = considerations<BR> > > =A0 =A0 =A0 =A0in Section 8.1.6.<BR> > = > <BR> > > In the description for DAV:getlastmodified:<BR> > = > <BR> > > Section 14., para. 56:<BR> > > OLD:<BR> > = > <BR> > > =A0 =A0 COPY/MOVE behaviour: =A0This property value = is dependent on the last<BR> > > =A0 =A0 =A0 =A0modified date of = the destination resource, not the value of the<BR> > > =A0 =A0 =A0 = =A0property on the source resource. =A0Note that some server<BR> > = > =A0 =A0 =A0 =A0implementations use the file system date modified = value for the<BR> > > =A0 =A0 =A0 =A0DAV:getlastmodified value, = and this is preserved in a MOVE even<BR> > > =A0 =A0 =A0 =A0when = the HTTP Last-Modified value SHOULD change. =A0Thus, clients<BR> > = > =A0 =A0 =A0 =A0cannot rely on this value for caching and SHOULD use = ETags.<BR> > > <BR> > > NEW:<BR> > > <BR> > > =A0 = =A0 COPY/MOVE behaviour: =A0This property value is dependent on the = last<BR> > > =A0 =A0 =A0 =A0modified date of the destination = resource, not the value of the<BR> > > =A0 =A0 =A0 =A0property on = the source resource. =A0Also note the cacheability<BR> > > =A0 =A0 = =A0 =A0considerations in Section 8.1.6.<BR> > > <BR> > > = Note that tis particular change removes language that contradicts <BR> = > RFC2616 (we<BR> > > can't simply tell people that RFC2616 = doesn't count anymore, at least not<BR> > > without strong WG = consensus).<BR> > <BR> = </TT></FONT></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>= --Apple-Mail-1--60168450-- From w3c-dist-auth-request@frink.w3.org Mon Dec 19 14:11:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQQB-0004RV-7P for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 14:11:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29174 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 14:10:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoQO2-0007xs-3E for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 19:09:30 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoQNq-0007wX-5R for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 19:09:18 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EoQNZ-0000RW-8Y for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 19:09:17 +0000 Received: (qmail invoked by alias); 19 Dec 2005 19:08:56 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 19 Dec 2005 20:08:56 +0100 X-Authenticated: #1915285 Message-ID: <43A704DE.5070407@gmx.de> Date: Mon, 19 Dec 2005 20:07:10 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoQNZ-0000RW-8Y f06db024b5834c5322514a8531d76cfa X-Original-To: w3c-dist-auth@w3.org Subject: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A704DE.5070407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoQO2-0007xs-3E@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 19:09:30 +0000 Content-Transfer-Encoding: 7bit Hi, below is a summary of issues related to changes to ETag handling requirements. Feedback appreciated. Best regards, Julian -- cut -- RFC25128bis has some new server requirements, and some more are currently discussed. All of them fall into the category of transforming WebDAV into a kind of distributed file system. I absolutely agree that this is one important scenario, and that many clients already assume that they can rely on these things. So it's a real-world use case, I just happen to think there are lots of others, and making WebDAV incompatible with these would be a step into the wrong direction. The individual changes that have been discussed (or dropped into the draft are): R1) Require servers to support strong entity tags, R2) Require servers to return entity tags for PUT requests, R3) Require ETags not to change when only properties or lock state change, R4) Require servers to store arbitrary binary content, R5) Require servers to store dead properties, R6) Require servers to use persist Content-Type upon PUT. (If there are more, please let me know). Let's discuss them one by one: R1) Require servers to support strong entity tags Weak ETags are adequate for cacheing (optimizing GET operations), but not authoring (they can't be used with PUT): "Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request." So I do agree that putting in a SHOULD support strong ETags makes sense, as long as we don't make existing compliant servers non-compliant. That is, we shouldn't require them to return anything upon PUT, and we also should let them upgrade weak ETags to strong ETags if that makes sense to them. R2) Require servers to return entity tags for PUT requests The idea is that a client that did a PUT immediately will know the etag for the entity, and can use that in future requests for syncing. The trouble here is that RFC2616 doesn't really define what it means to return an ETag upon PUT, see discussion thread at <http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/thread.html#13>. So, at a minimum the WebDAV WG will have to clarify what it means, and make *absolutely* sure that this clarification is added to the RFC2616 errata. Assuming we had consensus on what an ETag upon PUT means (such as "an ETag for the entity you'd get upon a subsequent GET"), I'm still not sure how this helps with syncing. Servers are allowed to rewrite content upon PUT, so a client would still need to do another GET in order to retrieve the new entity body (that is, except if we also require R4). R3) Require ETags not to change when only properties or lock state change This is just broken spec writing, sorry. The guarantee that HTTP gives us that the ETag will change if the content changes, that's it. Of course it's sub-optimal if the etag changes when the content didn't, but a server may have very good reasons to do so. So yes, if the Etag changes the client may have to resync, just to find out that nothing changed, after all. I do understand that clients ran into problems because of repeating the sequence PUT, then PROPPATCH assuming that PROPPATCH wouldn't modify the ETag. As far as I can tell, a safe way to do this seems to be PUT, the PROPPATCH and HEAD to get the current ETag (potentially with a WebDAV lock). R4) Require servers to store arbitrary binary content There are servers that don't, examples may be Atom servers, Calendaring servers, and any kind of server that uses HTTP/Webdav to expose specific types of resources with no generic store available. Even if this would not be the case, I have to point out that the spec currently mentions scenarios where servers may rewrite content without notice (see <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.section.19.8>). R5) Require servers to store dead properties RFC2518 says this is a SHOULD. Meaning, servers may not allow it, and I think this clearly reflects reality. Checking for PROPPATCH in the "Allow" header will not always work, because there may be servers which support PROPPATCH for just a limited set of properties (such as a server that only supports setting properties in a single namespace - no kidding, that one exists). R6) Require servers to use persist Content-Type upon PUT I think that's the best thing to do, but there are servers / resource types which will ignore that, and (try to) detect the type on their own. IMHO that's not optimal, but given the fact it's the preference stated in an upcoming TAG finding (<http://www.w3.org/2001/tag/doc/mime-respect-20051205>), I don't think we can make this more than a SHOULD. So what next? I strongly object to any attempt to transform WebDAV into something like NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has been designed for a wide variety of resource types, not only serving files. The good thing is that I'm almost sure that the IESG wouldn't let us do that anyway. On the other hand, I do understand that certain types of clients will not work well with servers that can't provide some of these features. Those who like to add new requirements thus should gather feedback from the client implementors, collecting information so that we really understand what these requirements are (right now it seems we're still guessing). My feeling is that this will include a) support for strong etags b) some way of discovering whether a given resource will allow storing arbitrary contents, or just some specific content type c) some way of discovering whether a given resource will allow storing arbitrary dead properties If this is what these clients need, let's extend the spec so that they can find out. But if we can't finish this within the next few weeks, then I certainly think that we should leave things as they were in RFC2518, and have a separate spec take care of this. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 14:25:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQdE-0007M3-S5 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 14:25:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00555 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 14:24:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoQbd-0003FI-Nv for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 19:23:33 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoQbX-0003Ed-RZ for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 19:23:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1EoQbS-0007EN-GB for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 19:23:26 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3805614229D; Mon, 19 Dec 2005 12:25:57 -0800 (PST) In-Reply-To: <43A704DE.5070407@gmx.de> References: <43A704DE.5070407@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4bae7dedb22dde09ea7690a2027cf53f@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault <lisa@osafoundation.org> Date: Mon, 19 Dec 2005 11:23:18 -0800 To: Julian Reschke <julian.reschke@gmx.de> X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoQbS-0007EN-GB 8e21c09a52e802de4681ec24ff5b1b66 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/4bae7dedb22dde09ea7690a2027cf53f@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11211 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoQbd-0003FI-Nv@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 19:23:33 +0000 Content-Transfer-Encoding: 7bit Most of these things came up in interoperability tests, and it seems from those experiences that most existing WebDAV clients expect servers to behave as remote file systems. It's the most common use case out there and the reason why WebDAV is now deployed on all Windows and Mac platforms. Other uses of WebDAV are emerging and sometimes these do not need all these requirements or some such requirements might even be harmful to certain cases as you point out. Thus, I'd be happy with a new compliance class that a server could use to advertise this set of capabilities. Some existing servers would be able to advertise that almost immediately. That new compliance class probably shouldn't be called 'bis' - perhaps we can come up with another word or declare this as level 3 because it's still rather core stuff. Lisa On Dec 19, 2005, at 11:07 AM, Julian Reschke wrote: > > Hi, > > below is a summary of issues related to changes to ETag handling > requirements. Feedback appreciated. > > Best regards, Julian > > -- cut -- > > > > RFC25128bis has some new server requirements, and some more are > currently discussed. All of them fall into the category of > transforming WebDAV into a kind of distributed file system. I > absolutely agree that this is one important scenario, and that many > clients already assume that they can rely on these things. So it's a > real-world use case, I just happen to think there are lots of others, > and making WebDAV incompatible with these would be a step into the > wrong direction. > > The individual changes that have been discussed (or dropped into the > draft are): > > R1) Require servers to support strong entity tags, > > R2) Require servers to return entity tags for PUT requests, > > R3) Require ETags not to change when only properties or lock state > change, > > R4) Require servers to store arbitrary binary content, > > R5) Require servers to store dead properties, > > R6) Require servers to use persist Content-Type upon PUT. > > > (If there are more, please let me know). > > > Let's discuss them one by one: > > > R1) Require servers to support strong entity tags > > Weak ETags are adequate for cacheing (optimizing GET operations), but > not authoring (they can't be used with PUT): > > "Clients MAY issue simple (non-subrange) GET requests with either weak > validators or strong validators. Clients MUST NOT use weak validators > in other forms of request." > > So I do agree that putting in a SHOULD support strong ETags makes > sense, as long as we don't make existing compliant servers > non-compliant. That is, we shouldn't require them to return anything > upon PUT, and we also should let them upgrade weak ETags to strong > ETags if that makes sense to them. > > > R2) Require servers to return entity tags for PUT requests > > The idea is that a client that did a PUT immediately will know the > etag for the entity, and can use that in future requests for syncing. > The trouble here is that RFC2616 doesn't really define what it means > to return an ETag upon PUT, see discussion thread at > <http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/ > thread.html#13>. So, at a minimum the WebDAV WG will have to clarify > what it means, and make *absolutely* sure that this clarification is > added to the RFC2616 errata. > > Assuming we had consensus on what an ETag upon PUT means (such as "an > ETag for the entity you'd get upon a subsequent GET"), I'm still not > sure how this helps with syncing. Servers are allowed to rewrite > content upon PUT, so a client would still need to do another GET in > order to retrieve the new entity body (that is, except if we also > require R4). > > > R3) Require ETags not to change when only properties or lock state > change > > This is just broken spec writing, sorry. The guarantee that HTTP gives > us that the ETag will change if the content changes, that's it. Of > course it's sub-optimal if the etag changes when the content didn't, > but a server may have very good reasons to do so. So yes, if the Etag > changes the client may have to resync, just to find out that nothing > changed, after all. > > I do understand that clients ran into problems because of repeating > the sequence > > PUT, then PROPPATCH > > assuming that PROPPATCH wouldn't modify the ETag. As far as I can > tell, a safe way to do this seems to be > > PUT, the PROPPATCH and HEAD to get the current ETag > > (potentially with a WebDAV lock). > > > > R4) Require servers to store arbitrary binary content > > There are servers that don't, examples may be Atom servers, > Calendaring servers, and any kind of server that uses HTTP/Webdav to > expose specific types of resources with no generic store available. > > Even if this would not be the case, I have to point out that the spec > currently mentions scenarios where servers may rewrite content without > notice (see > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis > -09.html#rfc.section.19.8>). > > > R5) Require servers to store dead properties > > RFC2518 says this is a SHOULD. Meaning, servers may not allow it, and > I think this clearly reflects reality. Checking for PROPPATCH in the > "Allow" header will not always work, because there may be servers > which support PROPPATCH for just a limited set of properties (such as > a server that only supports setting properties in a single namespace - > no kidding, that one exists). > > > R6) Require servers to use persist Content-Type upon PUT > > I think that's the best thing to do, but there are servers / resource > types which will ignore that, and (try to) detect the type on their > own. IMHO that's not optimal, but given the fact it's the preference > stated in an upcoming TAG finding > (<http://www.w3.org/2001/tag/doc/mime-respect-20051205>), I don't > think we can make this more than a SHOULD. > > > > So what next? > > I strongly object to any attempt to transform WebDAV into something > like NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has > been designed for a wide variety of resource types, not only serving > files. The good thing is that I'm almost sure that the IESG wouldn't > let us do that anyway. > > On the other hand, I do understand that certain types of clients will > not work well with servers that can't provide some of these features. > Those who like to add new requirements thus should gather feedback > from the client implementors, collecting information so that we really > understand what these requirements are (right now it seems we're still > guessing). My feeling is that this will include > > a) support for strong etags > b) some way of discovering whether a given resource will allow storing > arbitrary contents, or just some specific content type > c) some way of discovering whether a given resource will allow storing > arbitrary dead properties > > If this is what these clients need, let's extend the spec so that they > can find out. But if we can't finish this within the next few weeks, > then I certainly think that we should leave things as they were in > RFC2518, and have a separate spec take care of this. > > > > > > > From w3c-dist-auth-request@frink.w3.org Mon Dec 19 16:23:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSTd-0000Tk-S9 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 16:23:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14816 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 16:22:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoSRb-0008V7-V8 for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 21:21:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoSRQ-0008SC-2H for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 21:21:08 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoSRI-000073-Di for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 21:21:07 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBJLKuTR019166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Dec 2005 13:20:56 -0800 (PST) In-Reply-To: <43A704DE.5070407@gmx.de> References: <43A704DE.5070407@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> Cc: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: Jim Whitehead <ejw@soe.ucsc.edu> Date: Mon, 19 Dec 2005 13:20:55 -0800 To: Julian Reschke <julian.reschke@gmx.de> X-Mailer: Apple Mail (2.746.2) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: lisa.w3.org 1EoSRI-000073-Di 01341ad4ddc24db6e252dd4430d1de6d X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11212 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoSRb-0008V7-V8@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 21:21:19 +0000 Content-Transfer-Encoding: 7bit > Julian, Thank you for posting this issue summary. From a client perspective, what they need is a reliable Etag be returned by a successful PUT. I believe it's fine if that Etag is either weak or strong -- what is damaging for clients is when the Etag changes from weak to strong at some point after a successful PUT, since there is no reliable mechanism for the client to discover this has happened (yes, you can use polling, but there is no guarantee for how long you need to perform polling before you know you've received the final Etag). The main client use for the Etag returned by PUT is ensuring that their locally cached state is the same as that held by the server. This requirement goes across multiple client types, and is not limited just to filesystem-like clients. As a result, my views on the requirements below are as follows: R1) Require servers to support strong entity tags, Not needed -- weak Etags are as good as strong etags for most uses. R2) Require servers to return entity tags for PUT requests Required. Or, put another way, what clients need is the ability to know the final value of the etag assigned to the server's representation of the resource created by a successful PUT. It seems that the best way to do this is to have the server respond with that Etag in the PUT response. What might also work is for there to be a guarantee that this final etag will be available within a given time period, and hence clients will only need to perform a single follow- on request to get this etag. However, protocol requirements involving timing are usually very hard to get right -- it's not my first choice. That's why I think returning the etag in the PUT response is the best way to communicate this final etag value. > R3) Require ETags not to change when only properties or lock state > change > > This is just broken spec writing, sorry. The guarantee that HTTP > gives us that the ETag will change if the content changes, that's > it. Of course it's sub-optimal if the etag changes when the content > didn't, but a server may have very good reasons to do so. So yes, > if the Etag changes the client may have to resync, just to find out > that nothing changed, after all. It is quite clear from reading RFC 2616 and RFC 2518 that the use of Etags was intended to describe the entity due to a GET response. The definitions of entity and etags are below (RFC 2616, section 1.3, 3.11, 7.1). entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity- body, as described in section 7. A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality. A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison. Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified by the request. Some of this metainformation is OPTIONAL; some might be REQUIRED by portions of this specification. entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header From these definitions, it's clear that HTTP intended for only the metadata in the entity-header fields to be considered part of the entity. In particular, there are other kinds of metadata that are *not* included in the definition of an entity. It seems to me we have a few choices. * Stick closely to the HTTP notion of entity, in which case changes to the DAV:getcontentlanguage, DAV:getcontenttype, DAV:getcontentlength, and DAV:getlastmodified MUST affect the Etag, and changes to other properties MUST NOT affect the etag. * Make a clear distinction between WebDAV properties and HTTP entities, stating that changes to WebDAV properties MUST NOT cause changes to HTTP entities. * Consider WebDAV properties to be part of the state of the resource, even though they (except for the properties listed above) do not affect the entity (as defined by HTTP), and hence any change to a property MUST cause a change to the Etag. I'll note that the third option seems to be the hardest one to defend based purely on the language of the HTTP specification. Another solution is to introduce a new state token representing the dead property state. This token could be retrieved from a property, or available in a response header (perhaps for PROPFIND). This would allow WebDAV to discuss the impact of property changes on a state token without having to alter the definition of entity in HTTP. R4) Require servers to store arbitrary binary content, This seems too strong to me. I think the requirement should be for clients to discover when a server does not accept arbitrary binary content, either by an appropriate error code for PUT, or via some other discovery mechanism (a property that exists that describes acceptable MIME types and/or XML schemas?) R5) Require servers to store dead properties, Same as for R4. > R6) Require servers to use persist Content-Type upon PUT. I agree this is a SHOULD level requirement. > I strongly object to any attempt to transform WebDAV into something > like NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has > been designed for a wide variety of resource types, not only > serving files. The good thing is that I'm almost sure that the IESG > wouldn't let us do that anyway. > I believe that these issues are more broad than just filesystem-like vs non-filesystem-like, and hence framing the issue as "what those filesystem-like clients need" is not productive. - Jim From w3c-dist-auth-request@frink.w3.org Mon Dec 19 16:55:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSyH-0006my-P0 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 16:55:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18923 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 16:54:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoSwW-00020T-SE for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 21:53:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoSwB-0001vb-MN for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 21:52:55 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EoSw5-000546-9R for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 21:52:55 +0000 Received: (qmail invoked by alias); 19 Dec 2005 21:51:58 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp016) with SMTP; 19 Dec 2005 22:51:58 +0100 X-Authenticated: #1915285 Message-ID: <43A72B27.4060900@gmx.de> Date: Mon, 19 Dec 2005 22:50:31 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead <ejw@soe.ucsc.edu> CC: w3c-dist-auth@w3.org References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> In-Reply-To: <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EoSw5-000546-9R 70edfb86c203e9637be5910d56d23d27 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A72B27.4060900@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoSwW-00020T-SE@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 21:53:16 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > From a client perspective, what they need is a reliable Etag be > returned by a successful PUT. I believe it's fine if that Etag is either > weak or strong -- what is damaging for clients is when the Etag changes > from weak to strong at some point after a successful PUT, since there is > no reliable mechanism for the client to discover this has happened (yes, > you can use polling, but there is no guarantee for how long you need to > perform polling before you know you've received the final Etag). Note that weak ETags indeed can't be used with PUT (I was wrong on that in previous messages). The weak-to-strong propagation in Apache IMHO is technically sound, as the semantics is compliant to HTTP, and (non-authoring) clients get the best out of it. The question is how to change this so that authoring clients will be happy as well. Special-casing things IMHO will not work. In Apache, ETags are generated by httpd, not moddav, and thus are optimized for GET, not authoring. > The main client use for the Etag returned by PUT is ensuring that their > locally cached state is the same as that held by the server. This > requirement goes across multiple client types, and is not limited just > to filesystem-like clients. > > As a result, my views on the requirements below are as follows: > > R1) Require servers to support strong entity tags, > > Not needed -- weak Etags are as good as strong etags for most uses. > > R2) Require servers to return entity tags for PUT requests > > Required. Or, put another way, what clients need is the ability to know > the final value of the etag assigned to the server's representation of > the resource created by a successful PUT. It seems that the best way to > do this is to have the server respond with that Etag in the PUT > response. What might also work is for there to be a guarantee that this > final etag will be available within a given time period, and hence > clients will only need to perform a single follow-on request to get this > etag. However, protocol requirements involving timing are usually very > hard to get right -- it's not my first choice. That's why I think > returning the etag in the PUT response is the best way to communicate > this final etag value. Again, if we require this, we'll have to make sure everybody agrees on what this means. That, at a minimum, requires getting consensus on the HTTP mailing list, and getting that consensus into the RFC2616 errata. >> R3) Require ETags not to change when only properties or lock state change >> >> This is just broken spec writing, sorry. The guarantee that HTTP gives >> us that the ETag will change if the content changes, that's it. Of >> course it's sub-optimal if the etag changes when the content didn't, >> but a server may have very good reasons to do so. So yes, if the Etag >> changes the client may have to resync, just to find out that nothing >> changed, after all. > > It is quite clear from reading RFC 2616 and RFC 2518 that the use of > Etags was intended to describe the entity due to a GET response. The > definitions of entity and etags are below (RFC 2616, section 1.3, 3.11, > 7.1). > > entity > The information transferred as the payload of a request or > response. An entity consists of metainformation in the form of > entity-header fields and content in the form of an entity-body, as > described in section 7. > > > A "strong entity tag" MAY be shared by two entities of a resource > only if they are equivalent by octet equality. > > A "weak entity tag," indicated by the "W/" prefix, MAY be shared by > two entities of a resource only if the entities are equivalent and > could be substituted for each other with no significant change in > semantics. A weak entity tag can only be used for weak comparison. > > > Entity-header fields define metainformation about the entity-body or, > if no body is present, about the resource identified by the request. > Some of this metainformation is OPTIONAL; some might be REQUIRED by > portions of this specification. > > entity-header = Allow ; Section 14.7 > | Content-Encoding ; Section 14.11 > | Content-Language ; Section 14.12 > | Content-Length ; Section 14.13 > | Content-Location ; Section 14.14 > | Content-MD5 ; Section 14.15 > | Content-Range ; Section 14.16 > | Content-Type ; Section 14.17 > | Expires ; Section 14.21 > | Last-Modified ; Section 14.29 > | extension-header > > extension-header = message-header > > > From these definitions, it's clear that HTTP intended for only the > metadata in the entity-header fields to be considered part of the > entity. In particular, there are other kinds of metadata that are *not* > included in the definition of an entity. > > It seems to me we have a few choices. > > * Stick closely to the HTTP notion of entity, in which case changes to > the DAV:getcontentlanguage, DAV:getcontenttype, DAV:getcontentlength, > and DAV:getlastmodified MUST affect the Etag, and changes to other > properties MUST NOT affect the etag. Jim, where does the "MUST NOT" come from??? A server that changes the ETag although the entity didn't change is completely compliant to the spec. Only the other direction (content change -> etag change) is a MUST, because it's relevant for interoperability (cache correctness). A server that changes ETags although that wasn't necessary causes cache misses, that's it. It only becomes an issue for authoring clients. > * Make a clear distinction between WebDAV properties and HTTP entities, > stating that changes to WebDAV properties MUST NOT cause changes to HTTP > entities. I still don't see why we're using RFC2119 syntax here... Anyway, if the issue is with clients that do a sequence of PROPPATCH/PUT (or the other way around), and we want them to be able to use the ETag in an "If" header, why don't we simply tell servers to return the ETag upon PROPPATCH if it changed? In that case the client will always have the latest ETag, and it doesn't matter at all whether it changes with PROPPATCH or not. > * Consider WebDAV properties to be part of the state of the resource, > even though they (except for the properties listed above) do not affect > the entity (as defined by HTTP), and hence any change to a property MUST > cause a change to the Etag. I don't think anybody likes that idea. > I'll note that the third option seems to be the hardest one to defend > based purely on the language of the HTTP specification. > > Another solution is to introduce a new state token representing the dead > property state. This token could be retrieved from a property, or > available in a response header (perhaps for PROPFIND). This would allow > WebDAV to discuss the impact of property changes on a state token > without having to alter the definition of entity in HTTP. That's also an interesting idea. I don't think it's relevant to this discussion, as servers that currently change ETags upon PROPPATCH do not do this because they feel it's a good idea, but because changing properties indeed causes a change to their backend that *results* in the ETag changing. So introducing a new state token wouldn't change that situation at all. > R4) Require servers to store arbitrary binary content, > > This seems too strong to me. I think the requirement should be for > clients to discover when a server does not accept arbitrary binary > content, either by an appropriate error code for PUT, or via some other <http://greenbytes.de/tech/webdav/rfc2616.html#status.415> > discovery mechanism (a property that exists that describes acceptable > MIME types and/or XML schemas?) Something like that. Certainly not in scope for RFC2518bis, right? > R5) Require servers to store dead properties, > > Same as for R4. Yep. >> R6) Require servers to use persist Content-Type upon PUT. > > I agree this is a SHOULD level requirement. So do I. Any help in arguing this with RoyF appreciated :-). >> I strongly object to any attempt to transform WebDAV into something >> like NFS over HTTP. WebDAV is an *extension* to HTTP; and HTTP has >> been designed for a wide variety of resource types, not only serving >> files. The good thing is that I'm almost sure that the IESG wouldn't >> let us do that anyway. >> > > I believe that these issues are more broad than just filesystem-like vs > non-filesystem-like, and hence framing the issue as "what those > filesystem-like clients need" is not productive. Point taken; but I still think we really need to make sure other use cases will not break. That would take away a lot of WebDAV's (and HTTP's) flexibility. I really think that what we're talking about is a specific profile. Should we be able to converge on what the feature set is, all that's left to do is to give it a name and make it easily discoverable upfront. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 17:09:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTCS-0003Aa-Ry for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:09:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20806 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 17:08:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoTAt-0006A3-OK for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 22:08:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoTAd-00068j-T8 for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 22:07:51 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoTAW-0008TU-Bl for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 22:07:51 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Dec 2005 14:07:44 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBJM7fpf020121; Mon, 19 Dec 2005 14:07:41 -0800 (PST) Received: from 10.21.96.112 ([10.21.96.112]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Dec 2005 22:07:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 19 Dec 2005 14:07:49 -0800 From: Cullen Jennings <fluffy@cisco.com> To: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org> Message-ID: <BFCC6F35.660D3%fluffy@cisco.com> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYE6KX35J58PHDbEdqCAQARJEEJ/A== In-Reply-To: <43A704DE.5070407@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EoTAW-0008TU-Bl 47a2ff027a091885e16c2a56d65054c3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/BFCC6F35.660D3%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11214 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoTAt-0006A3-OK@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 22:08:07 +0000 Content-Transfer-Encoding: 7bit Let's say Alice has a compliant webdav client that stores gif files, and Bob has a compliant dav server? Will these things work together? I can imagine a couple answers: 1) we don't know, it might work, it might not - there is really no way to know 2) no Alice's client is not compliant because the only thing a webdav server has to store is HTML 3) yes, given it passes policy constraints, such as no virus in gif file, size of file, total size amount of quota, valid account and password, all is fine... I'm confused - which one of these does the WG want. This is actually a specific instance of a meta issue. The meta issue is are we making things easy for both client and server side in a way that causes it to be unclear if the a client and server can actually work together. I may not understand the issue here and I don't care how we solve it, but it seems to me that a client and server should be able to work together. few bits inline ... On 12/19/05 11:07 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > R4) Require servers to store arbitrary binary content > > There are servers that don't, examples may be Atom servers, Calendaring > servers, and any kind of server that uses HTTP/Webdav to expose specific > types of resources with no generic store available. This seems irrelevant. They are not DAV servers, they are complain to some other RFC that does use DAV as the protocol but adds additional constraints, extensions, and semantics such as only iCal files can exists at a given URI. > > Even if this would not be the case, I have to point out that the spec > currently mentions scenarios where servers may rewrite content without > notice (see > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.sec > tion.19.8>). Again this example is more along the lines of a specific policy modification that was done to the data to meet certain security requirements. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 17:13:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTFw-0003ej-GW for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:13:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21635 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 17:12:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoTER-00072S-A0 for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 22:11:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoTEM-00071t-Tw for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 22:11:42 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoTEK-0001Da-4R for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 22:11:42 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Dec 2005 14:11:39 -0800 X-IronPort-AV: i="3.99,268,1131350400"; d="scan'208"; a="242894017:sNHT31519352" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBJMBaMe017951; Mon, 19 Dec 2005 14:11:37 -0800 (PST) Received: from 10.21.96.112 ([10.21.96.112]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Dec 2005 22:11:36 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 19 Dec 2005 14:11:45 -0800 From: Cullen Jennings <fluffy@cisco.com> To: Julian Reschke <julian.reschke@gmx.de>, Jim Whitehead <ejw@soe.ucsc.edu> CC: WebDav <w3c-dist-auth@w3.org> Message-ID: <BFCC7021.660D9%fluffy@cisco.com> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYE6TKhcOykv3DcEdqCAQARJEEJ/A== In-Reply-To: <43A72B27.4060900@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (lisa.w3.org: domain of fluffy@cisco.com designates 171.68.10.87 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EoTEK-0001Da-4R ce809ac2f8947883e639e9567781a5a0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/BFCC7021.660D9%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoTER-00072S-A0@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 22:11:47 +0000 Content-Transfer-Encoding: 7bit On 12/19/05 1:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: >> R2) Require servers to return entity tags for PUT requests >> >> Required. Or, put another way, what clients need is the ability to know >> the final value of the etag assigned to the server's representation of >> the resource created by a successful PUT. It seems that the best way to >> do this is to have the server respond with that Etag in the PUT >> response. What might also work is for there to be a guarantee that this >> final etag will be available within a given time period, and hence >> clients will only need to perform a single follow-on request to get this >> etag. However, protocol requirements involving timing are usually very >> hard to get right -- it's not my first choice. That's why I think >> returning the etag in the PUT response is the best way to communicate >> this final etag value. > > Again, if we require this, we'll have to make sure everybody agrees on > what this means. That, at a minimum, requires getting consensus on the > HTTP mailing list, and getting that consensus into the RFC2616 errata. Help me understand the logic of why we need RFC2616 errata on this. Are we going to do something that is a violation of 2616 or just something that a 2616 server would not typically do? From rijmen@gpwelllogging.com Mon Dec 19 17:14:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTGc-0003r2-14 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:14:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21799 for <webdav-archive@ietf.org>; Mon, 19 Dec 2005 17:12:58 -0500 (EST) Received: from 82-39-3-21.cable.ubr01.gate.blueyonder.co.uk ([82.39.3.21] helo=-1208608776) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoTIr-0007dq-Cr for webdav-archive@ietf.org; Mon, 19 Dec 2005 17:16:23 -0500 Received: from gpwelllogging.com (-1214665792 [-1218209752]) by 82-39-3-21.cable.ubr01.gate.blueyonder.co.uk (Qmailv1) with ESMTP id 821D99E8C9 for <webdav-archive@ietf.org>; Sun, 18 Dec 2005 20:57:47 -0600 Date: Sun, 18 Dec 2005 20:57:47 -0600 From: Doctor <rijmen@gpwelllogging.com> X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <3218037337.20051218205747@gpwelllogging.com> To: Webdav <webdav-archive@ietf.org> Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------C3B87A7792D8B79" X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 X-Spam-Score: 4.2 (++++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------C3B87A7792D8B79 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlmagra $3.3 Lebvitra $3.3 Ciialis $3.7 Imiitrex $16.4 Floamax $2.2 Ultbram $0.78 Vivoxx $4.75 Amzbien $2.2 Valigum $0.97 Xabnax $1.09 Somja $3 Merbidia $2.2 visit our website http://uparisicar.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals ertytyjiklg RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------C3B87A7792D8B79 Content-Type: text/html Content-Transfer-Encoding: 7bit <html> <body> <b>Vlvagra - $3.3 <br> Levvitra - $3.3<br> Cizalis - $3.7<br> Imiztrex - $16.4<br> Flobmax - $2.2<br> Ulttram - $0.78<br> Vivoxx - $4.75 <br> Amgbien - $2.2<br> Valihum - $0.97 <br> Xaynax - $1.09<br> Somia - $3 <br> Merjidia - $2.2</b><br> <br> <br> <a href="http://uparisicar.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ="><strong>visit our website</strong></a><br> <br> <br> Best regards,<br> Online Pharmaceuticals <br> <br> ertytyjiklg RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= </body> </html> ------------C3B87A7792D8B79-- From w3c-dist-auth-request@frink.w3.org Mon Dec 19 17:22:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTP6-0006NK-9m for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:22:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24574 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 17:21:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoTNY-0002UM-70 for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 22:21:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoTNO-0002Tm-Pe for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 22:21:02 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoTNH-0004Cl-Gz for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 22:21:02 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBJMKld0017398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Dec 2005 14:20:48 -0800 (PST) In-Reply-To: <BFCC7021.660D9%fluffy@cisco.com> References: <BFCC7021.660D9%fluffy@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> Cc: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org> Content-Transfer-Encoding: 7bit From: Jim Whitehead <ejw@soe.ucsc.edu> Date: Mon, 19 Dec 2005 14:20:46 -0800 To: Cullen Jennings <fluffy@cisco.com> X-Mailer: Apple Mail (2.746.2) Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1EoTNH-0004Cl-Gz 3d5c0d9a79fa1a403b60eb7693340a9e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11216 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoTNY-0002UM-70@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 22:21:12 +0000 Content-Transfer-Encoding: 7bit I'd like clarification as well. It's fine for WebDAV to place additional requirements on base HTTP servers. I don't see anything in the definition of PUT or of the Etag header that would prevent Etag being returned by PUT. - Jim On Dec 19, 2005, at 2:11 PM, Cullen Jennings wrote: > On 12/19/05 1:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > >>> R2) Require servers to return entity tags for PUT requests >>> >>> Required. Or, put another way, what clients need is the ability >>> to know >>> the final value of the etag assigned to the server's >>> representation of >>> the resource created by a successful PUT. It seems that the best >>> way to >>> do this is to have the server respond with that Etag in the PUT >>> response. What might also work is for there to be a guarantee >>> that this >>> final etag will be available within a given time period, and hence >>> clients will only need to perform a single follow-on request to >>> get this >>> etag. However, protocol requirements involving timing are usually >>> very >>> hard to get right -- it's not my first choice. That's why I think >>> returning the etag in the PUT response is the best way to >>> communicate >>> this final etag value. >> >> Again, if we require this, we'll have to make sure everybody >> agrees on >> what this means. That, at a minimum, requires getting consensus on >> the >> HTTP mailing list, and getting that consensus into the RFC2616 >> errata. > > Help me understand the logic of why we need RFC2616 errata on this. > Are we > going to do something that is a violation of 2616 or just something > that a > 2616 server would not typically do? From w3c-dist-auth-request@frink.w3.org Mon Dec 19 17:54:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTts-0003NQ-6p for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:54:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02061 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 17:53:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoTrp-0001QH-JI for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 22:52:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoTrd-0001Ph-5j for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 22:52:17 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EoTrZ-00076f-2t for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 22:52:16 +0000 Received: (qmail invoked by alias); 19 Dec 2005 22:51:59 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp027) with SMTP; 19 Dec 2005 23:51:59 +0100 X-Authenticated: #1915285 Message-ID: <43A73936.6020806@gmx.de> Date: Mon, 19 Dec 2005 23:50:30 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead <ejw@soe.ucsc.edu> CC: Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> In-Reply-To: <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EoTrZ-00076f-2t 42307f78cae376a66f9e155e48dcdea1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A73936.6020806@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11217 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoTrp-0001QH-JI@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 22:52:29 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > I'd like clarification as well. > > It's fine for WebDAV to place additional requirements on base HTTP > servers. I don't see anything in the definition of PUT or of the Etag > header that would prevent Etag being returned by PUT. That's not the issue here. The question here is whether an ETag returned upon PUT is for the entity the client sent (1), or for the entity the server would send upon a subsequent GET (2). There are cases where both will not be the same, so this needs to be clarified. In case of (2), a client will need a subsequent GET if it's planning to use the ETag for subsequent GET/Range requests. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:03:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoU2L-0005Ds-DL for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:03:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03246 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:02:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoU0l-00047e-4L for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:01:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoU0f-00046C-TS for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:01:37 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EoU0Y-00020A-CI for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:01:37 +0000 Received: (qmail invoked by alias); 19 Dec 2005 22:54:44 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp034) with SMTP; 19 Dec 2005 23:54:44 +0100 X-Authenticated: #1915285 Message-ID: <43A739DB.6030702@gmx.de> Date: Mon, 19 Dec 2005 23:53:15 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> CC: Jim Whitehead <ejw@soe.ucsc.edu>, WebDav <w3c-dist-auth@w3.org> References: <BFCC7021.660D9%fluffy@cisco.com> In-Reply-To: <BFCC7021.660D9%fluffy@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoU0Y-00020A-CI 5c271c49df8b92c9841ead320ed78940 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A739DB.6030702@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11218 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoU0l-00047e-4L@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:01:43 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 12/19/05 1:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > >>> R2) Require servers to return entity tags for PUT requests >>> >>> Required. Or, put another way, what clients need is the ability to know >>> the final value of the etag assigned to the server's representation of >>> the resource created by a successful PUT. It seems that the best way to >>> do this is to have the server respond with that Etag in the PUT >>> response. What might also work is for there to be a guarantee that this >>> final etag will be available within a given time period, and hence >>> clients will only need to perform a single follow-on request to get this >>> etag. However, protocol requirements involving timing are usually very >>> hard to get right -- it's not my first choice. That's why I think >>> returning the etag in the PUT response is the best way to communicate >>> this final etag value. >> Again, if we require this, we'll have to make sure everybody agrees on >> what this means. That, at a minimum, requires getting consensus on the >> HTTP mailing list, and getting that consensus into the RFC2616 errata. > > Help me understand the logic of why we need RFC2616 errata on this. Are we > going to do something that is a violation of 2616 or just something that a > 2616 server would not typically do? If we're saying that a server SHOULD return an ETag, we'll have to take a position about what that ETag is for. So if we do (I'm not saying we necessarily shouldn't), we better make sure it's compliant to what a potential revision of RFC2616 is going to say. The best way to achieve this is to agree on that clarification, and to put it into RFC2616's errata. Best regards, JUlian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:06:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoU5j-00061O-RG for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:06:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03511 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:05:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoU4E-0004wR-1p for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:05:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoU4B-0004vq-NY for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:05:15 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EoU46-0003bn-RE for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:05:15 +0000 Received: (qmail invoked by alias); 19 Dec 2005 23:05:08 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp019) with SMTP; 20 Dec 2005 00:05:08 +0100 X-Authenticated: #1915285 Message-ID: <43A73C4B.3010603@gmx.de> Date: Tue, 20 Dec 2005 00:03:39 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings <fluffy@cisco.com> CC: WebDav <w3c-dist-auth@w3.org> References: <BFCC6F35.660D3%fluffy@cisco.com> In-Reply-To: <BFCC6F35.660D3%fluffy@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoU46-0003bn-RE 2fb9883adc99862554e41abd46fdbfe6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A73C4B.3010603@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoU4E-0004wR-1p@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:05:18 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Let's say Alice has a compliant webdav client that stores gif files, and Bob > has a compliant dav server? Will these things work together? > > I can imagine a couple answers: > > 1) we don't know, it might work, it might not - there is really no way to > know As of now (RFC2616 + RFC2518), we don't know. A server is free to reject whatever it feels to. If anybody thinks this is not the case, please back that up with references to normative specification text. But is it good that a client won't know until it tries, potentially getting a 415 status code? No, thus the proposal to make that feature discoverable. > 2) no Alice's client is not compliant because the only thing a webdav server > has to store is HTML Nobody is saying that, as far I can tell. > 3) yes, given it passes policy constraints, such as no virus in gif file, > size of file, total size amount of quota, valid account and password, all is > fine... Nope. > I'm confused - which one of these does the WG want. This is actually a > specific instance of a meta issue. The meta issue is are we making things > easy for both client and server side in a way that causes it to be unclear > if the a client and server can actually work together. I want servers to be able to do (1). I want clients to be able to detect (3). I want as many clients as possible to talk to servers that do not guarantee (3). > I may not understand the issue here and I don't care how we solve it, but it > seems to me that a client and server should be able to work together. Yes. >> R4) Require servers to store arbitrary binary content >> >> There are servers that don't, examples may be Atom servers, Calendaring >> servers, and any kind of server that uses HTTP/Webdav to expose specific >> types of resources with no generic store available. > > This seems irrelevant. They are not DAV servers, they are complain to some > other RFC that does use DAV as the protocol but adds additional constraints, > extensions, and semantics such as only iCal files can exists at a given URI. I think there's a broad consensus that Calendaring servers and Atom servers should be able to be WebDAV servers as well. >> Even if this would not be the case, I have to point out that the spec >> currently mentions scenarios where servers may rewrite content without >> notice (see >> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.sec >> tion.19.8>). > > > Again this example is more along the lines of a specific policy modification > that was done to the data to meet certain security requirements. How does this make a difference to the client? It may either have to manage to live with a 4xx upon PUT, or with content being different from what he thought he stored. Yes, that's an edge case, but it's VERY similar to the case where a Calendaring server or an Atom server drops parts of the content that was PUT because it didn't fit with the servers's internal data model. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoU78-0006qQ-As for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:08:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03805 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:07:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoU5d-00053K-TB for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:06:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoU5a-00052k-DW for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:06:42 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoU5X-0004CO-4i for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:06:41 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJN6Wul006378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2005 15:06:33 -0800 Received: from [129.46.225.69] (dhcp-campbell-26.qualcomm.com [129.46.225.69]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJN6Ugu026812; Mon, 19 Dec 2005 15:06:31 -0800 (PST) Mime-Version: 1.0 Message-Id: <p06230909bfcceba46bbe@[129.46.225.69]> In-Reply-To: <43A73936.6020806@gmx.de> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> Date: Mon, 19 Dec 2005 15:06:28 -0800 To: Julian Reschke <julian.reschke@gmx.de>, Jim Whitehead <ejw@soe.ucsc.edu> From: Ted Hardie <hardie@qualcomm.com> Cc: Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> Content-Type: text/plain; charset="us-ascii" Received-SPF: none (lisa.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoU5X-0004CO-4i 0c9c89ebe7d068e67187ed5c111533de X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/p06230909bfcceba46bbe@%5B129.46.225.69%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11220 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoU5d-00053K-TB@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:06:45 +0000 At 11:50 PM +0100 12/19/05, Julian Reschke wrote: >Jim Whitehead wrote: >>I'd like clarification as well. >> >>It's fine for WebDAV to place additional requirements on base HTTP servers. I don't see anything in the definition of PUT or of the Etag header that would prevent Etag being returned by PUT. > >That's not the issue here. > >The question here is whether an ETag returned upon PUT is for the entity the client sent (1), or for the entity the server would send upon a subsequent GET (2). I have personally always assumed that an ETag returned on a PUT is for the entity the client sent , and that if what the client would get at a subsequent GET was different, the ETag changed. It's not clear to me how a subsequent range request would work interoperably if this were not the case, as it seems to require that the client understand what transformation the server is going to perform (that is, the client would have to somehow know what the bits would be after its PUT). It certainly seems easier to me to code a conditional with this assumption. Just my personal opinion, regards, Ted Hardie From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:11:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoUAH-0007Ga-KR for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:11:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04168 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:10:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoU8l-0005UM-1Z for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:09:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoU8f-0005Te-7X for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:09:53 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoU8V-0005Qn-VQ for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:09:53 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBJN9Yu8013270; Tue, 20 Dec 2005 00:09:34 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBJN9DLP013141; Tue, 20 Dec 2005 00:09:13 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBJN9CGS000499; Tue, 20 Dec 2005 00:09:12 +0100 (MET) Date: Tue, 20 Dec 2005 00:09:12 +0100 (MET) From: Yves Lafon <ylafon@w3.org> X-X-Sender: ylafon@tarantula.inria.fr To: Julian Reschke <julian.reschke@gmx.de> cc: Jim Whitehead <ejw@soe.ucsc.edu>, Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> In-Reply-To: <43A73936.6020806@gmx.de> Message-ID: <Pine.GSO.4.64.0512192358180.14@gnenaghyn.vaevn.se> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 20 Dec 2005 00:09:14 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoU8V-0005Qn-VQ 304345f26205ac78ed102cb1e38be5bc X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512192358180.14@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoU8l-0005UM-1Z@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:09:59 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 19 Dec 2005, Julian Reschke wrote: > > Jim Whitehead wrote: >> I'd like clarification as well. >>=20 >> It's fine for WebDAV to place additional requirements on base HTTP serve= rs.=20 >> I don't see anything in the definition of PUT or of the Etag header that= =20 >> would prevent Etag being returned by PUT. > > That's not the issue here. > > The question here is whether an ETag returned upon PUT is for the entity = the=20 > client sent (1), or for the entity the server would send upon a subsequen= t=20 > GET (2). My implementation returns the ETag that asubsequent GET would see, so=20 option (2). Ans I am in the case where the PUT entity and the served=20 entity will not be the same, as there are CVS actions done during the PUT,= =20 so possible keyword extensions, etc... > There are cases where both will not be the same, so this needs to be=20 > clarified. In case of (2), a client will need a subsequent GET if it's=20 > planning to use the ETag for subsequent GET/Range requests. > > Best regards, Julian > > --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoUKX-00017o-Jo for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:22:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05268 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:21:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoUIw-00007U-Vb for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:20:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoUIl-0008V5-3h for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:20:19 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoUIe-0001Au-3b; Mon, 19 Dec 2005 23:20:19 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJNK6ul007734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2005 15:20:06 -0800 Received: from [129.46.225.69] (dhcp-campbell-26.qualcomm.com [129.46.225.69]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJNK3Yg008384; Mon, 19 Dec 2005 15:20:04 -0800 (PST) Mime-Version: 1.0 Message-Id: <p0623090abfccf05e8730@[129.46.225.69]> In-Reply-To: <Pine.GSO.4.64.0512192358180.14@gnenaghyn.vaevn.se> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> <Pine.GSO.4.64.0512192358180.14@gnenaghyn.vaevn.se> Date: Mon, 19 Dec 2005 15:20:02 -0800 To: Yves Lafon <ylafon@w3.org>, Julian Reschke <julian.reschke@gmx.de> From: Ted Hardie <hardie@qualcomm.com> Cc: Jim Whitehead <ejw@soe.ucsc.edu>, Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> Content-Type: text/plain; charset="us-ascii" Received-SPF: none (lisa.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoUIe-0001Au-3b 3a2d18efb1612cdef9fe888a8f45cc10 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/p0623090abfccf05e8730@%5B129.46.225.69%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11222 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoUIw-00007U-Vb@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:20:30 +0000 At 12:09 AM +0100 12/20/05, Yves Lafon wrote: > > >My implementation returns the ETag that asubsequent GET would see, so option (2). Ans I am in the case where the PUT entity and the served entity will not be the same, as there are CVS actions done during the PUT, so possible keyword extensions, etc... Are these property changes, or changes to the entity itself? If to the entity, how does a get-range work? regards, Ted Hardie From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:28:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoUQk-0001sV-6e for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:28:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05854 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:27:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoUP6-0000nO-Pi for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:26:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoUOu-0000mc-Sx for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:26:40 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EoUOq-0003kP-J6 for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:26:40 +0000 Received: (qmail invoked by alias); 19 Dec 2005 23:19:54 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp027) with SMTP; 20 Dec 2005 00:19:54 +0100 X-Authenticated: #1915285 Message-ID: <43A73FC0.8030208@gmx.de> Date: Tue, 20 Dec 2005 00:18:24 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ted Hardie <hardie@qualcomm.com> CC: Jim Whitehead <ejw@soe.ucsc.edu>, Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> <p06230909bfcceba46bbe@[129.46.225.69]> In-Reply-To: <p06230909bfcceba46bbe@[129.46.225.69]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoUOq-0003kP-J6 762702ff1879c0a299820360b9cf133a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A73FC0.8030208@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoUP6-0000nO-Pi@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:26:52 +0000 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > At 11:50 PM +0100 12/19/05, Julian Reschke wrote: >> Jim Whitehead wrote: >>> I'd like clarification as well. >>> >>> It's fine for WebDAV to place additional requirements on base HTTP servers. I don't see anything in the definition of PUT or of the Etag header that would prevent Etag being returned by PUT. >> That's not the issue here. >> >> The question here is whether an ETag returned upon PUT is for the entity the client sent (1), or for the entity the server would send upon a subsequent GET (2). > > I have personally always assumed that an ETag returned on a PUT is for the entity the client sent , and that if what the client would get at a subsequent GET was different, the ETag changed. It's not clear to me how a subsequent range request would work interoperably if this were not the case, as it seems to require that the client understand what transformation the server is going to perform (that is, the client would have to somehow know what the bits would be after its PUT). It certainly seems easier to me to code a conditional with this assumption. > > Just my personal opinion, > regards, > Ted Hardie Ted, thanks a lot for the feedback. As a matter of fact, I thought the same until recently when I asked on the HTTP mailing list. Scott Lawrence (<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0014.html>), Mark Baker (<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0016.html>), and Henrik Frystyk Nielsen (<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0017.html>) disagreed with that point of view (and this was the only feedback, except for agreement that RFC2616 should be clarified). This is why I think that we shouldn't PUT^h^h^hput in this requirement unless we tell people what it means, and we make sure we are in agreement with what a potential revision of RFC2616 is going to say about it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 18:32:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoUUJ-0002yL-4S for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 18:32:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06167 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 18:31:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoUSk-0002SP-Bt for w3c-dist-auth-dist@listhub.w3.org; Mon, 19 Dec 2005 23:30:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoUSe-00025L-VE for w3c-dist-auth@listhub.w3.org; Mon, 19 Dec 2005 23:30:33 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EoUSa-00021P-Pe for w3c-dist-auth@w3.org; Mon, 19 Dec 2005 23:30:31 +0000 Received: (qmail invoked by alias); 19 Dec 2005 23:30:23 -0000 Received: from p508F8D0C.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.141.12] by mail.gmx.net (mp039) with SMTP; 20 Dec 2005 00:30:23 +0100 X-Authenticated: #1915285 Message-ID: <43A74234.6020501@gmx.de> Date: Tue, 20 Dec 2005 00:28:52 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ted Hardie <hardie@qualcomm.com> CC: Yves Lafon <ylafon@w3.org>, Jim Whitehead <ejw@soe.ucsc.edu>, Cullen Jennings <fluffy@cisco.com>, WebDav <w3c-dist-auth@w3.org> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> <Pine.GSO.4.64.0512192358180.14@gnenaghyn.vaevn.se> <p0623090abfccf05e8730@[129.46.225.69]> In-Reply-To: <p0623090abfccf05e8730@[129.46.225.69]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoUSa-00021P-Pe 3456df13a2329e3d0321a9cc0f0612de X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A74234.6020501@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11224 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoUSk-0002SP-Bt@frink.w3.org> Resent-Date: Mon, 19 Dec 2005 23:30:38 +0000 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > At 12:09 AM +0100 12/20/05, Yves Lafon wrote: >> >> My implementation returns the ETag that asubsequent GET would see, so option (2). Ans I am in the case where the PUT entity and the served entity will not be the same, as there are CVS actions done during the PUT, so possible keyword extensions, etc... > > Are these property changes, or changes to the entity itself? If to the entity, how does a get-range work? My interpretation is that a GET/Range will not work, that is, a client which obtained an ETag upon PUT will have to *know* that the content may have been rewritten before the ETag as assigned. This is exactly why I'm keep telling people that we need to decide what the ETag means, and also make sure that what we're saying is the same thing that RFC2616bis is going to say (should it ever become reality). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Dec 19 19:14:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoV8v-0003R6-QQ for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 19:14:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10292 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 19:13:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoV6z-0001AS-40 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 00:12:13 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoV6q-00019a-5Y for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 00:12:04 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by aji.w3.org with esmtp (Exim 4.50) id 1EoV6Z-00010J-13 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 00:11:59 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 19 Dec 2005 16:11:44 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBK0Bdpf010041; Mon, 19 Dec 2005 16:11:40 -0800 (PST) Received: from 10.21.96.112 ([10.21.96.112]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Dec 2005 00:11:39 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 19 Dec 2005 16:11:48 -0800 From: Cullen Jennings <fluffy@cisco.com> To: Julian Reschke <julian.reschke@gmx.de> CC: WebDav <w3c-dist-auth@w3.org> Message-ID: <BFCC8C44.6615B%fluffy@cisco.com> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYE+ff0NngU7nDtEdqCAQARJEEJ/A== In-Reply-To: <43A73C4B.3010603@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.org: domain of fluffy@cisco.com designates 171.71.176.71 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1EoV6Z-00010J-13 394dcef84c1dcc9aeaabc909e1939b70 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/BFCC8C44.6615B%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11225 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoV6z-0001AS-40@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 00:12:13 +0000 Content-Transfer-Encoding: 7bit On 12/19/05 3:03 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > Cullen Jennings wrote: >> Let's say Alice has a compliant webdav client that stores gif files, and Bob >> has a compliant dav server? Will these things work together? >> >> I can imagine a couple answers: >> >> 1) we don't know, it might work, it might not - there is really no way to >> know > > As of now (RFC2616 + RFC2518), we don't know. A server is free to reject > whatever it feels to. If anybody thinks this is not the case, please > back that up with references to normative specification text. > > But is it good that a client won't know until it tries, potentially > getting a 415 status code? No, thus the proposal to make that feature > discoverable. Ok, so what is your advice to client implementers? Do you want to specify something they can count on working? XML works? 7 bit ascii works? XHTML works? Getting a 415 might tell you the end user why it failed (though probably not given most client software) but it is not going to make it work. If people are comfortable with there is no guarantee that even the most trivial things will interoperate with this protocol, I'm not pushing it. I'm just a checking that I correctly understand this as I find it slightly surprising. Cullen From w3c-dist-auth-request@frink.w3.org Mon Dec 19 20:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoW6v-0000Fg-RY for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 20:16:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16442 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 20:15:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoW4y-0004Qo-Km for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 01:14:12 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoW4n-0004Os-3I for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 01:14:01 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.org with esmtp (Exim 4.50) id 1EoW4e-0007Xg-PA for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 01:14:00 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBK1DnUn012961; Mon, 19 Dec 2005 17:13:49 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 77CD2177; Mon, 19 Dec 2005 17:13:49 -0800 (PST) In-Reply-To: <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <D4C6001A-AC71-4471-9585-A51196B7140A@wsanchez.net> Cc: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net> Date: Mon, 19 Dec 2005 17:13:48 -0800 To: Jim Whitehead <ejw@soe.ucsc.edu> X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoW4e-0007Xg-PA a983db000d221751fd8942c564022288 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/D4C6001A-AC71-4471-9585-A51196B7140A@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11227 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoW4y-0004Qo-Km@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 01:14:12 +0000 Content-Transfer-Encoding: 7bit There is no such thing as a final etag value. Why pretend there is? The tag could change for any number of reasons, including someone coming along and changing the content right after your PUT. Absent some reliable notification mechanism, there is no way to know that your locally cached copy is what's presently on the server, regardless of whether the server gives you a stable etag in the PUT response or not. So this requirement doesn't get you what you are wishing for. -wsv On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote: > R2) Require servers to return entity tags for PUT requests > > Required. Or, put another way, what clients need is the ability to > know the final value of the etag assigned to the server's > representation of the resource created by a successful PUT. It > seems that the best way to do this is to have the server respond > with that Etag in the PUT response. What might also work is for > there to be a guarantee that this final etag will be available > within a given time period, and hence clients will only need to > perform a single follow-on request to get this etag. However, > protocol requirements involving timing are usually very hard to get > right -- it's not my first choice. That's why I think returning the > etag in the PUT response is the best way to communicate this final > etag value. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 20:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoW6w-0000Fj-33 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 20:16:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16439 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 20:15:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoW4q-0004Pd-6E for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 01:14:04 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoW4h-0004OP-LU for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 01:13:55 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.org with esmtp (Exim 4.50) id 1EoW4Z-0007UI-D4 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 01:13:54 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBK1DeAo012905; Mon, 19 Dec 2005 17:13:40 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id E886D177; Mon, 19 Dec 2005 17:13:39 -0800 (PST) In-Reply-To: <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <DCEC167B-F3EA-4D77-913F-694D618A9225@wsanchez.net> Cc: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net> Date: Mon, 19 Dec 2005 17:13:39 -0800 To: Jim Whitehead <ejw@soe.ucsc.edu> X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoW4Z-0007UI-D4 f7985aaca21d29b63cb4964038f98d34 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/DCEC167B-F3EA-4D77-913F-694D618A9225@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11226 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoW4q-0004Pd-6E@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 01:14:04 +0000 Content-Transfer-Encoding: 7bit The second option seems impossible. If modifying the last- modified time on an HTTP entity MUST change the etag and modifying DAV:getlastmodified MUST NOT, that's contradictory, give the definition of DAV:getlastmodified. I don't think any of these three options makes sense as a requirement. -wsv On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote: > It seems to me we have a few choices. > > * Stick closely to the HTTP notion of entity, in which case changes > to the DAV:getcontentlanguage, DAV:getcontenttype, > DAV:getcontentlength, and DAV:getlastmodified MUST affect the Etag, > and changes to other properties MUST NOT affect the etag. > > * Make a clear distinction between WebDAV properties and HTTP > entities, stating that changes to WebDAV properties MUST NOT cause > changes to HTTP entities. > > * Consider WebDAV properties to be part of the state of the > resource, even though they (except for the properties listed above) > do not affect the entity (as defined by HTTP), and hence any change > to a property MUST cause a change to the Etag. > > I'll note that the third option seems to be the hardest one to > defend based purely on the language of the HTTP specification. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 21:13:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoX0L-0006AF-So for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 21:13:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23209 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 21:12:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoWyh-0002oA-0U for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 02:11:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoWyU-0002mp-H2 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 02:11:34 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EoWyR-0007ig-1B for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 02:11:33 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBK2B4Sx014322 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Dec 2005 18:11:04 -0800 (PST) In-Reply-To: <43A73936.6020806@gmx.de> References: <BFCC7021.660D9%fluffy@cisco.com> <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <CE46B9D4-F74D-4843-81A6-C783F482A78C@cs.ucsc.edu> Cc: Cullen Jennings <fluffy@cisco.com>, WebDav WG <w3c-dist-auth@w3.org> Content-Transfer-Encoding: 7bit From: Jim Whitehead <ejw@soe.ucsc.edu> Date: Mon, 19 Dec 2005 18:11:02 -0800 To: Julian Reschke <julian.reschke@gmx.de> X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1EoWyR-0007ig-1B 7f4f98e7932a61c785c4edf1fdfbcfc6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/CE46B9D4-F74D-4843-81A6-C783F482A78C@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11228 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoWyh-0002oA-0U@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 02:11:47 +0000 Content-Transfer-Encoding: 7bit > Julian, Thanks for making this more clear -- you're right, there is a significant issue here. > The question here is whether an ETag returned upon PUT is for the > entity the client sent (1), or for the entity the server would send > upon a subsequent GET (2). > > There are cases where both will not be the same, so this needs to > be clarified. In case of (2), a client will need a subsequent GET > if it's planning to use the ETag for subsequent GET/Range requests. > I think option #2 is the best one here (the Etag returned by PUT is the one a subsequent GET would retrieve). - Jim From w3c-dist-auth-request@frink.w3.org Mon Dec 19 21:18:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoX53-0006yB-U0 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 21:18:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23685 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 21:17:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoX3C-0005Xu-IP for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 02:16:26 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoX35-0005Wq-Va for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 02:16:20 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by aji.w3.org with esmtp (Exim 4.50) id 1EoX2w-00067r-1R for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 02:16:18 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBK2G514015485 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 Dec 2005 18:16:05 -0800 (PST) In-Reply-To: <D4C6001A-AC71-4471-9585-A51196B7140A@wsanchez.net> References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> <D4C6001A-AC71-4471-9585-A51196B7140A@wsanchez.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> Cc: Julian Reschke <julian.reschke@gmx.de>, WebDav WG <w3c-dist-auth@w3.org> Content-Transfer-Encoding: quoted-printable From: Jim Whitehead <ejw@soe.ucsc.edu> Date: Mon, 19 Dec 2005 18:16:03 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net> X-Mailer: Apple Mail (2.746.2) Received-SPF: none (aji.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoX2w-00067r-1R da2cb6973691858e5eb2d1d5295f8776 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoX3C-0005Xu-IP@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 02:16:26 +0000 Content-Transfer-Encoding: quoted-printable If I'm a client that has an exclusive write lock, then if I PUT to =20 that resource, the stored entity should not be modified by anyone =20 other than the server. In this case, which is the most common one for =20= DAV-based editing, it's still very useful for the client to receive =20 the final etag value in the response to PUT. Why? It saves the client =20= from having to poll an uncertain number of times before it receives =20 the final, stable etag value. I still feel that R2 is required. - Jim On Dec 19, 2005, at 5:13 PM, Wilfredo S=E1nchez Vega wrote: > > There is no such thing as a final etag value. Why pretend there =20 > is? The tag could change for any number of reasons, including =20 > someone coming along and changing the content right after your PUT. > > Absent some reliable notification mechanism, there is no way to =20 > know that your locally cached copy is what's presently on the =20 > server, regardless of whether the server gives you a stable etag in =20= > the PUT response or not. So this requirement doesn't get you what =20 > you are wishing for. > > -wsv > > > On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote: > >> R2) Require servers to return entity tags for PUT requests >> >> Required. Or, put another way, what clients need is the ability to =20= >> know the final value of the etag assigned to the server's =20 >> representation of the resource created by a successful PUT. It =20 >> seems that the best way to do this is to have the server respond =20 >> with that Etag in the PUT response. What might also work is for =20 >> there to be a guarantee that this final etag will be available =20 >> within a given time period, and hence clients will only need to =20 >> perform a single follow-on request to get this etag. However, =20 >> protocol requirements involving timing are usually very hard to =20 >> get right -- it's not my first choice. That's why I think =20 >> returning the etag in the PUT response is the best way to =20 >> communicate this final etag value. > From w3c-dist-auth-request@frink.w3.org Mon Dec 19 21:25:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoXCD-0000cY-PG for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 21:25:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24309 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 21:24:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoXAp-0006a0-4c for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 02:24:19 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoXAk-0006Yz-LQ for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 02:24:15 +0000 Received: from exprod6og7.obsmtp.com ([64.18.1.127]) by aji.w3.org with smtp (Exim 4.50) id 1EoXAg-00010Q-RR for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 02:24:13 +0000 Received: from source ([192.150.20.142]) by exprod6ob7.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 19 Dec 2005 18:24:04 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBK2NuFX021292; Mon, 19 Dec 2005 18:23:56 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBK2Nurs020888; Mon, 19 Dec 2005 18:23:57 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 18:25:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2005 18:23:58 -0800 Message-ID: <E1F796B37FB8544FA09F6258E7CED3BB4B9156@namail3.corp.adobe.com> In-Reply-To: <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFC8sQoRE6ZFPNRRChXfdX/VP/3wAAHqAQ From: "Dan Brotsky" <dbrotsky@adobe.com> To: "Jim Whitehead" <ejw@soe.ucsc.edu>, =?iso-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net> Cc: "Julian Reschke" <julian.reschke@gmx.de>, "WebDav WG" <w3c-dist-auth@w3.org> X-OriginalArrivalTime: 20 Dec 2005 02:25:14.0923 (UTC) FILETIME=[9C73F7B0:01C6050C] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoXAg-00010Q-RR 290ca89a293a9b443d106ee4e35c1309 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9156@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoXAp-0006a0-4c@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 02:24:19 +0000 Content-Transfer-Encoding: quoted-printable I strongly agree with Jim's use case and conclusion. That's the key = issue: the client shouldn't have to poll to wait for the etag to = stabilize. dan > -----Original Message----- > From: w3c-dist-auth-request@w3.org=20 > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Whitehead > Sent: Monday, December 19, 2005 18:16 > To: Wilfredo S=E1nchez Vega > Cc: Julian Reschke; WebDav WG > Subject: Re: Summary of ETag related issues in RFC2518bis >=20 >=20 > If I'm a client that has an exclusive write lock, then if I=20 > PUT to that resource, the stored entity should not be=20 > modified by anyone other than the server. In this case, which=20 > is the most common one for DAV-based editing, it's still very=20 > useful for the client to receive the final etag value in the=20 > response to PUT. Why? It saves the client from having to poll=20 > an uncertain number of times before it receives the final,=20 > stable etag value. >=20 > I still feel that R2 is required. >=20 > - Jim >=20 > On Dec 19, 2005, at 5:13 PM, Wilfredo S=E1nchez Vega wrote: >=20 > > > > There is no such thing as a final etag value. Why=20 > pretend there is? =20 > > The tag could change for any number of reasons, including someone=20 > > coming along and changing the content right after your PUT. > > > > Absent some reliable notification mechanism, there is no=20 > way to know=20 > > that your locally cached copy is what's presently on the server,=20 > > regardless of whether the server gives you a stable etag in the PUT=20 > > response or not. So this requirement doesn't get you what you are=20 > > wishing for. > > > > -wsv > > > > > > On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote: > > > >> R2) Require servers to return entity tags for PUT requests > >> > >> Required. Or, put another way, what clients need is the ability to=20 > >> know the final value of the etag assigned to the server's=20 > >> representation of the resource created by a successful=20 > PUT. It seems=20 > >> that the best way to do this is to have the server respond=20 > with that=20 > >> Etag in the PUT response. What might also work is for=20 > there to be a=20 > >> guarantee that this final etag will be available within a=20 > given time=20 > >> period, and hence clients will only need to perform a single=20 > >> follow-on request to get this etag. However, protocol requirements=20 > >> involving timing are usually very hard to get right -- it's not my=20 > >> first choice. That's why I think returning the etag in the PUT=20 > >> response is the best way to communicate this final etag value. > > >=20 >=20 >=20 From w3c-dist-auth-request@frink.w3.org Mon Dec 19 22:01:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoXkK-0008Dm-O5 for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 22:01:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27633 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 21:59:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoXii-0005MC-0a for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 02:59:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoXiY-0005Kg-UZ for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 02:59:10 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoXh5-0000Mn-TE for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 02:59:10 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBK2vY5c005557; Mon, 19 Dec 2005 18:57:34 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay7.apple.com (Apple SCV relay) with ESMTP id 9850F50; Mon, 19 Dec 2005 18:57:34 -0800 (PST) In-Reply-To: <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> <D4C6001A-AC71-4471-9585-A51196B7140A@wsanchez.net> <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8141A98D-4D61-4308-A95C-F930A56ED5E6@wsanchez.net> Cc: Julian Reschke <julian.reschke@gmx.de>, WebDav WG <w3c-dist-auth@w3.org> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net> Date: Mon, 19 Dec 2005 18:57:34 -0800 To: Jim Whitehead <ejw@soe.ucsc.edu> X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoXh5-0000Mn-TE 995bb411dc83abf9f921667b34633483 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/8141A98D-4D61-4308-A95C-F930A56ED5E6@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoXii-0005MC-0a@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 02:59:20 +0000 Content-Transfer-Encoding: 7bit OK, I follow. The question then is how one would implement than on a server using a filesystem as the backing store, which is a *very* common case (Apache). The information have from the filesystem doesn't seem to give us enough data without doing something like checksumming the file. The performance implications of that solution are rather drastic. Absent a workable solution, we're going to be moving Apache into the non-compliant category if this is a MUST-level requirement. -wsv On Dec 19, 2005, at 6:16 PM, Jim Whitehead wrote: > If I'm a client that has an exclusive write lock, then if I PUT to > that resource, the stored entity should not be modified by anyone > other than the server. In this case, which is the most common one > for DAV-based editing, it's still very useful for the client to > receive the final etag value in the response to PUT. Why? It saves > the client from having to poll an uncertain number of times before > it receives the final, stable etag value. > > I still feel that R2 is required. From w3c-dist-auth-request@frink.w3.org Mon Dec 19 22:49:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoYVh-0001wy-4R for webdav-archive@megatron.ietf.org; Mon, 19 Dec 2005 22:49:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02717 for <webdav-archive@lists.ietf.org>; Mon, 19 Dec 2005 22:48:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoYTl-0000YQ-O9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 03:47:57 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoYTR-0000XI-As for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 03:47:37 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.50) id 1EoYTN-0006IM-3j for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 03:47:36 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBK3lCfb022572 for <w3c-dist-auth@w3.org>; Mon, 19 Dec 2005 22:47:12 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBK3lC4q126912 for <w3c-dist-auth@w3.org>; Mon, 19 Dec 2005 22:47:12 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBK3lChn000651 for <w3c-dist-auth@w3.org>; Mon, 19 Dec 2005 22:47:12 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBK3lCKI000644 for <w3c-dist-auth@w3.org>; Mon, 19 Dec 2005 22:47:12 -0500 To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> Message-ID: <OFF55202B4.32F12D01-ON852570DD.0014C19A-852570DD.0014CF4E@us.ibm.com> Date: Mon, 19 Dec 2005 22:47:17 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/19/2005 22:47:11, Serialize complete at 12/19/2005 22:47:11 Content-Type: multipart/alternative; boundary="=_alternative 0014CEE7852570DD_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1EoYTN-0006IM-3j 1445c2d5ab561cf1abdc9401f632b016 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFF55202B4.32F12D01-ON852570DD.0014C19A-852570DD.0014CF4E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11232 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoYTl-0000YQ-O9@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 03:47:57 +0000 This is a multipart message in MIME format. --=_alternative 0014CEE7852570DD_= Content-Type: text/plain; charset="US-ASCII" Jim: What about the point made by an earlier poster, namely that a server is allowed to modify the content stored by a PUT, so that a GET following the PUT might return different content than was PUT (the earlier poster gave the example of a server that expands RCS keywords on PUT). In this case (i.e. the server modifies the content stored by the PUT), if server returns the etag that would be returned on a GET, and the client requests a GET with an If-None-Match header with the etag returned by the PUT, the client will incorrectly conclude that the text it sent with the PUT is what would be retrieved by the GET. So unless we are going to disallow servers from modifying the content stored from a PUT (note that our server does not do this, so I am speaking as a neutral party here :-), we pretty much have to have PUT return the entity tag of the content that was PUT, not what would be returned by the GET. Then a client that wants to continue modifying a resource to which it has just done a PUT, would need to do a GET with an If-None-Match call following the PUT, to handle servers that do this kind of rewriting on PUT. Note that this is just a single GET, not to be confused with the "polling" scenario described in "promotion from weak to strong etag" thread. Cheers, Geoff Jim wrote on 12/19/2005 09:11:02 PM: > > Julian, > > Thanks for making this more clear -- you're right, there is a > significant issue here. > > > The question here is whether an ETag returned upon PUT is for the > > entity the client sent (1), or for the entity the server would send > > upon a subsequent GET (2). > > > > There are cases where both will not be the same, so this needs to > > be clarified. In case of (2), a client will need a subsequent GET > > if it's planning to use the ETag for subsequent GET/Range requests. > > > > I think option #2 is the best one here (the Etag returned by PUT is > the one a subsequent GET would retrieve). --=_alternative 0014CEE7852570DD_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt>Jim:</tt></font> <br> <br><font size=2><tt>What about the point made by an earlier poster, namely that</tt></font> <br><font size=2><tt>a server is allowed to modify the content stored by a PUT,</tt></font> <br><font size=2><tt>so that a GET following the PUT might return different content</tt></font> <br><font size=2><tt>than was PUT (the earlier poster gave the example of a server</tt></font> <br><font size=2><tt>that expands RCS keywords on PUT).</tt></font> <br> <br><font size=2><tt>In this case (i.e. the server modifies the content stored by</tt></font> <br><font size=2><tt>the PUT), if server returns the etag that would be returned</tt></font> <br><font size=2><tt>on a GET, and the client requests a GET with an If-None-Match</tt></font> <br><font size=2><tt>header with the etag returned by the PUT, the client will</tt></font> <br><font size=2><tt>incorrectly conclude that the text it sent with the PUT is</tt></font> <br><font size=2><tt>what would be retrieved by the GET.</tt></font> <br> <br><font size=2><tt>So unless we are going to disallow servers from modifying the</tt></font> <br><font size=2><tt>content stored from a PUT (note that our server does not do this,</tt></font> <br><font size=2><tt>so I am speaking as a neutral party here :-), we pretty much</tt></font> <br><font size=2><tt>have to have PUT return the entity tag of the content that was</tt></font> <br><font size=2><tt>PUT, not what would be returned by the GET.</tt></font> <br> <br><font size=2><tt>Then a client that wants to continue modifying a resource to</tt></font> <br><font size=2><tt>which it has just done a PUT, would need to do a GET with</tt></font> <br><font size=2><tt>an If-None-Match call following the PUT, to handle servers</tt></font> <br><font size=2><tt>that do this kind of rewriting on PUT.</tt></font> <br> <br><font size=2><tt>Note that this is just a single GET, not to be confused with</tt></font> <br><font size=2><tt>the "polling" scenario described in "promotion from weak to</tt></font> <br><font size=2><tt>strong etag" thread.</tt></font> <br> <br><font size=2><tt>Cheers,</tt></font> <br><font size=2><tt>Geoff</tt></font> <br> <br> <br><font size=2><tt>Jim wrote on 12/19/2005 09:11:02 PM:<br> ><br> > Julian,<br> > <br> > Thanks for making this more clear -- you're right, there is a  <br> > significant issue here.<br> > <br> > > The question here is whether an ETag returned upon PUT is for the  <br> > > entity the client sent (1), or for the entity the server would send  <br> > > upon a subsequent GET (2).<br> > ><br> > > There are cases where both will not be the same, so this needs to  <br> > > be clarified. In case of (2), a client will need a subsequent GET  <br> > > if it's planning to use the ETag for subsequent GET/Range requests.<br> > ><br> > <br> > I think option #2 is the best one here (the Etag returned by PUT is  <br> > the one a subsequent GET would retrieve).<br> <br> </tt></font> --=_alternative 0014CEE7852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 00:11:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoZm5-0003xA-Vb for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 00:11:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10073 for <webdav-archive@lists.ietf.org>; Tue, 20 Dec 2005 00:09:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoZk7-0003uh-RI for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 05:08:55 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoZju-0003tS-LE for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 05:08:42 +0000 Received: from aji.w3.org ([133.27.228.225]) by maggie.w3.org with esmtp (Exim 4.50) id 1EoZjt-0005By-8K for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 05:08:41 +0000 Received: from exprod6og13.obsmtp.com ([64.18.1.25]) by aji.w3.org with smtp (Exim 4.50) id 1EoZji-0007Di-Nj for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 05:08:39 +0000 Received: from source ([192.150.20.142]) by exprod6ob13.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 19 Dec 2005 21:08:27 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBK58IFX025441; Mon, 19 Dec 2005 21:08:19 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBK58JHV005322; Mon, 19 Dec 2005 21:08:19 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 21:09:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2005 21:09:21 -0800 Message-ID: <E1F796B37FB8544FA09F6258E7CED3BB4B9174@namail3.corp.adobe.com> In-Reply-To: <OFF55202B4.32F12D01-ON852570DD.0014C19A-852570DD.0014CF4E@us.ibm.com> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFGI+8zfjBGQSgRpG4F5oQLVoZQQAAP58A From: "Dan Brotsky" <dbrotsky@adobe.com> To: "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3.org> X-OriginalArrivalTime: 20 Dec 2005 05:09:38.0219 (UTC) FILETIME=[936F7FB0:01C60523] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoZji-0007Di-Nj 461e616a4ba9a4df6f7b18990cd658c3 Received-SPF: none (maggie.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9174@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11233 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoZk7-0003uh-RI@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 05:08:55 +0000 Content-Transfer-Encoding: quoted-printable Geoff, I don't follow your reasoning here when you say "the client will=20 incorrectly conclude that the text it sent with the PUT is=20 what would be retrieved by the GET." It seems like there are three cases: 1. The server modifies the value "on the way up", that is, before returning from the PUT. (This is typically how a version control system would expand keywords, as part of the checkin.) In this case the value that would eventually be retrieved by GET is known and thus its etag can be returned, even if that etag is a timestamp. 2. The server returns before modifying the value, but knows that it will do so. In this case a synthetic value for the etag can be generated and returned, as long as the server takes steps to make sure that etag is returned with the eventual GET and all GETs requested before the modifications are complete are blocked (e.g., with "server busy"). This etag can still be a timestamp, by the way, and can even be a timestamp of the checkin, as long as the server associates that time with the eventual result (which version control systems also typically do). 3. The server returns before modifying the value, and doesn't know that a modification will take place. (For example, the "type" of the file is later changed so that the file undergoes keyword expansion later.) In this case, at the time the file is modified by the server, it should assign a new etag, because indeed the etag returned at the time of the PUT should not match what a client would eventually GET. But before that later modification is done, the etag is correct. In no case does a client ever assume that "the text it sent with the PUT is what would be retrieved by the GET." That's not what the etag is for. The etag is to reassure the client that the value on the server *has not changed since the PUT completed*. No guarantees are issued that the value doesn't change as part of the PUT; that would be a part of the PUT semantics for that server and are outside the scope of WebDAV. dan ________________________________ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Monday, December 19, 2005 19:47 To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis =09 =09 Jim:=20 =09 What about the point made by an earlier poster, namely that=20 a server is allowed to modify the content stored by a PUT,=20 so that a GET following the PUT might return different content=20 than was PUT (the earlier poster gave the example of a server=20 that expands RCS keywords on PUT).=20 =09 In this case (i.e. the server modifies the content stored by=20 the PUT), if server returns the etag that would be returned=20 on a GET, and the client requests a GET with an If-None-Match=20 header with the etag returned by the PUT, the client will=20 incorrectly conclude that the text it sent with the PUT is=20 what would be retrieved by the GET.=20 =09 So unless we are going to disallow servers from modifying the=20 content stored from a PUT (note that our server does not do this,=20 so I am speaking as a neutral party here :-), we pretty much=20 have to have PUT return the entity tag of the content that was=20 PUT, not what would be returned by the GET.=20 =09 Then a client that wants to continue modifying a resource to=20 which it has just done a PUT, would need to do a GET with=20 an If-None-Match call following the PUT, to handle servers=20 that do this kind of rewriting on PUT.=20 =09 Note that this is just a single GET, not to be confused with=20 the "polling" scenario described in "promotion from weak to=20 strong etag" thread.=20 =09 Cheers,=20 Geoff=20 =09 =09 Jim wrote on 12/19/2005 09:11:02 PM: > > Julian, >=20 > Thanks for making this more clear -- you're right, there is a > significant issue here. >=20 > > The question here is whether an ETag returned upon PUT is for the =20 > > entity the client sent (1), or for the entity the server would send =20 > > upon a subsequent GET (2). > > > > There are cases where both will not be the same, so this needs to =20 > > be clarified. In case of (2), a client will need a subsequent GET =20 > > if it's planning to use the ETag for subsequent GET/Range requests. > > >=20 > I think option #2 is the best one here (the Etag returned by PUT is =20 > the one a subsequent GET would retrieve). =09 =09 From w3c-dist-auth-request@frink.w3.org Tue Dec 20 00:16:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoZrJ-0005Ft-OO for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 00:16:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10472 for <webdav-archive@lists.ietf.org>; Tue, 20 Dec 2005 00:15:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoZpq-00056Q-2n for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 05:14:50 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoZpn-00055k-J0 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 05:14:47 +0000 Received: from exprod6og9.obsmtp.com ([64.18.1.21]) by aji.w3.org with smtp (Exim 4.50) id 1EoZpk-0000vS-D7 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 05:14:46 +0000 Received: from source ([192.150.11.134]) by exprod6ob9.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 19 Dec 2005 21:14:41 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBK5EUYc017844; Mon, 19 Dec 2005 21:14:31 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBK5Ecru025679; Mon, 19 Dec 2005 21:14:39 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 21:15:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2005 21:15:39 -0800 Message-ID: <E1F796B37FB8544FA09F6258E7CED3BB4B9176@namail3.corp.adobe.com> In-Reply-To: <8141A98D-4D61-4308-A95C-F930A56ED5E6@wsanchez.net> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFEb3w+WmLzAnjR2emYjr5UrqSmwAEdoCQ From: "Dan Brotsky" <dbrotsky@adobe.com> To: =?iso-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <wsanchez@wsanchez.net>, "Jim Whitehead" <ejw@soe.ucsc.edu> Cc: "Julian Reschke" <julian.reschke@gmx.de>, "WebDav WG" <w3c-dist-auth@w3.org> X-OriginalArrivalTime: 20 Dec 2005 05:15:57.0430 (UTC) FILETIME=[75768160:01C60524] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoZpk-0000vS-D7 13cb7418b122ce7afaecc4a0f996862e X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9176@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoZpq-00056Q-2n@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 05:14:50 +0000 Content-Transfer-Encoding: quoted-printable > The question then is how one would implement than on a=20 > server using a filesystem as the backing store, which is a=20 > *very* common case (Apache). The information have from the=20 > filesystem doesn't seem to give us enough data without doing=20 > something like checksumming the file. The performance=20 > implications of that solution are rather drastic. First of all, there are many filesystems in the world that accurate to = way more than 1 millisecond, so I don't think a general statement such = as "the filesystem doesn't seem to give us enough data" is really = applicable. Second, even in filesystems with millisecond resolutions, all the = filesystem has to do is support exclusive write-locking and you can = build a compliant server. The server must simply keep the file locked = long enough to avoid the milllisecond window and then set the time back = to the write time in order to ensure that any interference is = noticeable. I don't have any problem with a standard that can't be implemented in = the simplest possible way against the weakest possible resources. All = we are saying is that, if you really have a filesystem that allows = multiple writers to interfere with one another undetectably, then you = can't build a compliant WebDAV server against that filesystem. And = that's just a fact: the server certainly can't guarantee anything = without support from the filesystem. >=20 > Absent a workable solution, we're going to be moving=20 > Apache into the non-compliant category if this is a=20 > MUST-level requirement. I think there are many workable solutions over standard filesystems for = this problem. dan >=20 > -wsv >=20 >=20 > On Dec 19, 2005, at 6:16 PM, Jim Whitehead wrote: >=20 > > If I'm a client that has an exclusive write lock, then if I PUT to=20 > > that resource, the stored entity should not be modified by anyone=20 > > other than the server. In this case, which is the most=20 > common one for=20 > > DAV-based editing, it's still very useful for the client to receive=20 > > the final etag value in the response to PUT. Why? It saves=20 > the client=20 > > from having to poll an uncertain number of times before it receives=20 > > the final, stable etag value. > > > > I still feel that R2 is required. >=20 >=20 >=20 From w3c-dist-auth-request@frink.w3.org Tue Dec 20 00:32:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoa6Y-0000Hd-8q for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 00:32:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11571 for <webdav-archive@lists.ietf.org>; Tue, 20 Dec 2005 00:31:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eoa4z-0001JW-3M for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 05:30:29 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eoa4s-0001Iv-7Z for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 05:30:22 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by aji.w3.org with esmtp (Exim 4.50) id 1Eoa4f-0007EV-F7 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 05:30:21 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Dec 2005 21:30:05 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBK5U4Qg014008; Mon, 19 Dec 2005 21:30:04 -0800 (PST) Received: from 10.21.144.68 ([10.21.144.68]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Dec 2005 05:30:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 19 Dec 2005 21:30:12 -0800 From: Cullen Jennings <fluffy@cisco.com> To: Julian Reschke <julian.reschke@gmx.de> CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Lisa Dusseault <lisa@osafoundation.org>, WebDav <w3c-dist-auth@w3.org> Message-ID: <BFCCD6E4.661D5%fluffy@cisco.com> Thread-Topic: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings Thread-Index: AcYFJnLTsZau1XEZEdqFpgARJEEJ/A== In-Reply-To: <43A1318F.3060503@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: aji.w3.org 1Eoa4f-0007EV-F7 3ebad696039df90e5d9750922fe472e9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/BFCCD6E4.661D5%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11235 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1Eoa4z-0001JW-3M@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 05:30:29 +0000 Content-Transfer-Encoding: 7bit On 12/15/05 1:04 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > Cullen Jennings wrote: >> >> Perhaps you could explain how one gets multiple bindings when not using >> an XML database? > > As Geoff, I really don't see what this would have to do with an XML > database. > > You can get multiple bindings if > > - you support BIND and/or > - if your underlying store supports something similar, such as a > filesystem supporting hard links > > Best regards, Julian Right, no big deal but it seems like a XML database that say had a regular expression for mapping one URI to another could easily get multiple bindings to one resource. The questions was could you use the DB lock mechanism (or for that matter a files system lock) to implement DAV locks. Julian said this would not be compliant with 2516 which I believe but I don't yet understand why it would not be. Now Lisa proposed a model for locking slightly different than GULP which would, by my understanding, would allow an implementation like GULP but would also allow implementation like the one I just described to also be compliant. For a server that supported BIND, it would probably have to be a GULP like implementation. Now I have no idea what is best, but I am poking at the form of the argument. You are arguing the 4 servers tested are compliant with GULP therefore do GULP. However the 4 servers, by my understanding (happy to be corrected if I am wrong here), also are compliant with what Lisa proposed given GULP is a subset of it. I strongly suspect that there are some DAV like servers out there that try to use file and data base locking mechanism to do locks - I don't know if they are 2516 compliant or not. I also suspect there are some servers that do run regular expression on URL to create multiple bindings to files on a file system and DELETE will remove both all at the same time. Again, don't know if this should be legal for a server or not but practically it does not make much difference for the client so servers will continue to do it. I like the idea of looking at what is running code today to determine how to move forward. (I won't ask about if those 4 servers you tested can store gif files or not :-) I'd like to see this discussion have more on what the model should and and why. So far I can summarize it as: 1) gulp would probably work 2) an alternative model might work 3) some people prefer 1 some 2 4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is good 5) I'm not seeing the insights that help people understand why one model or another would be better or worse. I really like the posts Dan and Jim where having on the meaning and implications of etags on PUT. I could read it and understand why one might want or not want various options. From w3c-dist-auth-request@frink.w3.org Tue Dec 20 00:44:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoaI5-0002mR-JT for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 00:44:02 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12682 for <webdav-archive@lists.ietf.org>; Tue, 20 Dec 2005 00:42:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoaGD-000465-DL for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 05:42:05 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoaG5-00044k-N3; Tue, 20 Dec 2005 05:41:58 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by aji.w3.org with esmtp (Exim 4.50) id 1EoaFt-0003HM-RF; Tue, 20 Dec 2005 05:41:56 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Dec 2005 21:41:44 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBK5fcMe000545; Mon, 19 Dec 2005 21:41:38 -0800 (PST) Received: from 10.21.144.68 ([10.21.144.68]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Dec 2005 05:41:38 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 19 Dec 2005 21:41:46 -0800 From: Cullen Jennings <fluffy@cisco.com> To: Jim Whitehead <ejw@soe.ucsc.edu>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com> CC: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org>, <w3c-dist-auth-request@w3.org> Message-ID: <BFCCD99A.661DA%fluffy@cisco.com> Thread-Topic: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed Thread-Index: AcYFKBB7TwdMmnEbEdqFpgARJEEJ/A== In-Reply-To: <A1A8EE58-3E69-4664-928C-DE66E608A39F@cs.ucsc.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3217873307_19007719" Received-SPF: pass (aji.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1EoaFt-0003HM-RF 8be1a8d57bfb568d7d49dc66da4c61bc X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/BFCCD99A.661DA%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/11236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Resent-Message-Id: <E1EoaGD-000465-DL@frink.w3.org> Resent-Date: Tue, 20 Dec 2005 05:42:05 +0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3217873307_19007719 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable My recollection was that BIND did NOT pass WGLC with no open issues. (There may have been no new issues but that is quite a different thing). I'm could certainly be wrong on this and would be happy to be shown I was wrong. It may be that all the open issues are resolved in bis. If the WG does not come to agreement on BIND, I would certainly view an individual submission of this work as an end run around the WG. We have had this discussion before on the topic of bis and Ted and I have both commente= d on our feelings about the idea that if the WG can't agree we will just submit some draft anyways. I do believe that bis and BIND can both be completed. On 12/19/05 9:28 AM, "Jim Whitehead" <ejw@soe.ucsc.edu> wrote: > I agree with this as well. >=20 > - Jim > On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote: >=20 >>=20 >> Sounds good to me. >> =20 >> Cheers,=20 >> Geoff=20 >> =20 >> Julian wrote on 12/17/2005 06:40:38 AM: >> =20 >>> >=20 >>> > Hi. >>> >=20 >>> > With the inclusion of the proposed text below in RFC2518bius, we'd b= e >>> > closing an issue that was raised in spring while discussing BIND. In= the >>> > subsequent discussion (summarized in >>> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs- >>> > properties-latest.html>) >>> > we found that it's not a problem specific to BIND at all, because it >>> > applies to any operation that creates new resources or moves them. >>> >=20 >>> > Since then BIND has passed (a third!) working group last call, with = no >>> > new issues raised. So here's my current understanding of where we st= and >>> > with BIND. Feedback appreciated. >>> >=20 >>> > 1) BIND is finished, however it's currently on hold because we're bu= sy >>> > with RFC2518bis. >>> >=20 >>> > 2) Should the working group manage to complete RFC2518bis as planned= , we >>> > can slightly revise the current BIND draft, taking out stuff that's = not >>> > needed anymore, namely >>> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. >>> > html#rfc.section.1.3> >>> > ("preconditions and postconditions"), parts of >>> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. >>> > html#rfc.section.2.4> >>> > (discussion of broken DELETE semantics of RFC2518bis), and parts of >>> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12. >>> > html#rfc.section.8.2> >>> > (introduction of "DAV" request header). As these changes would be pu= rely >>> > editorial, I'll assume we wouldn't want to do another WGLC. >>> >=20 >>> > 3) On the other hand, should the working group fail to finish >>> > RFC2518bis, we'll submit BIND as is. >>> >=20 >>> >=20 >>> > Best regards, Julian >>> >=20 >>> >=20 >>> >=20 >>> >=20 >>> >=20 >>> >=20 >>> > bugzilla@soe.ucsc.edu wrote: >>>> > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D85 >>>> > >=20 >>>> > >=20 >>>> > >=20 >>>> > >=20 >>>> > >=20 >>>> > > ------- Additional Comments From julian.reschke@greenbytes.de =A0 >>> > 2005-12-17 03:25 ------- >>>> > > OK, I believe I have completed my changes. As usual, see them in >>>> context at >>>> > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis= - >>> > latest.html#rfc.issue.bz085> >>>> > >=20 >>>> > >=20 >>>> > > In Section 8, NEW: >>>> > >=20 >>>> > > =A08.1.6 =A0Impacts of Namespace Operations on Cacheability >>>> > > =A0 >>>> > > =A0 =A0 Note that the HTTP response headers "Etag" and "Last-Modified= " (see >>>> > > =A0 =A0 [RFC2616], Sections 14.19 and 14.29) are defined per URL (not= per >>>> > > =A0 =A0 resource), and are used by clients for caching. =A0Therefore se= rvers >>>> > > =A0 =A0 must ensure that executing any operation that affects the URL >>>> > > =A0 =A0 namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does pre= serve >>>> > > =A0 =A0 their semantics, in particular: >>>> > > =A0 >>>> > > =A0 =A0 o =A0For any given URL, the "Last-Modified" value must incremen= t >>>> every >>>> > > =A0 =A0 =A0 =A0time the representation returned upon GET changes (within = the >>>> > > =A0 =A0 =A0 =A0limits of timestamp resolution). >>>> > > =A0 >>>> > > =A0 =A0 o =A0For any given URL, no "ETag" value must ever be re-used fo= r >>>> > > =A0 =A0 =A0 =A0different representations returned by GET. >>>> > > =A0 >>>> > > =A0 =A0 In practice this means that servers >>>> > > =A0 >>>> > > =A0 =A0 o =A0may have to increment "Last-Modified" timestamps for every >>>> > > =A0 =A0 =A0 =A0resource inside the destination namespace of a namespace >>>> > > =A0 =A0 =A0 =A0operation, and >>>> > > =A0 >>>> > > =A0 =A0 o =A0similarily, may have to re-assign "ETag" values for these >>>> > > =A0 =A0 =A0 =A0resources (unless the server allocates entity tags in a wa= y so >>>> > > =A0 =A0 =A0 =A0that they are unique across the whole URL namespace manage= d by the >>>> > > =A0 =A0 =A0 =A0server). >>>> > > =A0 >>>> > > =A0 =A0 Note that these considerations also apply to specific use cas= es, such >>>> > > =A0 =A0 as using PUT creating a new resource at a URL that has been m= apped >>>> > > =A0 =A0 before, but has been deleted since then. >>>> > > =A0 >>>> > > =A0 =A0 Finally, WebDAV properties (such as DAV:getetag and DAV: >>>> > > =A0 =A0 getlastmodified) that inherit their semantics from HTTP heade= rs must >>>> > > =A0 =A0 behave accordingly. >>>> > >=20 >>>> > > In the description for DAV:getetag: >>>> > >=20 >>>> > > OLD: >>>> > >=20 >>>> > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent on the= >>>> final >>>> > > =A0 =A0 =A0 =A0state of the destination resource, not the value of the >>>> property >>>> > > =A0 =A0 =A0 =A0on the source resource. >>>> > >=20 >>>> > > NEW: >>>> > >=20 >>>> > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent on the= >>>> final >>>> > > =A0 =A0 =A0 =A0state of the destination resource, not the value of the >>>> property >>>> > > =A0 =A0 =A0 =A0on the source resource. =A0Also note the cacheability >>>> considerations >>>> > > =A0 =A0 =A0 =A0in Section 8.1.6. >>>> > >=20 >>>> > > In the description for DAV:getlastmodified: >>>> > >=20 >>>> > > Section 14., para. 56: >>>> > > OLD: >>>> > >=20 >>>> > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent on the= last >>>> > > =A0 =A0 =A0 =A0modified date of the destination resource, not the value o= f the >>>> > > =A0 =A0 =A0 =A0property on the source resource. =A0Note that some server >>>> > > =A0 =A0 =A0 =A0implementations use the file system date modified value fo= r the >>>> > > =A0 =A0 =A0 =A0DAV:getlastmodified value, and this is preserved in a MOVE= even >>>> > > =A0 =A0 =A0 =A0when the HTTP Last-Modified value SHOULD change. =A0Thus, cl= ients >>>> > > =A0 =A0 =A0 =A0cannot rely on this value for caching and SHOULD use ETags= . >>>> > >=20 >>>> > > NEW: >>>> > >=20 >>>> > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent on the= last >>>> > > =A0 =A0 =A0 =A0modified date of the destination resource, not the value o= f the >>>> > > =A0 =A0 =A0 =A0property on the source resource. =A0Also note the cacheabili= ty >>>> > > =A0 =A0 =A0 =A0considerations in Section 8.1.6. >>>> > >=20 >>>> > > Note that tis particular change removes language that contradicts >>> > RFC2616 (we >>>> > > can't simply tell people that RFC2616 doesn't count anymore, at l= east not >>>> > > without strong WG consensus). >>> >=20 >> =20 >=20 >=20 --B_3217873307_19007719 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: BIND, was: [Bug 85] clarification of live property behaviour vs = namespace  ops needed
My recollection was that BIND did NOT pass WGLC with no open issues. (There= may have been no new issues but that is quite a different thing). I'm could= certainly be wrong on this and would be happy to be shown I was wrong. It m= ay be that all the open issues are resolved in bis.

If the WG does not come to agreement on BIND, I would certainly view an ind= ividual submission of this work as an end run around the WG. We have had thi= s discussion before on the topic of bis and Ted and I have both commented on= our feelings about the idea that if the WG can't agree we will just submit = some draft anyways.

I do believe that bis and BIND can both be completed.



On 12/19/05 9:28 AM, "Jim Whitehead" <ejw@soe.ucsc.edu> wro= te:

I agree with this as well.

- Jim
On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote:


Sounds good to me.
 
Cheers,
Geoff
 
Julian wrote on 12/17/2005 06:40:38 AM:
 
 >
 > Hi.
 >
 > With the inclusion of the proposed text below in RFC2518bius, we= 'd be
 > closing an issue that was raised in spring while discussing BIND= . In the
 > subsequent discussion (summarized in
 > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-name= space-vs-
 > properties-latest.html>)
 > we found that it's not a problem specific to BIND at all, becaus= e it
 > applies to any operation that creates new resources or moves the= m.
 >
 > Since then BIND has passed (a third!) working group last call, w= ith no
 > new issues raised. So here's my current understanding of where w= e stand
 > with BIND. Feedback appreciated.
 >
 > 1) BIND is finished, however it's currently on hold because we'r= e busy
 > with RFC2518bis.
 >
 > 2) Should the working group manage to complete RFC2518bis as pla= nned, we
 > can slightly revise the current BIND draft, taking out stuff tha= t's not
 > needed anymore, namely
 > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.  > html#rfc.section.1.3>
 > ("preconditions and postconditions"), parts of
 > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.  > html#rfc.section.2.4>
 > (discussion of broken DELETE semantics of RFC2518bis), and parts= of
 > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.  > html#rfc.section.8.2>
 > (introduction of "DAV" request header). As these chang= es would be purely
 > editorial, I'll assume we wouldn't want to do another WGLC.
 >
 > 3) On the other hand, should the working group fail to finish  > RFC2518bis, we'll submit BIND as is.
 >
 >
 > Best regards, Julian
 >
 >
 >
 >
 >
 >
 > bugzilla@soe.ucsc.edu wrote:
 > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D85
 > >
 > >
 > >
 > >
 > >
 > > ------- Additional Comments From julian.reschke@greenbytes.= de =A0
 > 2005-12-17 03:25 -------
 > > OK, I believe I have completed my changes. As usual, see th= em in context at
 > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-r= fc2518bis-
 > latest.html#rfc.issue.bz085>
 > >
 > >
 > > In Section 8, NEW:
 > >
 > > =A08.1.6 =A0Impacts of Namespace Operations on Cacheability
 > > =A0
 > > =A0 =A0 Note that the HTTP response headers "Etag" an= d "Last-Modified" (see
 > > =A0 =A0 [RFC2616], Sections 14.19 and 14.29) are defined per UR= L (not per
 > > =A0 =A0 resource), and are used by clients for caching. =A0Theref= ore servers
 > > =A0 =A0 must ensure that executing any operation that affects t= he URL
 > > =A0 =A0 namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) do= es preserve
 > > =A0 =A0 their semantics, in particular:
 > > =A0
 > > =A0 =A0 o =A0For any given URL, the "Last-Modified" val= ue must increment every
 > > =A0 =A0 =A0 =A0time the representation returned upon GET changes (w= ithin the
 > > =A0 =A0 =A0 =A0limits of timestamp resolution).
 > > =A0
 > > =A0 =A0 o =A0For any given URL, no "ETag" value must ev= er be re-used for
 > > =A0 =A0 =A0 =A0different representations returned by GET.
 > > =A0
 > > =A0 =A0 In practice this means that servers
 > > =A0
 > > =A0 =A0 o =A0may have to increment "Last-Modified" time= stamps for every
 > > =A0 =A0 =A0 =A0resource inside the destination namespace of a names= pace
 > > =A0 =A0 =A0 =A0operation, and
 > > =A0
 > > =A0 =A0 o =A0similarily, may have to re-assign "ETag" v= alues for these
 > > =A0 =A0 =A0 =A0resources (unless the server allocates entity tags i= n a way so
 > > =A0 =A0 =A0 =A0that they are unique across the whole URL namespace = managed by the
 > > =A0 =A0 =A0 =A0server).
 > > =A0
 > > =A0 =A0 Note that these considerations also apply to specific u= se cases, such
 > > =A0 =A0 as using PUT creating a new resource at a URL that has = been mapped
 > > =A0 =A0 before, but has been deleted since then.
 > > =A0
 > > =A0 =A0 Finally, WebDAV properties (such as DAV:getetag and DAV= :
 > > =A0 =A0 getlastmodified) that inherit their semantics from HTTP= headers must
 > > =A0 =A0 behave accordingly.
 > >
 > > In the description for DAV:getetag:
 > >
 > > OLD:
 > >
 > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent = on the final
 > > =A0 =A0 =A0 =A0state of the destination resource, not the value of = the property
 > > =A0 =A0 =A0 =A0on the source resource.
 > >
 > > NEW:
 > >
 > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent = on the final
 > > =A0 =A0 =A0 =A0state of the destination resource, not the value of = the property
 > > =A0 =A0 =A0 =A0on the source resource. =A0Also note the cacheability = considerations
 > > =A0 =A0 =A0 =A0in Section 8.1.6.
 > >
 > > In the description for DAV:getlastmodified:
 > >
 > > Section 14., para. 56:
 > > OLD:
 > >
 > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent = on the last
 > > =A0 =A0 =A0 =A0modified date of the destination resource, not the v= alue of the
 > > =A0 =A0 =A0 =A0property on the source resource. =A0Note that some ser= ver
 > > =A0 =A0 =A0 =A0implementations use the file system date modified va= lue for the
 > > =A0 =A0 =A0 =A0DAV:getlastmodified value, and this is preserved in = a MOVE even
 > > =A0 =A0 =A0 =A0when the HTTP Last-Modified value SHOULD change. =A0Th= us, clients
 > > =A0 =A0 =A0 =A0cannot rely on this value for caching and SHOULD use= ETags.
 > >
 > > NEW:
 > >
 > > =A0 =A0 COPY/MOVE behaviour: =A0This property value is dependent = on the last
 > > =A0 =A0 =A0 =A0modified date of the destination resource, not the v= alue of the
 > > =A0 =A0 =A0 =A0property on the source resource. =A0Also note the cach= eability
 > > =A0 =A0 =A0 =A0considerations in Section 8.1.6.
 > >
 > > Note that tis particular change removes language that contr= adicts
 > RFC2616 (we
 > > can't simply tell people that RFC2616 doesn't count anymore= , at least not
 > > without strong WG consensus).
 >
 



 --B_3217873307_19007719-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 03:06:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EocW7-0008Pw-HY for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 03:06:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25078 for ; Tue, 20 Dec 2005 03:05:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EocTx-0001e4-C1 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 08:04:25 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EocTm-0001dR-PK for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 08:04:14 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EocRt-00088K-TP for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 08:04:13 +0000 Received: (qmail invoked by alias); 20 Dec 2005 08:02:14 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp029) with SMTP; 20 Dec 2005 09:02:14 +0100 X-Authenticated: #1915285 Message-ID: <43A7BA2C.2080503@gmx.de> Date: Tue, 20 Dec 2005 09:00:44 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EocRt-00088K-TP e0787ed7a35cf4c756f2b61291b7e2a1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7BA2C.2080503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11237 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 08:04:25 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Ok, so what is your advice to client implementers? Do you want to specify > something they can count on working? XML works? 7 bit ascii works? XHTML > works? Getting a 415 might tell you the end user why it failed (though > probably not given most client software) but it is not going to make it > work. > > If people are comfortable with there is no guarantee that even the most > trivial things will interoperate with this protocol, I'm not pushing it. I'm > just a checking that I correctly understand this as I find it slightly > surprising. Please do not forget telling people what the alternative is. For instance, that you can't use a Microsoft WebFolder client for uploading to or namespace operations on your server, just because it happens to be a special type of server. For instance, would you rule out flickr.com allowing renaming (MOVE), metadata administration (PROPFIND/PROPPATCH) or uploading (PUT) using an off-the-shelf WebDAV client, just because it won't be able to work with anything except image files? That's what making support for arbitrary content required would mean, and server implementors would only have the choice to remove WebDAV support, or to break the spec. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 03:08:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EocXX-0000Gf-OB for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 03:08:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25169 for ; Tue, 20 Dec 2005 03:07:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EocW4-00028e-5U for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 08:06:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EocW1-000281-Kd for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 08:06:33 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EocUr-0000sO-Ih for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 08:06:31 +0000 Received: (qmail invoked by alias); 20 Dec 2005 08:05:19 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp011) with SMTP; 20 Dec 2005 09:05:19 +0100 X-Authenticated: #1915285 Message-ID: <43A7BAEB.9010404@gmx.de> Date: Tue, 20 Dec 2005 09:03:55 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead CC: Cullen Jennings , WebDav WG References: <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EocUr-0000sO-Ih c9c56e73024b971a2bfc75bfe6a931e0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7BAEB.9010404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11238 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 08:06:36 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Julian, > > Thanks for making this more clear -- you're right, there is a > significant issue here. > >> The question here is whether an ETag returned upon PUT is for the >> entity the client sent (1), or for the entity the server would send >> upon a subsequent GET (2). >> >> There are cases where both will not be the same, so this needs to be >> clarified. In case of (2), a client will need a subsequent GET if it's >> planning to use the ETag for subsequent GET/Range requests. >> > > I think option #2 is the best one here (the Etag returned by PUT is the > one a subsequent GET would retrieve). So given the fact people like Ted and myself got this wrong, and that people on the HTTP WG seem to agree this area is underspecified, what do we do? -1 on putting in new requirements into the spec that may be incompatible with RFC2616. +1 on getting that clarified in RFC2616's errata. Volunteers? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 03:09:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EocYb-0000ZP-EJ for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 03:09:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25204 for ; Tue, 20 Dec 2005 03:08:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EocXD-0002Ke-Dk for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 08:07:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EocX7-0002JT-Pl for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 08:07:41 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EocX2-00049U-Vg for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 08:07:40 +0000 Received: (qmail invoked by alias); 20 Dec 2005 08:07:31 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp038) with SMTP; 20 Dec 2005 09:07:31 +0100 X-Authenticated: #1915285 Message-ID: <43A7BB6F.9020409@gmx.de> Date: Tue, 20 Dec 2005 09:06:07 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jim Whitehead CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , WebDav WG References: <43A704DE.5070407@gmx.de> <942948C5-CCBE-459E-A038-8C966E334840@cs.ucsc.edu> <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> In-Reply-To: <4EA320E4-E8AA-474E-9EC6-D5815ED45754@cs.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EocX2-00049U-Vg 76da39c12544699167e925cd9286b0c0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7BB6F.9020409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11239 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 08:07:47 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > If I'm a client that has an exclusive write lock, then if I PUT to that > resource, the stored entity should not be modified by anyone other than > the server. In this case, which is the most common one for DAV-based > editing, it's still very useful for the client to receive the final etag > value in the response to PUT. Why? It saves the client from having to > poll an uncertain number of times before it receives the final, stable > etag value. Well. If the client has the lock, why would it need the ETag in the first place? > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 03:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodCP-0000Sc-Qe for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 03:50:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28554 for ; Tue, 20 Dec 2005 03:49:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EodAl-00037t-IR for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 08:48:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EodAW-000353-Lz for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 08:48:24 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EodAT-00029a-6J for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 08:48:24 +0000 Received: (qmail invoked by alias); 20 Dec 2005 08:48:19 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp037) with SMTP; 20 Dec 2005 09:48:19 +0100 X-Authenticated: #1915285 Message-ID: <43A7C4FC.6020209@gmx.de> Date: Tue, 20 Dec 2005 09:46:52 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Jim Whitehead , WebDav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EodAT-00029a-6J 219fc4b7241259f0c827330154aae222 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7C4FC.6020209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11240 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 08:48:39 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: >> The question then is how one would implement than on a >> server using a filesystem as the backing store, which is a >> *very* common case (Apache). The information have from the >> filesystem doesn't seem to give us enough data without doing >> something like checksumming the file. The performance >> implications of that solution are rather drastic. > > First of all, there are many filesystems in the world that accurate to way more than 1 millisecond, so I don't think a general statement such as "the filesystem doesn't seem to give us enough data" is really applicable. Depends on what the target platform is. Apache is built on top of APR, (Apache Portable Runtime) as I recall, and that API may not have a guarantee of a higher timer resolution. What would be your proposal to the Apache guys how to handle that? > Second, even in filesystems with millisecond resolutions, all the filesystem has to do is support exclusive write-locking and you can build a compliant server. The server must simply keep the file locked long enough to avoid the milllisecond window and then set the time back to the write time in order to ensure that any interference is noticeable. You mean "second" resolution, right? Two problems here: 1) Doing that may not be acceptable for mass uploads, where millions of documents need to be uploaded (don't tell me this isn't a use case...). 2) Even then, it's not that simple. ETag and Last-Modified also have to be adjusted after COPY and notably MOVE (!). But it seems that there's a simple way to fix this (for Apache): should a client require a strong ETag upon PUT, it could make that explicit in the request (new header?), so that the server can just special-case this, and do what's needed to ensure the ETag is stable. Wilfredo? > I don't have any problem with a standard that can't be implemented in the simplest possible way against the weakest possible resources. All we are saying is that, if you really have a filesystem that allows multiple writers to interfere with one another undetectably, then you can't build a compliant WebDAV server against that filesystem. And that's just a fact: the server certainly can't guarantee anything without support from the filesystem. I disagree with the statement that this kind of server is non-compliant. Are you saying that Apache/moddav is non-compliant? >> Absent a workable solution, we're going to be moving >> Apache into the non-compliant category if this is a >> MUST-level requirement. > > I think there are many workable solutions over standard filesystems for this problem. This discussion isn't new. As a matter of fact, it started at least two years ago. As of now, nothing in Apache/moddav has changed. I take that as indication that changing the server may not be as trivial as some people think. So, Dan, can you make a concrete proposal how to change Apache/moddav? > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 04:10:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodW4-000477-Ux for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 04:10:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00653 for ; Tue, 20 Dec 2005 04:09:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EodUH-0007I1-6b for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 09:08:49 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EodU5-0007GM-Pe for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 09:08:38 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EodTx-0001ct-Nw for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 09:08:36 +0000 Received: (qmail invoked by alias); 20 Dec 2005 09:08:23 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp038) with SMTP; 20 Dec 2005 10:08:23 +0100 X-Authenticated: #1915285 Message-ID: <43A7C9AC.7080404@gmx.de> Date: Tue, 20 Dec 2005 10:06:52 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Cullen Jennings CC: Geoffrey M Clemm , Lisa Dusseault , WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EodTx-0001ct-Nw b298f4de7cbbc4cfaa28d81c1cdae9f7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A7C9AC.7080404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11241 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 09:08:49 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Right, no big deal but it seems like a XML database that say had a regular > expression for mapping one URI to another could easily get multiple bindings > to one resource. > > The questions was could you use the DB lock mechanism (or for that matter a > files system lock) to implement DAV locks. Julian said this would not be > compliant with 2516 which I believe but I don't yet understand why it would > not be. If the server would use just the DB lock (on the resource), and nothing else, it wouldn't be compliant to several URL related locking requirements, namely that you can't MOVE a parent without providing the lock token (thus the URL of the locked resource is protected from getting changed), and the lock to disappear when the resource itself is moved. Both of these require the server to store the URL to what the lock request was sent with the lock. > Now Lisa proposed a model for locking slightly different than GULP which > would, by my understanding, would allow an implementation like GULP but > would also allow implementation like the one I just described to also be > compliant. For a server that supported BIND, it would probably have to be a > GULP like implementation. I'll assume you're referring to ? Which reads: LD> One could imagine the lock applying to the resource and to all its LD> bindings, considering the bindings to be part of the state of the LD> resource. If I recall, I think this is the model I'd always assumed LD> until GULP. With this model, if A and B are bindings to a resource, LD> and a LOCK token to A is successful, then for the duration of the lock LD> the token is required to change either A or B. This implies that a binding is part of the state of the resource, and I think both RFC2518 and RFC3744 are very clear that it's not. Namely, in : 'A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners.' So this is clearly different from what RFC2518 says, so it's not a proposed model, but a change request. LD> In today's server implementations, does a LOCK of depth 0 on a LD> collection prevent MOVE from being used to change resource names inside LD> the collection? This is another possible case that might be different LD> depending on whether bindings were considered part of the collection, LD> part of the resource state, or both. Checked and confirmed that servers indeed implement RFC2518 as written. I'm not sure why we're still arguing this. > Now I have no idea what is best, but I am poking at the form of the > argument. You are arguing the 4 servers tested are compliant with GULP > therefore do GULP. However the 4 servers, by my understanding (happy to be > corrected if I am wrong here), also are compliant with what Lisa proposed > given GULP is a subset of it. GULP not only describes the locking model in RFC2518, it's also implemented. Lisa's proposal describes something else. It's as simple as that. > I strongly suspect that there are some DAV like servers out there that try > to use file and data base locking mechanism to do locks - I don't know if > they are 2516 compliant or not. I also suspect there are some servers that They aren't, unless they keep the locked URL somewhere as well (of course they won't need to do that if there's only one, but then cnecking it on every namespace operation may get expensive). > do run regular expression on URL to create multiple bindings to files on a > file system and DELETE will remove both all at the same time. Again, don't > know if this should be legal for a server or not but practically it does not > make much difference for the client so servers will continue to do it. > > I like the idea of looking at what is running code today to determine how to > move forward. (I won't ask about if those 4 servers you tested can store gif > files or not :-) At least one of them may not be able to do so for some URLs. > I'd like to see this discussion have more on what the model should and and > why. So far I can summarize it as: > 1) gulp would probably work > 2) an alternative model might work > 3) some people prefer 1 some 2 > 4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is > good > 5) I'm not seeing the insights that help people understand why one model or > another would be better or worse. So far, I haven't seen a model other than GULP that indeed describes what RFC2518 says and what servers implement. Making a binding part of the state of the resource instead of the collection containing it is a non-starter, sorry. > I really like the posts Dan and Jim where having on the meaning and > implications of etags on PUT. I could read it and understand why one might > want or not want various options. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 04:16:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodbU-0005j0-V9 for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 04:16:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01212 for ; Tue, 20 Dec 2005 04:15:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EodaA-0008Kt-Pc for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 09:14:54 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eoda3-0008K2-Mq for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 09:14:47 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EodZv-0003Sv-T8 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 09:14:47 +0000 Received: (qmail invoked by alias); 20 Dec 2005 09:13:50 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp014) with SMTP; 20 Dec 2005 10:13:50 +0100 X-Authenticated: #1915285 Message-ID: <43A7CAF8.4050206@gmx.de> Date: Tue, 20 Dec 2005 10:12:24 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Geoffrey M Clemm CC: w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EodZv-0003Sv-T8 ed765f906fed39380bb676e8e92e0111 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7CAF8.4050206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11242 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 09:14:54 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > ... > So unless we are going to disallow servers from modifying the > content stored from a PUT (note that our server does not do this, > so I am speaking as a neutral party here :-), we pretty much > have to have PUT return the entity tag of the content that was > PUT, not what would be returned by the GET. > ... As a meta comment: I note here's another experienced person who interprets ETag-upon-PUT differently than people on the HTTP mailing list. *If* RFC2518bis wants to make normative statements about ETags in PUT, it MUST resolve this issue, and in a way that won't conflict with future revisions of RFC2616. At this point I firmly believe that we can't deliver RFC2518bis in time, unless we drop all changes introducing new requirements that are non-controversial. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 04:20:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodfM-00070d-La for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 04:20:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01517 for ; Tue, 20 Dec 2005 04:19:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eoddv-0002U3-Au for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 09:18:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eoddm-0002TD-GK for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 09:18:38 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Eoddf-0007fd-Eu for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 09:18:38 +0000 Received: (qmail invoked by alias); 20 Dec 2005 09:18:29 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp020) with SMTP; 20 Dec 2005 10:18:29 +0100 X-Authenticated: #1915285 Message-ID: <43A7CC10.6000502@gmx.de> Date: Tue, 20 Dec 2005 10:17:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: Geoffrey M Clemm , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Eoddf-0007fd-Eu fd435d9ffec67a51c90e0631c8652e26 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A7CC10.6000502@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11243 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 09:18:47 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: > ... > In no case does a client ever assume that "the text it sent with the PUT > is what would be retrieved by the GET." That's not what the etag is > for. The etag is to reassure the client that the value on the server > *has not changed since the PUT completed*. No guarantees are issued > that the value doesn't change as part of the PUT; that would be a part > of the PUT semantics for that server and are outside the scope of > WebDAV. > ... Thanks, Dan :-) So let's look at what clients are interested in again: - they want to avoid fetching an ETag after PUT, - in some cases, they want to be able to find out whether the server stored exactly what they sent, - if they interleave PUT and PROPPATCH, they want their ETags to continue to work. I believe all of these things can be accomplish by protocol extensions, and I'll be happy to spec them out. On the other hand, I don't think it would be a good idea to rush them into RFC2518bis, which was supposed to be finished around this time of year (if I may remember). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 04:23:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eodia-0007Zr-5N for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 04:23:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01666 for ; Tue, 20 Dec 2005 04:22:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eodgz-0003IT-7v for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 09:21:57 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eodgt-0003GD-5m; Tue, 20 Dec 2005 09:21:51 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by aji.w3.org with esmtp (Exim 4.50) id 1Eodgg-0008LN-4N; Tue, 20 Dec 2005 09:21:50 +0000 Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 3A03F349BA; Tue, 20 Dec 2005 10:26:26 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , Geoffrey M Clemm , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org From: Stefan Eissing Date: Tue, 20 Dec 2005 10:21:32 +0100 To: Jim Whitehead X-Mailer: Apple Mail (2.623) Received-SPF: none (aji.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eodgg-0008LN-4N 86eb4cfabb677d0e121e35d95eb59a89 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/fc799272b5415cdcbba42ac5ec7f7a1b@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11244 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 09:21:57 +0000 Content-Transfer-Encoding: 7bit Let's hold hands. Am 19.12.2005 um 18:28 schrieb Jim Whitehead: > I agree with this as well. > > - Jim > On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote: > >> >> Sounds good to me. >> >> Cheers, >> Geoff >> >> Julian wrote on 12/17/2005 06:40:38 AM: >> >> > >> > Hi. >> > >> > With the inclusion of the proposed text below in RFC2518bius, we'd >> be >> > closing an issue that was raised in spring while discussing BIND. >> In the >> > subsequent discussion (summarized in >> > >> > > properties-latest.html>) >> > we found that it's not a problem specific to BIND at all, because >> it >> > applies to any operation that creates new resources or moves them. >> > >> > Since then BIND has passed (a third!) working group last call, >> with no >> > new issues raised. So here's my current understanding of where we >> stand >> > with BIND. Feedback appreciated. >> > >> > 1) BIND is finished, however it's currently on hold because we're >> busy >> > with RFC2518bis. >> > >> > 2) Should the working group manage to complete RFC2518bis as >> planned, we >> > can slightly revise the current BIND draft, taking out stuff >> that's not >> > needed anymore, namely >> > > > html#rfc.section.1.3> >> > ("preconditions and postconditions"), parts of >> > > > html#rfc.section.2.4> >> > (discussion of broken DELETE semantics of RFC2518bis), and parts of >> > > > html#rfc.section.8.2> >> > (introduction of "DAV" request header). As these changes would be >> purely >> > editorial, I'll assume we wouldn't want to do another WGLC. >> > >> > 3) On the other hand, should the working group fail to finish >> > RFC2518bis, we'll submit BIND as is. >> > >> > >> > Best regards, Julian >> > >> > >> > >> > >> > >> > >> > bugzilla@soe.ucsc.edu wrote: >> > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 >> > > >> > > >> > > >> > > >> > > >> > > ------- Additional Comments From julian.reschke@greenbytes.de >> > 2005-12-17 03:25 ------- >> > > OK, I believe I have completed my changes. As usual, see them in >> context at >> > > >> > > latest.html#rfc.issue.bz085> >> > > >> > > >> > > In Section 8, NEW: >> > > >> > > 8.1.6 Impacts of Namespace Operations on Cacheability >> > > >> > > Note that the HTTP response headers "Etag" and "Last-Modified" >> (see >> > > [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per >> > > resource), and are used by clients for caching. Therefore servers >> > > must ensure that executing any operation that affects the URL >> > > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does >> preserve >> > > their semantics, in particular: >> > > >> > > o For any given URL, the "Last-Modified" value must increment >> every >> > > time the representation returned upon GET changes (within the >> > > limits of timestamp resolution). >> > > >> > > o For any given URL, no "ETag" value must ever be re-used for >> > > different representations returned by GET. >> > > >> > > In practice this means that servers >> > > >> > > o may have to increment "Last-Modified" timestamps for every >> > > resource inside the destination namespace of a namespace >> > > operation, and >> > > >> > > o similarily, may have to re-assign "ETag" values for these >> > > resources (unless the server allocates entity tags in a way so >> > > that they are unique across the whole URL namespace managed by >> the >> > > server). >> > > >> > > Note that these considerations also apply to specific use cases, >> such >> > > as using PUT creating a new resource at a URL that has been >> mapped >> > > before, but has been deleted since then. >> > > >> > > Finally, WebDAV properties (such as DAV:getetag and DAV: >> > > getlastmodified) that inherit their semantics from HTTP headers >> must >> > > behave accordingly. >> > > >> > > In the description for DAV:getetag: >> > > >> > > OLD: >> > > >> > > COPY/MOVE behaviour: This property value is dependent on the >> final >> > > state of the destination resource, not the value of the property >> > > on the source resource. >> > > >> > > NEW: >> > > >> > > COPY/MOVE behaviour: This property value is dependent on the >> final >> > > state of the destination resource, not the value of the property >> > > on the source resource. Also note the cacheability considerations >> > > in Section 8.1.6. >> > > >> > > In the description for DAV:getlastmodified: >> > > >> > > Section 14., para. 56: >> > > OLD: >> > > >> > > COPY/MOVE behaviour: This property value is dependent on the last >> > > modified date of the destination resource, not the value of the >> > > property on the source resource. Note that some server >> > > implementations use the file system date modified value for the >> > > DAV:getlastmodified value, and this is preserved in a MOVE even >> > > when the HTTP Last-Modified value SHOULD change. Thus, clients >> > > cannot rely on this value for caching and SHOULD use ETags. >> > > >> > > NEW: >> > > >> > > COPY/MOVE behaviour: This property value is dependent on the last >> > > modified date of the destination resource, not the value of the >> > > property on the source resource. Also note the cacheability >> > > considerations in Section 8.1.6. >> > > >> > > Note that tis particular change removes language that contradicts >> > RFC2616 (we >> > > can't simply tell people that RFC2616 doesn't count anymore, at >> least not >> > > without strong WG consensus). >> > From w3c-dist-auth-request@frink.w3.org Tue Dec 20 05:14:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoeVT-0001H4-1c for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 05:14:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06148 for ; Tue, 20 Dec 2005 05:13:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoeTR-0007B3-Da for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 10:12:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoeTG-00077c-4r for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 10:11:50 +0000 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by maggie.w3.org with esmtp (Exim 4.50) id 1EoeT1-0001om-0O for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 10:11:48 +0000 Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 2BF4845E6D; Tue, 20 Dec 2005 11:16:06 +0100 (CET) In-Reply-To: <43A7CC10.6000502@gmx.de> References: <43A7CC10.6000502@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org, Dan Brotsky , Geoffrey M Clemm From: Stefan Eissing Date: Tue, 20 Dec 2005 11:11:12 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: none (maggie.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EoeT1-0001om-0O e705d277d9b4ba3acfadefab605d0b9b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/bd8c1ab99eef6cf93729f7121711321c@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11245 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 10:12:01 +0000 Content-Transfer-Encoding: 7bit Am 20.12.2005 um 10:17 schrieb Julian Reschke: > > Dan Brotsky wrote: >> ... >> In no case does a client ever assume that "the text it sent with the >> PUT >> is what would be retrieved by the GET." That's not what the etag is >> for. The etag is to reassure the client that the value on the server >> *has not changed since the PUT completed*. No guarantees are issued >> that the value doesn't change as part of the PUT; that would be a part >> of the PUT semantics for that server and are outside the scope of >> WebDAV. >> ... > > Thanks, Dan :-) Yes. > > So let's look at what clients are interested in again: > > - they want to avoid fetching an ETag after PUT, In my thinking, there is no such thing as an ETAG for the PUT body. For the HTTP client, the server's storage mechanism is a black box. With PUT it can insert bits into that box. With GET it gets bits out of that box. The internal wheels and springs of that box is not to be known by the client. IFF a HTTP server sends an ETAG in the repsonse to a PUT, the contract should be as follows: The PUT bits changed the state of the resource to something where at least one varient of carries the following ETAG. If you make a subsequent PUT with this ETAG in an IF-* header, your PUT is likely to succeed during normal operations. Or the other way round: if any agent subsequently modifies the resource, the ETAG will change. The last part is important for a WebDAV client, since it wants to use ETAG for optimistic locking. It is not really interested in ETAG for caching purposes. //Stefan From w3c-dist-auth-request@frink.w3.org Tue Dec 20 08:43:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EohmO-0001xi-Us for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:43:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27286 for ; Tue, 20 Dec 2005 08:42:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EohkD-0000cE-Di for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 13:41:33 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eohk0-0000Xq-25 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 13:41:20 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by aji.w3.org with esmtp (Exim 4.50) id 1Eohjq-0007He-3c for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 13:41:18 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDf3mF022919 for ; Tue, 20 Dec 2005 08:41:03 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKDf4Jj119440 for ; Tue, 20 Dec 2005 08:41:04 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKDf4KL027084 for ; Tue, 20 Dec 2005 08:41:04 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDf44D027078 for ; Tue, 20 Dec 2005 08:41:04 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 08:41:09 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 08:41:03, Serialize complete at 12/20/2005 08:41:03 Content-Type: multipart/alternative; boundary="=_alternative 004B2D53852570DD_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1Eohjq-0007He-3c 15f8d0192ef729b2a278d7a2839efef8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/OF9D18008D.10864B11-ON852570DD.0047C484-852570DD.004B2DCE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11246 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 13:41:33 +0000 This is a multipart message in MIME format. --=_alternative 004B2D53852570DD_= Content-Type: text/plain; charset="US-ASCII" Cullen wrote on 12/20/2005 12:30:12 AM: > ... it seems like a XML database that say had a regular > expression for mapping one URI to another could easily get multiple bindings > to one resource. No, the semantics of a binding is defined to be a relationship to the bound resource that is independent of other bindings to that bound resource. If you tried to implement a binding, B, with a URI mapping, any change to any of the bindings that define that URI mapping would disrupt the binding B. The best you can get with a URI mapping implementation is an "auto-redirect" functionality, which is not something defined by any current WebDAV spec (several years ago, there was a "WebDAV Reference" spec that some folks were working on for this, but that got dropped for lack of interest). > The questions was could you use the DB lock mechanism (or for that matter a > files system lock) to implement DAV locks. Julian said this would not be > compliant with 2518 which I believe but I don't yet understand why it would > not be. WebDAV locks require that lock request URI be "protected", in addition to the resource being "locked". DB locks do not "protect" the lock request URI. > Now Lisa proposed a model for locking slightly different than GULP which > would, by my understanding, would allow an implementation like GULP but > would also allow implementation like the one I just described to also be > compliant. I am not aware of any locking model being proposed by Lisa. There was the posting about whether the DELETE method should be required (or at least allowed) to delete all bindings to the resource being deleted (rather than just the one binding identified by the DELETE request-URL), but that was a discussion about the semantics of DELETE, not about a different locking model. > I strongly suspect that there are some DAV like servers out there that try > to use file and data base locking mechanism to do locks - I don't know if > they are 2518 compliant or not. I'm not sure what point you are making here ... a server can chose to not be compliant with the spec, and how that will harm interoperability will depend on what areas they are not compliant and what functionality is assumed/needed by the client. > I also suspect there are some servers that > do run regular expression on URL to create multiple bindings to files on a > file system and DELETE will remove both all at the same time. Those wouldn't be bindings, as defined by the BIND specification. > Again, don't > know if this should be legal for a server or not but practically it does not > make much difference for the client so servers will continue to do it. As you say, a server can do whatever it wants, but it does make a difference to a client if the server claims they are bindings (say, by declaring support for BIND/UNBIND/REBIND), which it doesn't. > I'd like to see this discussion have more on what the model should and and > why. So far I can summarize it as: > 1) gulp would probably work > 2) an alternative model might work > 3) some people prefer 1 some 2 > 4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is > good > 5) I'm not seeing the insights that help people understand why one model or > another would be better or worse. I believe that is because there is no alternative model that has been proposed. Cheers, Geoff --=_alternative 004B2D53852570DD_= Content-Type: text/html; charset="US-ASCII"
Cullen wrote on 12/20/2005 12:30:12 AM:

> ... it seems like a XML database that say had a regular
> expression for mapping one URI to another could easily get multiple bindings
> to one resource.

No, the semantics of a binding is defined to be a relationship to the bound
resource that is independent of other bindings to that bound resource.
If you tried to implement a binding, B, with a URI mapping, any change to any
of the bindings that define that URI mapping would disrupt the binding B.

The best you can get with a URI mapping implementation is an "auto-redirect"
functionality, which is not something defined by any current WebDAV spec
(several years ago, there was a "WebDAV Reference" spec that some folks were working
on for this, but that got dropped for lack of interest).

> The questions was could you use the DB lock mechanism (or for that matter a
> files system lock) to implement DAV locks. Julian said this would not be
> compliant with 2518 which I believe but I don't yet understand why it would
> not be.

WebDAV locks require that lock request URI be "protected", in addition to the resource
being "locked".  DB locks do not "protect" the lock request URI.

> Now Lisa proposed a model for locking slightly different than GULP which
> would, by my understanding, would allow an implementation like GULP but
> would also allow implementation like the one I just described to also be
> compliant.

I am not aware of any locking model being proposed by Lisa.
There was the posting about whether the DELETE method should be required
(or at least allowed) to delete all bindings to the resource being
deleted (rather than just the one binding identified by the DELETE
request-URL), but that was a discussion about the semantics of DELETE,
not about a different locking model.

> I strongly suspect that there are some DAV like servers out there that try
> to use file and data base locking mechanism to do locks - I don't know if
> they are 2518 compliant or not.

I'm not sure what point you are making here ... a server can chose to not
be compliant with the spec, and how that will harm interoperability will
depend on what areas they are not compliant and what functionality is
assumed/needed by the client.

> I also suspect there are some servers that
> do run regular expression on URL to create multiple bindings to files on a
> file system and DELETE will remove both all at the same time.

Those wouldn't be bindings, as defined by the BIND specification.

> Again, don't
> know if this should be legal for a server or not but practically it does not
> make much difference for the client so servers will continue to do it.

As you say, a server can do whatever it wants, but it does make a difference
to a client if the server claims they are bindings (say, by declaring support
for BIND/UNBIND/REBIND), which it doesn't.

> I'd like to see this discussion have more on what the model should and and
> why. So far I can summarize it as:
> 1) gulp would probably work
> 2) an alternative model might work
> 3) some people prefer 1 some 2
> 4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is
> good
> 5) I'm not seeing the insights that help people understand why one model or
> another would be better or worse.
I believe that is because there is no alternative model that has been proposed.

Cheers,
Geoff

--=_alternative 004B2D53852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 08:51:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eohth-0003I9-UN for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:51:22 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28431 for ; Tue, 20 Dec 2005 08:50:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EohsB-0003L4-7U for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 13:49:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eohs8-0003KS-D0 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 13:49:44 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eohrv-0000oD-BX for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 13:49:43 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDnQS3021393 for ; Tue, 20 Dec 2005 08:49:26 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKDnQu4118754 for ; Tue, 20 Dec 2005 08:49:26 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKDnQq9032130 for ; Tue, 20 Dec 2005 08:49:26 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKDnQ6C032127 for ; Tue, 20 Dec 2005 08:49:26 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 08:49:31 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 08:49:26, Serialize complete at 12/20/2005 08:49:26 Content-Type: multipart/alternative; boundary="=_alternative 004BF024852570DD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eohrv-0000oD-BX 74b69365ea4a255fd0cc4cb0901c84e0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/OFBF8D9422.9F872FD0-ON852570DD.004B4186-852570DD.004BF22E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11247 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 13:49:47 +0000 This is a multipart message in MIME format. --=_alternative 004BF024852570DD_= Content-Type: text/plain; charset="US-ASCII" It is my understanding that issues that were open against the BIND specification were actually 2518bis issues, and therefore have been moved to the 2518bis open issue list (and are being currently addressed). So if there is an open issue remaining against the BIND specification, could someone identify it? Also, what in Julian's statement that suggested that an individual submission of the BIND work be made?? He was just stating that his understanding was that the working group had come to an agreement on BIND, and that the only reason we haven't submitted BIND is that we are focusing on 2518bis (which is the statement Jim and I were agreeing with). Cheers, Geoff Cullen wrote on 12/20/2005 12:41:46 AM: > > My recollection was that BIND did NOT pass WGLC with no open issues. > (There may have been no new issues but that is quite a different > thing). I'm could certainly be wrong on this and would be happy to > be shown I was wrong. It may be that all the open issues are resolved in bis. > > If the WG does not come to agreement on BIND, I would certainly view > an individual submission of this work as an end run around the WG. > We have had this discussion before on the topic of bis and Ted and I > have both commented on our feelings about the idea that if the WG > can't agree we will just submit some draft anyways. > > I do believe that bis and BIND can both be completed. > > > > On 12/19/05 9:28 AM, "Jim Whitehead" wrote: > I agree with this as well. > > - Jim > On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote: > > Sounds good to me. > > Cheers, > Geoff > > Julian wrote on 12/17/2005 06:40:38 AM: > > > > > Hi. > > > > With the inclusion of the proposed text below in RFC2518bius, we'd be > > closing an issue that was raised in spring while discussing BIND. In the > > subsequent discussion (summarized in > > > properties-latest.html>) > > we found that it's not a problem specific to BIND at all, because it > > applies to any operation that creates new resources or moves them. > > > > Since then BIND has passed (a third!) working group last call, with no > > new issues raised. So here's my current understanding of where we stand > > with BIND. Feedback appreciated. > > > > 1) BIND is finished, however it's currently on hold because we're busy > > with RFC2518bis. > > > > 2) Should the working group manage to complete RFC2518bis as planned, we > > can slightly revise the current BIND draft, taking out stuff that's not > > needed anymore, namely > > > html#rfc.section.1.3> > > ("preconditions and postconditions"), parts of > > > html#rfc.section.2.4> > > (discussion of broken DELETE semantics of RFC2518bis), and parts of > > > html#rfc.section.8.2> > > (introduction of "DAV" request header). As these changes would be purely > > editorial, I'll assume we wouldn't want to do another WGLC. > > > > 3) On the other hand, should the working group fail to finish > > RFC2518bis, we'll submit BIND as is. > > > > > > Best regards, Julian > > > > > > > > > > > > > > bugzilla@soe.ucsc.edu wrote: > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 > > > > > > > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > 2005-12-17 03:25 ------- > > > OK, I believe I have completed my changes. As usual, see them > in context at > > > > latest.html#rfc.issue.bz085> > > > > > > > > > In Section 8, NEW: > > > > > > 8.1.6 Impacts of Namespace Operations on Cacheability > > > > > > Note that the HTTP response headers "Etag" and "Last-Modified" (see > > > [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per > > > resource), and are used by clients for caching. Therefore servers > > > must ensure that executing any operation that affects the URL > > > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve > > > their semantics, in particular: > > > > > > o For any given URL, the "Last-Modified" value must increment every > > > time the representation returned upon GET changes (within the > > > limits of timestamp resolution). > > > > > > o For any given URL, no "ETag" value must ever be re-used for > > > different representations returned by GET. > > > > > > In practice this means that servers > > > > > > o may have to increment "Last-Modified" timestamps for every > > > resource inside the destination namespace of a namespace > > > operation, and > > > > > > o similarily, may have to re-assign "ETag" values for these > > > resources (unless the server allocates entity tags in a way so > > > that they are unique across the whole URL namespace managed by the > > > server). > > > > > > Note that these considerations also apply to specific use cases, such > > > as using PUT creating a new resource at a URL that has been mapped > > > before, but has been deleted since then. > > > > > > Finally, WebDAV properties (such as DAV:getetag and DAV: > > > getlastmodified) that inherit their semantics from HTTP headers must > > > behave accordingly. > > > > > > In the description for DAV:getetag: > > > > > > OLD: > > > > > > COPY/MOVE behaviour: This property value is dependent on the final > > > state of the destination resource, not the value of the property > > > on the source resource. > > > > > > NEW: > > > > > > COPY/MOVE behaviour: This property value is dependent on the final > > > state of the destination resource, not the value of the property > > > on the source resource. Also note the cacheability considerations > > > in Section 8.1.6. > > > > > > In the description for DAV:getlastmodified: > > > > > > Section 14., para. 56: > > > OLD: > > > > > > COPY/MOVE behaviour: This property value is dependent on the last > > > modified date of the destination resource, not the value of the > > > property on the source resource. Note that some server > > > implementations use the file system date modified value for the > > > DAV:getlastmodified value, and this is preserved in a MOVE even > > > when the HTTP Last-Modified value SHOULD change. Thus, clients > > > cannot rely on this value for caching and SHOULD use ETags. > > > > > > NEW: > > > > > > COPY/MOVE behaviour: This property value is dependent on the last > > > modified date of the destination resource, not the value of the > > > property on the source resource. Also note the cacheability > > > considerations in Section 8.1.6. > > > > > > Note that tis particular change removes language that contradicts > > RFC2616 (we > > > can't simply tell people that RFC2616 doesn't count anymore, atleast not > > > without strong WG consensus). > > > > --=_alternative 004BF024852570DD_= Content-Type: text/html; charset="US-ASCII"
It is my understanding that issues that were open against the BIND
specification were actually 2518bis issues, and therefore have been
moved to the 2518bis open issue list (and are being currently addressed).
So if there is an open issue remaining against the BIND specification,
could someone identify it?

Also, what in Julian's statement that suggested that an individual
submission of the BIND work be made??  He was just stating that his
understanding was that the working group had come to an agreement on
BIND, and that the only reason we haven't submitted BIND is that we
are focusing on 2518bis (which is the statement Jim and I were
agreeing with).

Cheers,
Geoff

Cullen wrote on 12/20/2005 12:41:46 AM:

>
> My recollection was that BIND did NOT pass WGLC with no open issues.
> (There may have been no new issues but that is quite a different
> thing). I'm could certainly be wrong on this and would be happy to
> be shown I was wrong. It may be that all the open issues are resolved in bis.
>
> If the WG does not come to agreement on BIND, I would certainly view
> an individual submission of this work as an end run around the WG.
> We have had this discussion before on the topic of bis and Ted and I
> have both commented on our feelings about the idea that if the WG
> can't agree we will just submit some draft anyways.
>
> I do believe that bis and BIND can both be completed.
>
>
>
> On 12/19/05 9:28 AM, "Jim Whitehead" <ejw@soe.ucsc.edu> wrote:
> I agree with this as well.
>
> - Jim
> On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote:
>
> Sounds good to me.
>  
> Cheers,
> Geoff
>  
> Julian wrote on 12/17/2005 06:40:38 AM:
>  
>  >
>  > Hi.
>  >
>  > With the inclusion of the proposed text below in RFC2518bius, we'd be
>  > closing an issue that was raised in spring while discussing BIND. In the
>  > subsequent discussion (summarized in
>  > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-
>  > properties-latest.html>)
>  > we found that it's not a problem specific to BIND at all, because it
>  > applies to any operation that creates new resources or moves them.
>  >
>  > Since then BIND has passed (a third!) working group last call, with no
>  > new issues raised. So here's my current understanding of where we stand
>  > with BIND. Feedback appreciated.
>  >
>  > 1) BIND is finished, however it's currently on hold because we're busy
>  > with RFC2518bis.
>  >
>  > 2) Should the working group manage to complete RFC2518bis as planned, we
>  > can slightly revise the current BIND draft, taking out stuff that's not
>  > needed anymore, namely
>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>  > html#rfc.section.1.3>
>  > ("preconditions and postconditions"), parts of
>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>  > html#rfc.section.2.4>
>  > (discussion of broken DELETE semantics of RFC2518bis), and parts of
>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>  > html#rfc.section.8.2>
>  > (introduction of "DAV" request header). As these changes would be purely
>  > editorial, I'll assume we wouldn't want to do another WGLC.
>  >
>  > 3) On the other hand, should the working group fail to finish
>  > RFC2518bis, we'll submit BIND as is.
>  >
>  >
>  > Best regards, Julian
>  >
>  >
>  >
>  >
>  >
>  >
>  > bugzilla@soe.ucsc.edu wrote:
>  > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > ------- Additional Comments From julian.reschke@greenbytes.de  
>  > 2005-12-17 03:25 -------
>  > > OK, I believe I have completed my changes. As usual, see them
> in context at
>  > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
>  > latest.html#rfc.issue.bz085>
>  > >
>  > >
>  > > In Section 8, NEW:
>  > >
>  > >  8.1.6  Impacts of Namespace Operations on Cacheability
>  > >  
>  > >     Note that the HTTP response headers "Etag" and "Last-Modified" (see
>  > >     [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
>  > >     resource), and are used by clients for caching.  Therefore servers
>  > >     must ensure that executing any operation that affects the URL
>  > >     namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve
>  > >     their semantics, in particular:
>  > >  
>  > >     o  For any given URL, the "Last-Modified" value must increment every
>  > >        time the representation returned upon GET changes (within the
>  > >        limits of timestamp resolution).
>  > >  
>  > >     o  For any given URL, no "ETag" value must ever be re-used for
>  > >        different representations returned by GET.
>  > >  
>  > >     In practice this means that servers
>  > >  
>  > >     o  may have to increment "Last-Modified" timestamps for every
>  > >        resource inside the destination namespace of a namespace
>  > >        operation, and
>  > >  
>  > >     o  similarily, may have to re-assign "ETag" values for these
>  > >        resources (unless the server allocates entity tags in a way so
>  > >        that they are unique across the whole URL namespace managed by the
>  > >        server).
>  > >  
>  > >     Note that these considerations also apply to specific use cases, such
>  > >     as using PUT creating a new resource at a URL that has been mapped
>  > >     before, but has been deleted since then.
>  > >  
>  > >     Finally, WebDAV properties (such as DAV:getetag and DAV:
>  > >     getlastmodified) that inherit their semantics from HTTP headers must
>  > >     behave accordingly.
>  > >
>  > > In the description for DAV:getetag:
>  > >
>  > > OLD:
>  > >
>  > >     COPY/MOVE behaviour:  This property value is dependent on the final
>  > >        state of the destination resource, not the value of the property
>  > >        on the source resource.
>  > >
>  > > NEW:
>  > >
>  > >     COPY/MOVE behaviour:  This property value is dependent on the final
>  > >        state of the destination resource, not the value of the property
>  > >        on the source resource.  Also note the cacheability considerations
>  > >        in Section 8.1.6.
>  > >
>  > > In the description for DAV:getlastmodified:
>  > >
>  > > Section 14., para. 56:
>  > > OLD:
>  > >
>  > >     COPY/MOVE behaviour:  This property value is dependent on the last
>  > >        modified date of the destination resource, not the value of the
>  > >        property on the source resource.  Note that some server
>  > >        implementations use the file system date modified value for the
>  > >        DAV:getlastmodified value, and this is preserved in a MOVE even
>  > >        when the HTTP Last-Modified value SHOULD change.  Thus, clients
>  > >        cannot rely on this value for caching and SHOULD use ETags.
>  > >
>  > > NEW:
>  > >
>  > >     COPY/MOVE behaviour:  This property value is dependent on the last
>  > >        modified date of the destination resource, not the value of the
>  > >        property on the source resource.  Also note the cacheability
>  > >        considerations in Section 8.1.6.
>  > >
>  > > Note that tis particular change removes language that contradicts
>  > RFC2616 (we
>  > > can't simply tell people that RFC2616 doesn't count anymore, atleast not
>  > > without strong WG consensus).
>  >
>  
>
--=_alternative 004BF024852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 09:32:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiWx-0004JW-Tv for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 09:32:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04193 for ; Tue, 20 Dec 2005 09:30:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoiVT-0006jD-8F for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 14:30:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EoiVF-0005xR-85 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 14:30:09 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by maggie.w3.org with esmtp (Exim 4.50) id 1EoiV8-0001Ht-8S for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 14:30:08 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKETi2u003564 for ; Tue, 20 Dec 2005 09:29:44 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKETiJj112642 for ; Tue, 20 Dec 2005 09:29:44 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKETiFs013901 for ; Tue, 20 Dec 2005 09:29:44 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKETi6b013897 for ; Tue, 20 Dec 2005 09:29:44 -0500 In-Reply-To: <43A7CAF8.4050206@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 09:29:49 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 09:29:44, Serialize complete at 12/20/2005 09:29:44 Content-Type: multipart/alternative; boundary="=_alternative 004FA260852570DD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EoiV8-0001Ht-8S f7a57d3e14e7ff3b53255cddbd0883c7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF96C7D41D.5F573C64-ON852570DD.004F2690-852570DD.004FA2A9@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11248 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 14:30:23 +0000 This is a multipart message in MIME format. --=_alternative 004FA260852570DD_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian's meta-comment. This is an interesting issue, but it is clear that it is controversial (and the consensus solution non-obvious), therefore I believe it is also clear that we should not try to resolve it in 2518bis. Cheers, Geoff Julian Reschke wrote on 12/20/2005 04:12:24 AM: > Geoffrey M Clemm wrote: > > ... > > So unless we are going to disallow servers from modifying the > > content stored from a PUT (note that our server does not do this, > > so I am speaking as a neutral party here :-), we pretty much > > have to have PUT return the entity tag of the content that was > > PUT, not what would be returned by the GET. > > ... > > As a meta comment: > > I note here's another experienced person who interprets ETag-upon-PUT > differently than people on the HTTP mailing list. *If* RFC2518bis wants > to make normative statements about ETags in PUT, it MUST resolve this > issue, and in a way that won't conflict with future revisions of RFC2616. > > At this point I firmly believe that we can't deliver RFC2518bis in time, > unless we drop all changes introducing new requirements that are > non-controversial. > > Best regards, Julian > > > > --=_alternative 004FA260852570DD_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian's meta-comment.  This is an interesting issue,
but it is clear that it is controversial (and the consensus
solution non-obvious), therefore I believe it is also clear that we
should not try to resolve it in 2518bis.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 12/20/2005 04:12:24 AM:

> Geoffrey M Clemm wrote:
> > ...
> > So unless we are going to disallow servers from modifying the
> > content stored from a PUT (note that our server does not do this,
> > so I am speaking as a neutral party here :-), we pretty much
> > have to have PUT return the entity tag of the content that was
> > PUT, not what would be returned by the GET.
> > ...
>
> As a meta comment:
>
> I note here's another experienced person who interprets ETag-upon-PUT
> differently than people on the HTTP mailing list. *If* RFC2518bis wants
> to make normative statements about ETags in PUT, it MUST resolve this
> issue, and in a way that won't conflict with future revisions of RFC2616.
>
> At this point I firmly believe that we can't deliver RFC2518bis in time,
> unless we drop all changes introducing new requirements that are
> non-controversial.
>
> Best regards, Julian
>
>
>
>
--=_alternative 004FA260852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 10:25:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojMz-0002LU-Kz for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:25:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11877 for ; Tue, 20 Dec 2005 10:24:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EojL9-00044n-2S for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 15:23:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EojKu-00042K-5n for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 15:23:32 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1EojKj-00079f-2L for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 15:23:31 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKFN8ch008347 for ; Tue, 20 Dec 2005 10:23:08 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKFN8Jj100606 for ; Tue, 20 Dec 2005 10:23:08 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKFN8iU004661 for ; Tue, 20 Dec 2005 10:23:08 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKFMws9003453 for ; Tue, 20 Dec 2005 10:22:58 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 10:23:04 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 10:22:58, Serialize complete at 12/20/2005 10:22:58 Content-Type: multipart/alternative; boundary="=_alternative 0054824C852570DD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EojKj-00079f-2L f7892abf347a9468fcdf0fba8d7e67ca X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFE7420DAA.965C1673-ON852570DD.004FBCE3-852570DD.005482A6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11249 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 15:23:47 +0000 This is a multipart message in MIME format. --=_alternative 0054824C852570DD_= Content-Type: text/plain; charset="US-ASCII" "Dan Brotsky" wrote on 12/20/2005 12:09:21 AM: > In no case does a client ever assume that "the text it sent with the PUT > is what would be retrieved by the GET." I agree. > That's not what the etag is for. That is what is up for debate. If a server has modified the text in a way that the user needs to see (i.e., the modified text needs to be the basis for subsequent edits), then there needs to be an efficient way for the client to find this out. One technique would be to define the etag returned by the PUT as being the etag corresponding to PUT text. Then if a client wants to perform further edits on that text, it should issue a GET with an If-None-Match header containing that etag. If new text is returned, then it should base its edits on that new text. If no new text is returned, it knows it can continue editing the text that was submitted earlier with the PUT. > The etag is to reassure the client that the value on the server > *has not changed since the PUT completed*. How is that sufficient? If the changes made by the server are substantive (and should be the basis for subsequent edits), returning the etag that corresponds to the text on the server will mislead the client into thinking it can make changes to the text it sent up with the PUT, when in fact it should download the server text with a GET first. Cheers, Geoff --=_alternative 0054824C852570DD_= Content-Type: text/html; charset="US-ASCII"
"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/20/2005 12:09:21 AM:

> In no case does a client ever assume that "the text it sent with the PUT
> is what would be retrieved by the GET."

I agree.

> That's not what the etag is for.

That is what is up for debate.  If a server has modified the text in a
way that the user needs to see (i.e., the modified text needs to be
the basis for subsequent edits), then there needs to be an efficient way
for the client to find this out.

One technique would be to define the etag returned by the PUT as
being the etag corresponding to PUT text.  Then if a client wants to perform
further edits on that text, it should issue a GET with an If-None-Match
header containing that etag.  If new text is returned, then it should
base its edits on that new text.  If no new text is returned, it knows
it can continue editing the text that was submitted earlier with the PUT.

> The etag is to reassure the client that the value on the server
> *has not changed since the PUT completed*.

How is that sufficient?  If the changes made by the server are
substantive (and should be the basis for subsequent edits), returning
the etag that corresponds to the text on the server will mislead the
client into thinking it can make changes to the text it sent up with
the PUT, when in fact it should download the server text with a GET first.

Cheers,
Geoff



--=_alternative 0054824C852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 10:47:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eojhu-0008Lr-Sy for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:47:21 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15070 for ; Tue, 20 Dec 2005 10:46:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EojgE-000342-Ls for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 15:45:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eojg2-00032j-16 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 15:45:22 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eojfr-0002R7-EZ for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 15:45:20 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKFj91s010107 for ; Tue, 20 Dec 2005 10:45:09 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKFj9u4120238 for ; Tue, 20 Dec 2005 10:45:09 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKFj8Ux024910 for ; Tue, 20 Dec 2005 10:45:09 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKFj8aH024548 for ; Tue, 20 Dec 2005 10:45:08 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 10:45:11 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 10:45:08, Serialize complete at 12/20/2005 10:45:08 Content-Type: multipart/alternative; boundary="=_alternative 005688B3852570DD_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eojfr-0002R7-EZ e3f7ba7b018a2d369df7b8dd2e3d572e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFD041694D.745B6B5C-ON852570DD.00548FF3-852570DD.005688F7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11250 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 15:45:34 +0000 This is a multipart message in MIME format. --=_alternative 005688B3852570DD_= Content-Type: text/plain; charset="US-ASCII" Stefan wrote on 12/20/2005 05:11:12 AM: > IFF a HTTP server sends an ETAG in the response to a PUT, the contract > should be as follows: > The PUT bits changed the state of the resource to something where at > least one varient of carries the following ETAG. If you make a > subsequent PUT with this ETAG in an IF-* header, your PUT is likely to > succeed during normal operations. Or the other way round: if any agent > subsequently modifies the resource, the ETAG will change. What about the situation where the server itself is the "agent that modified the resource" (and did so during the PUT)? If this modification is substantive, the client cares both for GET (to see what is currently on the server) and for PUT (to base subsequent edits on what is actually on the server). > The last part is important for a WebDAV client, since it wants to use > ETAG for optimistic locking. It is not really interested in ETAG for > caching purposes. Actually, I think a WebDAV client cares about both optimistic locking and caching. Also note that they are rather intimately linked, since optimistic locking is based on knowing that the client's edits are based on the text that is currently on the server, while caching is based on knowing that what the client currently has is based on the text that is currently on the server. Cheers, Geoff --=_alternative 005688B3852570DD_= Content-Type: text/html; charset="US-ASCII"
Stefan wrote on 12/20/2005 05:11:12 AM:

> IFF a HTTP server sends an ETAG in the response to a PUT, the contract
> should be as follows:
>     The PUT bits changed the state of the resource to something where at
> least one varient of carries the following ETAG. If you make a
> subsequent PUT with this ETAG in an IF-* header, your PUT is likely to
> succeed during normal operations. Or the other way round: if any agent
> subsequently modifies the resource, the ETAG will change.

What about the situation where the server itself is the "agent that
modified the resource" (and did so during the PUT)?  If this modification
is substantive, the client cares both for GET (to see what is currently
on the server) and for PUT (to base subsequent edits on what is actually
on the server).

> The last part is important for a WebDAV client, since it wants to use
> ETAG for optimistic  locking. It is not really interested in ETAG for
> caching purposes.
Actually, I think a WebDAV client cares about both optimistic locking
and caching.  Also note that they are rather intimately linked, since
optimistic locking is based on knowing that the client's edits are based on the
text that is currently on the server, while caching is based on knowing
that what the client currently has is based on the text that is currently on
the server.

Cheers,
Geoff

--=_alternative 005688B3852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 10:54:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojoS-0000m9-J2 for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:54:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15477 for ; Tue, 20 Dec 2005 10:52:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eojmx-0004VT-13 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 15:52:31 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eojmr-0004Tf-Ft for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 15:52:25 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by aji.w3.org with esmtp (Exim 4.50) id 1EojmZ-00080v-2I for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 15:52:24 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EojmR-0008Ek-Ud; Tue, 20 Dec 2005 10:51:59 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , webdav mailing list , webdav chair Message-Id: Date: Tue, 20 Dec 2005 10:51:59 -0500 Received-SPF: none (aji.w3.org: domain of apache@newodin.ietf.org does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1EojmZ-00080v-2I d5c0534cafe5025ef242f100db943fb1 X-Original-To: w3c-dist-auth@w3.org Subject: Document Action: 'Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources' to Experimental RFC X-Archived-At: http://www.w3.org/mid/E1EojmR-0008Ek-Ud@newodin.ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11251 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 15:52:31 +0000 The IESG has approved the following document: - 'Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources ' as an Experimental RFC This document is the product of the WWW Distributed Authoring and Versioning Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-13.tx t Technical Summary This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resource indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approaches to the problem. Working Group Summary The WebDav Working Group came to consensus on this document as a candidate for Experimental RFC. Protocol Quality This specification is Experimental so that we can develop experience on the quality of this protocol. At least one implmentation is expected. The documentwas reviewed for the IESG by Ted Hardie. The PROTO shepherd is Cullen Jennings. (Who has reviewed the spec for the IESG? Are there implementations?) Note to RFC Editor OLD: Abstract: This specification defines redirect reference resources. A redirect reference resource is a resource whose default response is an HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), redirecting the client to a different resource, the target resource. A redirect reference makes it possible to access the target resource indirectly, through any URI mapped to the redirect reference resource. There are no integrity guarantees associated with redirect reference resources. NEW: This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resource indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achievethe same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approaches to the problem. From w3c-dist-auth-request@frink.w3.org Tue Dec 20 12:01:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EokrD-0002VX-OK for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 12:01:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00452 for ; Tue, 20 Dec 2005 11:59:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eokoq-0006Xj-RV for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 16:58:32 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eokod-0006Wn-2e for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 16:58:19 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by aji.w3.org with esmtp (Exim 4.50) id 1EokoT-000225-Pa for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 16:58:18 +0000 Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id B87A04648A; Tue, 20 Dec 2005 18:03:03 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Stefan Eissing Date: Tue, 20 Dec 2005 17:58:01 +0100 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: none (aji.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EokoT-000225-Pa c95da1a15e07fa2baae1e40a184cbf73 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11252 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 16:58:32 +0000 Content-Transfer-Encoding: quoted-printable Am 20.12.2005 um 16:45 schrieb Geoffrey M Clemm: > Stefan wrote on 12/20/2005 05:11:12 AM: > > > IFF a HTTP server sends an ETAG in the response to a PUT, the=20 > contract > > should be as follows: > > =A0 =A0 The PUT bits changed the state of the resource to something=20= > where at > > least one varient of carries the following ETAG. If you make a > > subsequent PUT with this ETAG in an IF-* header, your PUT is likely=20= > to > > succeed during normal operations. Or the other way round: if any=20 > agent > > subsequently modifies the resource, the ETAG will change. > > What about the situation where the server itself is the "agent that > modified the resource" (and did so during the PUT)? =A0If this=20 > modification > is substantive, the client cares both for GET (to see what is = currently > on the server) and for PUT (to base subsequent edits on what is=20 > actually > on the server). Yes, such servers are imaginable. No, there are not very useful: Mathematically speaking if PUT(x) is the function in the server that=20 takes the client input and modifies it, so that a subsequent=20 GET(PUT(x)) defines the content a client gets back. We are talking=20 about the situation where x !=3D GET(PUT(x)) because the other case = is=20 trivial. So, the discussion is about: when is it safe for the client to continue=20= editing x and when should it really be editing GET(PUT(x)) and what is=20= the role of the ETAG in all of this. So, let edit(x, z) be the content after an edit z of x, then we have=20 basically two cases: a) GET(PUT(edit(x,z)) =3D=3D GET(PUT(edit(GET(PUT(x)),z)) Read: the result of putting the edit of the original x and the=20 putting of the edit of GET(PUT(x)) is the same. Keyword substitutions=20 fall in this category. It is safe to submit old values since they are=20 always overwritten by the new ones on PUT. Not a problem. b) GET(PUT(edit(x,z)) !=3D GET(PUT(edit(GET(PUT(x)),z)) In this case the server modifies the content of a PUT in a way=20 which somewhat random or for example counting the number of=20 modifications inside the content. Case b) seems to be what you mean with "substantive" changes. My=20 interpretation would be that the server shall either be silent with=20 regards to ETAG on the PUT response. And that a client which does not=20 see an ETAG in a PUT response, should make a GET afterwards. If it=20 wants to avoid concurrent updates, it could lock the resource just for=20= the PUT with subsequent GET. //Stefan > > The last part is important for a WebDAV client, since it wants to=20= > use > > ETAG for optimistic =A0locking. It is not really interested in ETAG=20= > for > > caching purposes. > > Actually, I think a WebDAV client cares about both optimistic locking > and caching. =A0Also note that they are rather intimately linked, = since > optimistic locking is based on knowing that the client's edits are=20 > based on the > text that is currently on the server, while caching is based on = knowing > that what the client currently has is based on the text that is=20 > currently on > the server. One Counterexample is Keyword substitution. It is safe to edit and=20 submit old substitution values. =20= From w3c-dist-auth-request@frink.w3.org Tue Dec 20 12:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eol6a-0001AL-6o for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 12:16:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02713 for ; Tue, 20 Dec 2005 12:15:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eol4w-0004iY-3y for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 17:15:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eol4b-0004Jx-Su for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 17:14:49 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eol4Y-0002nU-WB for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 17:14:49 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBKHEkTQ005305 for ; Tue, 20 Dec 2005 09:14:46 -0800 (PST) Received: from [17.203.113.212] (luthji.apple.com [17.203.113.212]) by relay7.apple.com (Apple SCV relay) with ESMTP id E9B43222 for ; Tue, 20 Dec 2005 09:14:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> References: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> Content-Transfer-Encoding: 7bit From: Jim Luther Date: Tue, 20 Dec 2005 09:14:35 -0800 To: webdav X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (lisa.w3.org: domain of luther.j@apple.com designates 17.254.13.22 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.3 X-W3C-Scan-Sig: lisa.w3.org 1Eol4Y-0002nU-WB 239f301d514f651f8caad2a4ed7b3d76 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/465DBB27-5E7F-498B-A694-7476212F66F5@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11253 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 17:15:10 +0000 Content-Transfer-Encoding: 7bit On Dec 20, 2005, at 8:58 AM, Stefan Eissing wrote: > Mathematically speaking if PUT(x) is the function in the server > that takes the client input and modifies it, so that a subsequent > GET(PUT(x)) defines the content a client gets back. We are talking > about the situation where x != GET(PUT(x)) because the other case > is trivial. As the implementer of a WebDAV file system client, the whole idea of x != GET(PUT(x)) makes my head hurt. For file systems to work, they require x == GET(PUT(x)) if there have been no PUTs from other clients between the PUT and the GET. - Jim From w3c-dist-auth-request@frink.w3.org Tue Dec 20 12:24:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EolDx-0002sm-IZ for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 12:24:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03999 for ; Tue, 20 Dec 2005 12:23:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EolCY-0001eW-Iu for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 17:23:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EolCK-0001cb-QI for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 17:22:48 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.50) id 1EolCH-0006e0-G4 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 17:22:48 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBKHHVCr011482; Tue, 20 Dec 2005 18:17:31 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBKHHBYE011396; Tue, 20 Dec 2005 18:17:12 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBKHHBoM013464; Tue, 20 Dec 2005 18:17:11 +0100 (MET) Date: Tue, 20 Dec 2005 18:17:11 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Stefan Eissing cc: Geoffrey M Clemm , webdav In-Reply-To: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> Message-ID: References: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 20 Dec 2005 18:17:12 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EolCH-0006e0-G4 cae661cca8f63384f19ccfb12763a117 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512201808040.12809@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11254 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 17:23:02 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2005, Stefan Eissing wrote: > Mathematically speaking if PUT(x) is the function in the server that take= s=20 > the client input and modifies it, so that a subsequent GET(PUT(x)) define= s=20 > the content a client gets back. We are talking about the situation where = x=20 > !=3D GET(PUT(x)) because the other case is trivial. > > So, the discussion is about: when is it safe for the client to continue= =20 > editing x and when should it really be editing GET(PUT(x)) and what is th= e=20 > role of the ETAG in all of this. > > So, let edit(x, z) be the content after an edit z of x, then we have=20 > basically two cases: > > a) GET(PUT(edit(x,z)) =3D=3D GET(PUT(edit(GET(PUT(x)),z)) > Read: the result of putting the edit of the original x and the puttin= g=20 > of the edit of GET(PUT(x)) is the same. Keyword substitutions fall in thi= s=20 > category. It is safe to submit old values since they are always overwritt= en=20 > by the new ones on PUT. Not a problem. > > b) GET(PUT(edit(x,z)) !=3D GET(PUT(edit(GET(PUT(x)),z)) > In this case the server modifies the content of a PUT in a way which= =20 > somewhat random or for example counting the number of modifications insid= e=20 > the content. If the server marginally modified the resource (like adding a cvs commit timestamp), editing the current "x" copy should not generate errors (case= =20 a). If changes may be more drastic in the document after the PUT so that continuing to edit "x" client side is an issue, then it would be safe for the server to reply to the PUT(x) with the HTTP status code 205 (Reset Content), even if "The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent." could be clarified in this case as "the client should issue a GET to retreive the latest version fo the document to edit" In any case, I don't see what's preventing the server to generate the ETag= =20 of the document you might get... with a GET (so, not the ETag of what has= =20 been put) --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Tue Dec 20 12:31:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EolKX-0004us-8Q for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 12:31:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04794 for ; Tue, 20 Dec 2005 12:30:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EolJ2-0002ra-Nl for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 17:29:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EolJ0-0002r1-6s for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 17:29:42 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.50) id 1EolIl-0001Io-He for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 17:29:42 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBKHTDN1015111; Tue, 20 Dec 2005 18:29:13 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBKHT0Eu015054; Tue, 20 Dec 2005 18:29:00 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBKHSxTL013517; Tue, 20 Dec 2005 18:28:59 +0100 (MET) Date: Tue, 20 Dec 2005 18:28:59 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Jim Luther cc: webdav In-Reply-To: <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> Message-ID: References: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 20 Dec 2005 18:29:00 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EolIl-0001Io-He 6f5168360885cab3dbdd1a9293cab7f6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512201827170.12809@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11255 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 17:29:44 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2005, Jim Luther wrote: > > On Dec 20, 2005, at 8:58 AM, Stefan Eissing wrote: >> Mathematically speaking if PUT(x) is the function in the server that tak= es=20 >> the client input and modifies it, so that a subsequent GET(PUT(x)) defin= es=20 >> the content a client gets back. We are talking about the situation where= x=20 >> !=3D GET(PUT(x)) because the other case is trivial. > > As the implementer of a WebDAV file system client, the whole idea of x != =3D=20 > GET(PUT(x)) makes my head hurt. For file systems to work, they require x = =3D=3D=20 > GET(PUT(x)) if there have been no PUTs from other clients between the PUT= and=20 > the GET. Well, as long as it is carefully hidden by the server, the client should=20 care at all if there is a discrepancy between the edited document and=20 what's on the server. You can have the same issue with caching. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Tue Dec 20 13:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EolqU-00076q-0v for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 13:04:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09267 for ; Tue, 20 Dec 2005 13:03:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eolo2-0007c0-63 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 18:01:46 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eolnp-0007ZN-3a for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 18:01:33 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Eolnk-0002Gl-Il for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 18:01:32 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2010D142292; Tue, 20 Dec 2005 11:04:02 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , "Geoffrey M Clemm" From: Lisa Dusseault Date: Tue, 20 Dec 2005 10:01:22 -0800 To: "Dan Brotsky" X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eolnk-0002Gl-Il 531fe0f1ec7a31815302ff05e74b9977 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/e9dc8bd57812bb9eee7cf4d6e559cca9@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11256 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 18:01:46 +0000 Content-Transfer-Encoding: 7bit So when is it OK for a client doing multiple edits to do several PUTs in a row without intermediate GET requests? I'll take the example of a source code file which is being edited, and the source control server expands keywords in comments in the file. The client software could issue a PUT and get back an ETag, then when later changes are made, issue another PUT with If-Match with the ETag just received. Each time, the server could expand the keywords, without harm done from the client "losing" the server's changes. In this case, multiple PUT without intermediate GET is OK to do -- the server is prepared to make the same changes on each PUT and doesn't really need the client to re-synchronize their changes. There are other cases like some CalDAV cases where the server adds an internal event identifier or alternate address to the event. I'd also bet that there are clients that already do multiple PUT requests without intermediate GETs especially if the client holds a lock. But if in some cases the server needs the client to do a GET between two subsequent PUTs because the changes are important to preserve, how can the server accomplish that? I believe there is a way without any additional mechanisms: - If the server is making changes that can be overwritten without harm, or if the server is making no changes, it can return an ETag in response to PUT and the client doesn't have to do a GET unless it later sees a different ETag. - If the server is making changes that must be preserved, then the server can respond to the initial PUT with a throwaway ETag, then immediately update the ETag of the resource to a new and more permanent value. Now the client will be forced to recognize that there are new changes to be synched -- just as if another client had made the change in that period of time. Most clients would already be compliant with this. If we decided to make this kind of recommendation, we'd also have to specify whether it's OK to do this while the client is holding a LOCK. Lisa On Dec 19, 2005, at 9:09 PM, Dan Brotsky wrote: > > Geoff, > > I don't follow your reasoning here when you say "the client will > incorrectly conclude that the text it sent with the PUT is > what would be retrieved by the GET." It seems like there are three > cases: > > 1. The server modifies the value "on the way up", that is, before > returning from the PUT. (This is typically how a version control > system > would expand keywords, as part of the checkin.) In this case the value > that would eventually be retrieved by GET is known and thus its etag > can > be returned, even if that etag is a timestamp. > > 2. The server returns before modifying the value, but knows that it > will > do so. In this case a synthetic value for the etag can be generated > and > returned, as long as the server takes steps to make sure that etag is > returned with the eventual GET and all GETs requested before the > modifications are complete are blocked (e.g., with "server busy"). > This > etag can still be a timestamp, by the way, and can even be a timestamp > of the checkin, as long as the server associates that time with the > eventual result (which version control systems also typically do). > > 3. The server returns before modifying the value, and doesn't know that > a modification will take place. (For example, the "type" of the file > is > later changed so that the file undergoes keyword expansion later.) In > this case, at the time the file is modified by the server, it should > assign a new etag, because indeed the etag returned at the time of the > PUT should not match what a client would eventually GET. But before > that later modification is done, the etag is correct. > > In no case does a client ever assume that "the text it sent with the > PUT > is what would be retrieved by the GET." That's not what the etag is > for. The etag is to reassure the client that the value on the server > *has not changed since the PUT completed*. No guarantees are issued > that the value doesn't change as part of the PUT; that would be a part > of the PUT semantics for that server and are outside the scope of > WebDAV. > > dan > > > > ________________________________ > > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > Sent: Monday, December 19, 2005 19:47 > To: w3c-dist-auth@w3.org > Subject: Re: Summary of ETag related issues in RFC2518bis > > > > Jim: > > What about the point made by an earlier poster, namely that > a server is allowed to modify the content stored by a PUT, > so that a GET following the PUT might return different content > than was PUT (the earlier poster gave the example of a server > that expands RCS keywords on PUT). > > In this case (i.e. the server modifies the content stored by > the PUT), if server returns the etag that would be returned > on a GET, and the client requests a GET with an If-None-Match > header with the etag returned by the PUT, the client will > incorrectly conclude that the text it sent with the PUT is > what would be retrieved by the GET. > > So unless we are going to disallow servers from modifying the > content stored from a PUT (note that our server does not do > this, > so I am speaking as a neutral party here :-), we pretty much > have to have PUT return the entity tag of the content that was > PUT, not what would be returned by the GET. > > Then a client that wants to continue modifying a resource to > which it has just done a PUT, would need to do a GET with > an If-None-Match call following the PUT, to handle servers > that do this kind of rewriting on PUT. > > Note that this is just a single GET, not to be confused with > the "polling" scenario described in "promotion from weak to > strong etag" thread. > > Cheers, > Geoff > > > Jim wrote on 12/19/2005 09:11:02 PM: > > > > Julian, > > > > Thanks for making this more clear -- you're right, there is a > > > significant issue here. > > > > > The question here is whether an ETag returned upon PUT is > for the > > > entity the client sent (1), or for the entity the server > would send > > > upon a subsequent GET (2). > > > > > > There are cases where both will not be the same, so this > needs to > > > be clarified. In case of (2), a client will need a > subsequent GET > > > if it's planning to use the ETag for subsequent GET/Range > requests. > > > > > > > I think option #2 is the best one here (the Etag returned by > PUT is > > the one a subsequent GET would retrieve). > > > > From w3c-dist-auth-request@frink.w3.org Tue Dec 20 13:14:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eom08-0001L3-G0 for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 13:14:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10358 for ; Tue, 20 Dec 2005 13:13:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eolya-0000xX-Hb for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 18:12:40 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EolyY-0000wz-Bb for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 18:12:38 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EolyS-0004UM-Cx for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 18:12:37 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E76D2142292; Tue, 20 Dec 2005 11:14:57 -0800 (PST) In-Reply-To: <43A7C9AC.7080404@gmx.de> References: <43A7C9AC.7080404@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , WebDav , Cullen Jennings From: Lisa Dusseault Date: Tue, 20 Dec 2005 10:12:18 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EolyS-0004UM-Cx 2ffa49933faaa2b920d852ac96b32baf X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/fe16d267d50cb60b59fd3c1b82fd0a18@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11257 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 18:12:40 +0000 Content-Transfer-Encoding: 7bit On Dec 20, 2005, at 1:06 AM, Julian Reschke wrote: > Cullen Jennings wrote: > >> Now Lisa proposed a model for locking slightly different than GULP >> which >> would, by my understanding, would allow an implementation like GULP >> but >> would also allow implementation like the one I just described to also >> be >> compliant. For a server that supported BIND, it would probably have >> to be a >> GULP like implementation. > > I'll assume you're referring to > 1282.html>? > > Which reads: > > LD> One could imagine the lock applying to the resource and to all its > LD> bindings, considering the bindings to be part of the state of the > LD> resource. If I recall, I think this is the model I'd always > assumed > LD> until GULP. With this model, if A and B are bindings to a > resource, > LD> and a LOCK token to A is successful, then for the duration of the > lock > LD> the token is required to change either A or B. > > This implies that a binding is part of the state of the resource, and > I think both RFC2518 and RFC3744 are very clear that it's not. Namely, > in : No, that's not a correct conclusion. This model only implies that all bindings are covered by the LOCK as well as the resource itself. The resource state is still the resource state and that doesn't include *any* bindings. It's actually very similar to the model proposed in GULP. In that model, the LOCK covers one binding as well as the resource. The GULP model does not imply that the locked binding is part of the state of the resource either. What a lock covers is a separate concept from what a resource state includes. Lisa From w3c-dist-auth-request@frink.w3.org Tue Dec 20 13:29:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EomF1-00063q-7h for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 13:29:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14255 for ; Tue, 20 Dec 2005 13:28:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EomDa-0005El-Ch for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 18:28:10 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EomDU-0005E7-Q0 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 18:28:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EomCw-0007mI-IE for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 18:28:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBKIRSmc013845; Tue, 20 Dec 2005 10:27:28 -0800 Date: Tue, 20 Dec 2005 10:27:28 -0800 Message-Id: <200512201827.jBKIRSmc013845@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EomCw-0007mI-IE 5ef87596b49a6e89e42721959f369d3a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 86] DAV header definitions should use RFC3864 templates X-Archived-At: http://www.w3.org/mid/200512201827.jBKIRSmc013845@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11258 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 18:28:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=86 ------- Additional Comments From mnot@pobox.com 2005-12-20 10:27 ------- The also should be registered if the semantics or syntax of any of the existing headers changes, or is significantly clarified. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 20 13:54:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eomcy-0005JZ-Tv for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 13:54:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18568 for ; Tue, 20 Dec 2005 13:53:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EombS-0003oe-Ut for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 18:52:50 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EombJ-0003nz-HD for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 18:52:41 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EombF-0001l0-Lu for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 18:52:40 +0000 Received: (qmail invoked by alias); 20 Dec 2005 18:52:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 20 Dec 2005 19:52:17 +0100 X-Authenticated: #1915285 Message-ID: <43A85278.8010605@gmx.de> Date: Tue, 20 Dec 2005 19:50:32 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , WebDav , Cullen Jennings References: <43A7C9AC.7080404@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EombF-0001l0-Lu 980b4eca25f07958a933fcbce62b4d7a X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A85278.8010605@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11259 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 18:52:50 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: >> Which reads: >> >> LD> One could imagine the lock applying to the resource and to all its >> LD> bindings, considering the bindings to be part of the state of the >> LD> resource. If I recall, I think this is the model I'd always assumed >> LD> until GULP. With this model, if A and B are bindings to a resource, >> LD> and a LOCK token to A is successful, then for the duration of the >> lock >> LD> the token is required to change either A or B. >> >> This implies that a binding is part of the state of the resource, and >> I think both RFC2518 and RFC3744 are very clear that it's not. Namely, >> in : > > No, that's not a correct conclusion. This model only implies that all > bindings are covered by the LOCK as well as the resource itself. The > resource state is still the resource state and that doesn't include > *any* bindings. Well, it's what you said. Quoting again: LD> One could imagine the lock applying to the resource and to all its LD> bindings, considering the bindings to be part of the state of the LD> resource. If I recall, I think this is the model I'd always assumed LD> until GULP. With this model, if A and B are bindings to a resource, LD> and a LOCK token to A is successful, then for the duration of the lock LD> the token is required to change either A or B. > It's actually very similar to the model proposed in GULP. In that > model, the LOCK covers one binding as well as the resource. The GULP > model does not imply that the locked binding is part of the state of the > resource either. What a lock covers is a separate concept from what a > resource state includes. Well, it's not completely separate because if affects how Depth 0 locks in collections behave. Anyway, I don't think we'll make any progress unless you tell us exactly which part of GULP you're unhappy with, and how you propose to change it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 14:11:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EomtS-0001RN-2Z for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 14:11:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20630 for ; Tue, 20 Dec 2005 14:10:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eomrg-0008OH-B9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 19:09:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eomrd-0008NF-TI for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 19:09:33 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eomrb-0005pQ-9K for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 19:09:33 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2E61E1422AC; Tue, 20 Dec 2005 12:12:03 -0800 (PST) In-Reply-To: <43A85278.8010605@gmx.de> References: <43A7C9AC.7080404@gmx.de> <43A85278.8010605@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Tue, 20 Dec 2005 11:09:20 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eomrb-0005pQ-9K 7cb21597fd4564c1b4a7c26bad49e214 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/dbda34f535c4010f837fa12b26d26aef@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11260 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 19:09:36 +0000 Content-Transfer-Encoding: 7bit On Dec 20, 2005, at 10:50 AM, Julian Reschke wrote: > > LD> One could imagine the lock applying to the resource and to all its > LD> bindings, considering the bindings to be part of the state of the > LD> resource. If I recall, I think this is the model I'd always > assumed > LD> until GULP. With this model, if A and B are bindings to a > resource, > LD> and a LOCK token to A is successful, then for the duration of the > lock > LD> the token is required to change either A or B. > >> It's actually very similar to the model proposed in GULP. In that >> model, the LOCK covers one binding as well as the resource. The GULP >> model does not imply that the locked binding is part of the state of >> the resource either. What a lock covers is a separate concept from >> what a resource state includes. You're right, I used language in a sloppy way in describing the model. Anyway, to update my language, I don't see why the model for a LOCK can't cover more than only the binding that was locked and the resource (and its state) itself. We should be picking a model that results in desirable behaviors. > > Well, it's not completely separate because if affects how Depth 0 > locks in collections behave. > > Anyway, I don't think we'll make any progress unless you tell us > exactly which part of GULP you're unhappy with, and how you propose to > change it. I'm unhappy with the consequence of the GULP model that a DELETE of a binding to a locked resource may or may not work depending on whether that binding was the one locked. I propose to change it by requiring that a DELETE of a binding to a locked resource needs a lock token. Lisa From w3c-dist-auth-request@frink.w3.org Tue Dec 20 14:27:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eon8y-0006Pg-DB for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 14:27:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22623 for ; Tue, 20 Dec 2005 14:26:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eon7L-0004SU-HK for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 19:25:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eon7F-0004Ro-2f for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 19:25:41 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Eon7C-0004t6-QU for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 19:25:40 +0000 Received: (qmail invoked by alias); 20 Dec 2005 19:25:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 20 Dec 2005 20:25:36 +0100 X-Authenticated: #1915285 Message-ID: <43A85A46.9000307@gmx.de> Date: Tue, 20 Dec 2005 20:23:50 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <43A7C9AC.7080404@gmx.de> <43A85278.8010605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Eon7C-0004t6-QU 6a8ee3133bb67f16795953277919761a X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A85A46.9000307@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11261 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 19:25:47 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > You're right, I used language in a sloppy way in describing the model. > Anyway, to update my language, I don't see why the model for a LOCK > can't cover more than only the binding that was locked and the resource > (and its state) itself. We should be picking a model that results in > desirable behaviors. Yes, that's possible. >> Well, it's not completely separate because if affects how Depth 0 >> locks in collections behave. >> >> Anyway, I don't think we'll make any progress unless you tell us >> exactly which part of GULP you're unhappy with, and how you propose to >> change it. > > I'm unhappy with the consequence of the GULP model that a DELETE of a > binding to a locked resource may or may not work depending on whether > that binding was the one locked. I propose to change it by requiring > that a DELETE of a binding to a locked resource needs a lock token. I still don't see concrete text, but anyway... 1) The cost of locking a resource with multiple bindings will be significantly higher. 2) I don't see any gain to a client. The purpose of a lock is that while the resource is locked the client is protected from others moving away the resource, or modifying it's lockable state. Just protecting the binding that was locked achieves exactly that. 3) Multiple bindings to a resource cause the server behaviour to become more complex, yes. But the change you suggest doesn't help here; for instance it would mean that a client (without the lock token) is allowed to add a new binding to a locked resource, but not to remove it. As long as the model describes the semantics in RFC2518, and a client gets what it wants, I don't see any reason for coming up with a more complex model. So the summary is... Why does it matter, and how does that justify a more expensive implementation? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 14:38:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EonJN-0000fn-Jc for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 14:38:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23931 for ; Tue, 20 Dec 2005 14:37:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EonHp-0007tu-LK for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 19:36:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EonHc-0007sY-KM for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 19:36:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by maggie.w3.org with esmtp (Exim 4.50) id 1EonHZ-0003X3-DK for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 19:36:24 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 461121422A8; Tue, 20 Dec 2005 12:38:38 -0800 (PST) In-Reply-To: <43A85A46.9000307@gmx.de> References: <43A7C9AC.7080404@gmx.de> <43A85278.8010605@gmx.de> <43A85A46.9000307@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87fbd313f8db43d6f516e830a813a7e3@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Tue, 20 Dec 2005 11:35:59 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (maggie.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EonHZ-0003X3-DK 873c04a65ffaa5cd907dfcfbf9b15b4f X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/87fbd313f8db43d6f516e830a813a7e3@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11262 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 19:36:37 +0000 Content-Transfer-Encoding: 7bit On Dec 20, 2005, at 11:23 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> I'm unhappy with the consequence of the GULP model that a DELETE of a >> binding to a locked resource may or may not work depending on whether >> that binding was the one locked. I propose to change it by requiring >> that a DELETE of a binding to a locked resource needs a lock token. > > I still don't see concrete text, but anyway... You could consider the current draft to hold concrete text. > > 1) The cost of locking a resource with multiple bindings will be > significantly higher. > > 2) I don't see any gain to a client. The purpose of a lock is that > while the resource is locked the client is protected from others > moving away the resource, or modifying it's lockable state. Just > protecting the binding that was locked achieves exactly that. It's simpler for the client -- simpler client logic, fewer special cases. In particular, it's a model that plain RFC2518 clients (clients that haven't implemented any of BIND) can understand. > > 3) Multiple bindings to a resource cause the server behaviour to > become more complex, yes. But the change you suggest doesn't help > here; for instance it would mean that a client (without the lock > token) is allowed to add a new binding to a locked resource, but not > to remove it. Since that's covered in the BIND request, which is not part of RFC2518, I didn't see a need to get into that. DELETE is part of RFC2518 thus we have to cover its behavior. > > As long as the model describes the semantics in RFC2518, and a client > gets what it wants, I don't see any reason for coming up with a more > complex model. > > So the summary is... Why does it matter, and how does that justify a > more expensive implementation? I'm not convinced it' s a more expensive implementation. The best case for that argument is that it's a more expensive *server* implementation, for those servers which implement BIND. It seems simpler for everybody else. It matters because of the behavior with clients that are not aware of BIND. Lisa From w3c-dist-auth-request@frink.w3.org Tue Dec 20 15:00:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eonet-0008GY-CY for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:00:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28180 for ; Tue, 20 Dec 2005 14:59:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EondH-0005gn-FU for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 19:58:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eond4-0005f0-3k for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 19:58:34 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Eond0-00043t-2a for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 19:58:33 +0000 Received: (qmail invoked by alias); 20 Dec 2005 19:57:56 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp009) with SMTP; 20 Dec 2005 20:57:56 +0100 X-Authenticated: #1915285 Message-ID: <43A861DA.7060303@gmx.de> Date: Tue, 20 Dec 2005 20:56:10 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault CC: WebDav WG References: <43A7C9AC.7080404@gmx.de> <43A85278.8010605@gmx.de> <43A85A46.9000307@gmx.de> <87fbd313f8db43d6f516e830a813a7e3@osafoundation.org> In-Reply-To: <87fbd313f8db43d6f516e830a813a7e3@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Eond0-00043t-2a ce271bdd36722769d8699869cf2442a2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/43A861DA.7060303@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11263 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 19:58:47 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > On Dec 20, 2005, at 11:23 AM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >>> I'm unhappy with the consequence of the GULP model that a DELETE of a >>> binding to a locked resource may or may not work depending on whether >>> that binding was the one locked. I propose to change it by requiring >>> that a DELETE of a binding to a locked resource needs a lock token. >> >> I still don't see concrete text, but anyway... > > You could consider the current draft to hold concrete text. 1) We are trying to come up with a paragraph that summarizes lock semantics. RFC2518(bis) does not have this. 2) Please point to a piece of text that's not in sync with GULP, in particular saying what you think it says about DELETEing "other" bindings to a locked resource. >> 1) The cost of locking a resource with multiple bindings will be >> significantly higher. >> >> 2) I don't see any gain to a client. The purpose of a lock is that >> while the resource is locked the client is protected from others >> moving away the resource, or modifying it's lockable state. Just >> protecting the binding that was locked achieves exactly that. > > It's simpler for the client -- simpler client logic, fewer special > cases. In particular, it's a model that plain RFC2518 clients (clients > that haven't implemented any of BIND) can understand. How does it affect the client? How do things get simpler for a client? Please explain. >> 3) Multiple bindings to a resource cause the server behaviour to >> become more complex, yes. But the change you suggest doesn't help >> here; for instance it would mean that a client (without the lock >> token) is allowed to add a new binding to a locked resource, but not >> to remove it. > > Since that's covered in the BIND request, which is not part of RFC2518, > I didn't see a need to get into that. DELETE is part of RFC2518 thus we > have to cover its behavior. I don't think that's helpful. >> As long as the model describes the semantics in RFC2518, and a client >> gets what it wants, I don't see any reason for coming up with a more >> complex model. >> >> So the summary is... Why does it matter, and how does that justify a >> more expensive implementation? > > I'm not convinced it' s a more expensive implementation. The best case > for that argument is that it's a more expensive *server* implementation, > for those servers which implement BIND. It seems simpler for everybody > else. > > It matters because of the behavior with clients that are not aware of BIND. I'm still waiting for an example *why* it matters. Just stating that some client implementors may find that behavior surprising is hardly a technical argument. For instance, when you have multiple URLs for one resource, updating URL a may also affect URL b. That's also "surprising" for clients that do not expect that. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 15:04:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EonjE-0001aW-UT for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:04:59 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29044 for ; Tue, 20 Dec 2005 15:03:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eonho-0000Zy-Na for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 20:03:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eonhk-0000Yq-Tk for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 20:03:25 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eonhb-0006BJ-U2 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 20:03:24 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKK2sP3025917 for ; Tue, 20 Dec 2005 15:02:54 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKK2tJj099666 for ; Tue, 20 Dec 2005 15:02:55 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKK2tVw008881 for ; Tue, 20 Dec 2005 15:02:55 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKK2tAO008869 for ; Tue, 20 Dec 2005 15:02:55 -0500 In-Reply-To: <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 15:02:58 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 15:02:55, Serialize complete at 12/20/2005 15:02:55 Content-Type: multipart/alternative; boundary="=_alternative 006E2242852570DD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Eonhb-0006BJ-U2 367462438c538ca32f6ba07cde3357ed X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFFA49F524.90EE05B5-ON852570DD.006DF40F-852570DD.006E229E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11264 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 20:03:28 +0000 This is a multipart message in MIME format. --=_alternative 006E2242852570DD_= Content-Type: text/plain; charset="US-ASCII" If WebDAV were just for file systems, then life would be simpler, but it's not, so we do have to deal with the head-hurting scenarios (:-). Jim wrote on 12/20/2005 12:14:35 PM: > > On Dec 20, 2005, at 8:58 AM, Stefan Eissing wrote: > > Mathematically speaking if PUT(x) is the function in the server > > that takes the client input and modifies it, so that a subsequent > > GET(PUT(x)) defines the content a client gets back. We are talking > > about the situation where x != GET(PUT(x)) because the other case > > is trivial. > > As the implementer of a WebDAV file system client, the whole idea of > x != GET(PUT(x)) makes my head hurt. For file systems to work, they > require x == GET(PUT(x)) if there have been no PUTs from other > clients between the PUT and the GET. > > - Jim > --=_alternative 006E2242852570DD_= Content-Type: text/html; charset="US-ASCII"
If WebDAV were just for file systems, then life would be simpler,
but it's not, so we do have to deal with the head-hurting scenarios (:-).

Jim wrote on 12/20/2005 12:14:35 PM:

>
> On Dec 20, 2005, at 8:58 AM, Stefan Eissing wrote:
> > Mathematically speaking if PUT(x) is the function in the server  
> > that takes the client input and modifies it, so that a subsequent  
> > GET(PUT(x)) defines the content a client gets back. We are talking  
> > about the situation where x != GET(PUT(x)) because the other case  
> > is trivial.
>
> As the implementer of a WebDAV file system client, the whole idea of  
> x != GET(PUT(x)) makes my head hurt. For file systems to work, they  
> require x == GET(PUT(x)) if there have been no PUTs from other  
> clients between the PUT and the GET.
>
> - Jim
>
--=_alternative 006E2242852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 15:22:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoo0Z-00067B-7O for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:22:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01007 for ; Tue, 20 Dec 2005 15:21:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eonyj-0005Ot-RI for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 20:20:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eonya-0005Mz-St for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 20:20:48 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.50) id 1EonyX-0004W4-Bj for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 20:20:48 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKKilx001114 for ; Tue, 20 Dec 2005 15:20:44 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKKKiJj114918 for ; Tue, 20 Dec 2005 15:20:44 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKKKciS025022 for ; Tue, 20 Dec 2005 15:20:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKKcke024583 for ; Tue, 20 Dec 2005 15:20:38 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 15:20:36 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 15:20:38, Serialize complete at 12/20/2005 15:20:38 Content-Type: multipart/alternative; boundary="=_alternative 006FBF69852570DD_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1EonyX-0004W4-Bj 1f3132fd735b46b2031dc4419a6ed3fe X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF5528BD5E.3D6461AF-ON852570DD.006E354D-852570DD.006FC025@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11265 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 20:20:57 +0000 This is a multipart message in MIME format. --=_alternative 006FBF69852570DD_= Content-Type: text/plain; charset="US-ASCII" Lisa Dusseault wrote on 12/20/2005 01:01:22 PM: > ... if in > some cases the server needs the client to do a GET between two > subsequent PUTs because the changes are important to preserve, how can > the server accomplish that? > I believe there is a way without any additional mechanisms: > > - If the server is making changes that can be overwritten without > harm, or if the server is making no changes, it can return an ETag in > response to PUT and the client doesn't have to do a GET unless it later > sees a different ETag. > > - If the server is making changes that must be preserved, then the > server can respond to the initial PUT with a throwaway ETag, then > immediately update the ETag of the resource to a new and more permanent > value. Now the client will be forced to recognize that there are new > changes to be synched -- just as if another client had made the change > in that period of time. I'd word it somewhat differently, but this is basically what I meant by saying that "the etag should correspond to the content specified for the PUT". If the content specified by the PUT is equivalent to what will be retrieved by a GET, then the PUT etag will match the GET etag. If the content specified by the PUT is not equivalent to what will be retrieved by a GET (the second case), I wouldn't call this a "throwaway" etag, but > Most clients would already be compliant with this. Yes, that is why I prefer this interpretation. > If we decided to make this kind of recommendation, we'd also have to > specify whether it's OK to do this while the client is holding a LOCK. I think it is clear that the answer to this should be "yes", but stating it explicitly is fine with me. Cheers, Geoff --=_alternative 006FBF69852570DD_= Content-Type: text/html; charset="US-ASCII"
Lisa Dusseault <lisa@osafoundation.org> wrote on 12/20/2005 01:01:22 PM:

> ... if in
> some cases the server needs the client to do a GET between two
> subsequent PUTs because the changes are important to preserve, how can
> the server accomplish that?
> I believe there is a way without any additional mechanisms:
>
>   - If the server is making changes that can be overwritten without
> harm, or if the server is making no changes, it can return an ETag in
> response to PUT and the client doesn't have to do a GET unless it later
> sees a different ETag.
>
>   - If the server is making changes that must be preserved, then the
> server can respond to the initial PUT with a throwaway ETag, then
> immediately update the ETag of the resource to a new and more permanent
> value.  Now the client will be forced to recognize that there are new
> changes to be synched -- just as if another client had made the change
> in that period of time.

I'd word it somewhat differently, but this is basically what I meant by
saying that "the etag should correspond to the content specified for the PUT".
If the content specified by the PUT is equivalent to what will be retrieved
by a GET, then the PUT etag will match the GET etag.  If the content specified
by the PUT is not equivalent to what will be retrieved by a GET (the second
case), I wouldn't call this a "throwaway" etag, but  

> Most clients would already be compliant with this.

Yes, that is why I prefer this interpretation.

> If we decided to make this kind of recommendation, we'd also have to
> specify whether it's OK to do this while the client is holding a LOCK.

I think it is clear that the answer to this should be "yes", but stating it
explicitly is fine with me.

Cheers,
Geoff

--=_alternative 006FBF69852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 15:32:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooAK-0001tK-F6 for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:32:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01911 for ; Tue, 20 Dec 2005 15:31:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eoo8f-00017O-Ud for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 20:31:13 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eoo8c-00015s-A0 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 20:31:10 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.50) id 1Eoo8T-0000Nm-18 for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 20:31:09 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKUolb001968 for ; Tue, 20 Dec 2005 15:30:50 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKKUou4123852 for ; Tue, 20 Dec 2005 15:30:50 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKKUnRO008413 for ; Tue, 20 Dec 2005 15:30:49 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKUmAw008266 for ; Tue, 20 Dec 2005 15:30:48 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 15:30:42 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 15:30:47, Serialize complete at 12/20/2005 15:30:47 Content-Type: multipart/alternative; boundary="=_alternative 0070AC75852570DD_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1Eoo8T-0000Nm-18 68588de16c5a0bea74ae79201e3bdbea X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFEFDD222D.37E7DC35-ON852570DD.006FF05D-852570DD.0070ACBD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11266 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 20:31:13 +0000 This is a multipart message in MIME format. --=_alternative 0070AC75852570DD_= Content-Type: text/plain; charset="US-ASCII" Yves Lafon wrote on 12/20/2005 12:17:11 PM: > If changes may be more drastic in the document after the PUT so that > continuing to edit "x" client side is an issue, then it would be safe for > the server to reply to the PUT(x) with the HTTP status code 205 (Reset > Content), even if "The server has fulfilled the request and the user agent > SHOULD reset the document view which caused the request to be sent." could > be clarified in this case as "the client should issue a GET to retreive > the latest version fo the document to edit" Making returning a 205 a MUST (or at least a SHOULD) in this case sounds good to me. > In any case, I don't see what's preventing the server to generate the ETag > of the document you might get... with a GET (so, not the ETag of what has > been put) A server can of course do what it wants since the spec currently doesn't deal with this issue, but doing so will cause failures in clients that use a GET with an If-None-Match header with that etag, since the server will not return the new content (because the etag matches the server value). Cheers, Geoff --=_alternative 0070AC75852570DD_= Content-Type: text/html; charset="US-ASCII"
Yves Lafon <ylafon@w3.org> wrote on 12/20/2005 12:17:11 PM:

> If changes may be more drastic in the document after the PUT so that
> continuing to edit "x" client side is an issue, then it would be safe for
> the server to reply to the PUT(x) with the HTTP status code 205 (Reset
> Content), even if "The server has fulfilled the request and the user agent
> SHOULD reset the document view which caused the request to be sent." could
> be clarified in this case as "the client should issue a GET to retreive
> the latest version fo the document to edit"

Making returning a 205 a MUST (or at least a SHOULD) in this case
sounds good to me.

> In any case, I don't see what's preventing the server to generate the ETag
> of the document you might get... with a GET (so, not the ETag of what has
> been put)

A server can of course do what it wants since the spec currently doesn't deal
with this issue, but doing so will cause failures in clients that use
a GET with an If-None-Match header with that etag, since the server
will not return the new content (because the etag matches the server value).

Cheers,
Geoff


--=_alternative 0070AC75852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 15:44:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooLo-0004eV-Kj for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 15:44:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03753 for ; Tue, 20 Dec 2005 15:43:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EooKE-0003lw-72 for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 20:43:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EooKA-0003kG-Ma for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 20:43:06 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by maggie.w3.org with esmtp (Exim 4.50) id 1EooK3-00061B-Co for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 20:43:05 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKgWMB022604 for ; Tue, 20 Dec 2005 15:42:32 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBKKgWJj119040 for ; Tue, 20 Dec 2005 15:42:32 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBKKgWcE005254 for ; Tue, 20 Dec 2005 15:42:32 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBKKgWAQ005241 for ; Tue, 20 Dec 2005 15:42:32 -0500 In-Reply-To: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Tue, 20 Dec 2005 15:42:35 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/20/2005 15:42:31, Serialize complete at 12/20/2005 15:42:31 Content-Type: multipart/alternative; boundary="=_alternative 0071C2D6852570DD_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EooK3-00061B-Co 651d50c79780303c8aba1c398dfef08b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFEEA1ED99.56F81871-ON852570DD.0070F649-852570DD.0071C367@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11267 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 20:43:10 +0000 This is a multipart message in MIME format. --=_alternative 0071C2D6852570DD_= Content-Type: text/plain; charset="US-ASCII" Stefan Eissing wrote on 12/20/2005 11:58:01 AM: > b) GET(PUT(edit(x,z)) != GET(PUT(edit(GET(PUT(x)),z)) > In this case the server modifies the content of a PUT in a way > which somewhat random or for example counting the number of > modifications inside the content. > > Case b) seems to be what you mean with "substantive" changes. My > interpretation would be that the server shall either be silent with > regards to ETAG on the PUT response. And that a client which does not > see an ETAG in a PUT response, should make a GET afterwards. If it > wants to avoid concurrent updates, it could lock the resource just for > the PUT with subsequent GET. If the server includes the etag corresponding to the PUT content, standard If-Match and If-None-Match processing works properly. Isn't supporting the standard semantics better than hoping clients will interpret the absence of an etag header in a certain way? Cheers, Geoff --=_alternative 0071C2D6852570DD_= Content-Type: text/html; charset="US-ASCII"
Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/20/2005 11:58:01 AM:

>    b) GET(PUT(edit(x,z)) != GET(PUT(edit(GET(PUT(x)),z))
>       In this case the server modifies the content of a PUT in a way
> which somewhat random or for example counting the number of
> modifications inside the content.
>
> Case b) seems to be what you mean with "substantive" changes. My
> interpretation would be that the server shall either be silent with
> regards to ETAG on the PUT response. And that a client which does not
> see an ETAG in a PUT response, should make a GET afterwards. If it
> wants to avoid concurrent updates, it could lock the resource just for
> the PUT with subsequent GET.

If the server includes the etag corresponding to the PUT content,
standard If-Match and If-None-Match processing works properly.  
Isn't supporting the standard semantics better than hoping clients will
interpret the absence of an etag header in a certain way?

Cheers,
Geoff

 --=_alternative 0071C2D6852570DD_=-- From w3c-dist-auth-request@frink.w3.org Tue Dec 20 16:57:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EopU7-0005c3-5r for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 16:57:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03937 for ; Tue, 20 Dec 2005 16:56:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EopS8-0008Gf-QP for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 21:55:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EopRh-0007rv-La for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 21:54:57 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EopRf-0004Yi-Gc for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 21:54:57 +0000 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBKLsoFb029065; Tue, 20 Dec 2005 13:54:50 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay7.apple.com (Apple SCV relay) with ESMTP id CCC2E227; Tue, 20 Dec 2005 13:54:50 -0800 (PST) In-Reply-To: <43A7C4FC.6020209@gmx.de> References: <43A7C4FC.6020209@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Dan Brotsky , Jim Whitehead , WebDav WG Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 20 Dec 2005 13:54:49 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EopRf-0004Yi-Gc 8a5a6667fc50ad5a7d5565ae11bb35d3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/C44108F2-789E-4F7D-BA67-E63CAD0765DC@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11268 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 21:55:24 +0000 Content-Transfer-Encoding: 7bit I don't see how that would help. For one, I suspect may clients will ask for this all the time, so then why not do it for all clients all the time? I'm not opposed to giving you the strong ETag, I just don't know how to do it. One possibility is not to return an ETag at all on PUT, nor for GET requests in the first second, and only return the strong ETag once we know what it is. This eliminates the weak ETag altogether. The advantage here is that while the client would have to poll a few times to get the ETag, it would now when it got the "final" ETag that Jim is advocating for, once it got any ETag at all. However, for the first second, the file would not be cacheable, which is more or less correct anyway. -wsv On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote: > But it seems that there's a simple way to fix this (for Apache): > should a client require a strong ETag upon PUT, it could make that > explicit in the request (new header?), so that the server can just > special-case this, and do what's needed to ensure the ETag is > stable. Wilfredo? From w3c-dist-auth-request@frink.w3.org Tue Dec 20 17:08:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eopem-00047T-Nd for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 17:08:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04966 for ; Tue, 20 Dec 2005 17:07:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EopdA-0002Qr-Ki for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 22:06:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eopcy-0002QH-BV for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 22:06:36 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eopcu-0001Bi-3H for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 22:06:35 +0000 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 399CA1422AF; Tue, 20 Dec 2005 15:09:06 -0800 (PST) In-Reply-To: References: <43A7C4FC.6020209@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , Dan Brotsky , Jim Whitehead , WebDav WG From: Lisa Dusseault Date: Tue, 20 Dec 2005 14:06:27 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eopcu-0001Bi-3H 1c9b2d52861253923924edd9b2f9b72a X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/c03b79139472bf08f703439c7b6efe16@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11269 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 22:06:48 +0000 Content-Transfer-Encoding: quoted-printable Perhaps Content-MD5 would help solve a number of these issues in a much=20= cleaner way. It doesn't do away with ETags I suspect, but can help=20 with PUT equivalence. Lisa On Dec 20, 2005, at 1:54 PM, Wilfredo S=E1nchez Vega wrote: > > I don't see how that would help. For one, I suspect may clients=20 > will ask for this all the time, so then why not do it for all clients=20= > all the time? I'm not opposed to giving you the strong ETag, I just=20= > don't know how to do it. > > One possibility is not to return an ETag at all on PUT, nor for GET=20= > requests in the first second, and only return the strong ETag once we=20= > know what it is. This eliminates the weak ETag altogether. > > The advantage here is that while the client would have to poll a few=20= > times to get the ETag, it would now when it got the "final" ETag that=20= > Jim is advocating for, once it got any ETag at all. However, for the=20= > first second, the file would not be cacheable, which is more or less=20= > correct anyway. > > -wsv > > > On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote: > >> But it seems that there's a simple way to fix this (for Apache):=20 >> should a client require a strong ETag upon PUT, it could make that=20 >> explicit in the request (new header?), so that the server can just=20 >> special-case this, and do what's needed to ensure the ETag is stable.=20= >> Wilfredo? > > From w3c-dist-auth-request@frink.w3.org Tue Dec 20 17:23:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eopt4-0003nq-AJ for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 17:23:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07206 for ; Tue, 20 Dec 2005 17:22:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoprW-0006U9-5k for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 22:21:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoprJ-0006T1-9w for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 22:21:25 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by aji.w3.org with esmtp (Exim 4.50) id 1EoprF-0006om-Nv for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 22:21:24 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBKMLHK8004539 for ; Tue, 20 Dec 2005 14:21:17 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id 426AF172; Tue, 20 Dec 2005 14:21:17 -0800 (PST) In-Reply-To: <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> References: <14e5c821a9ebaae9d5218fd1547bbfd9@greenbytes.de> <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49AC3EDE-F1DD-4CAD-A80C-BB6A05D231F0@wsanchez.net> Cc: webdav Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 20 Dec 2005 14:21:16 -0800 To: Jim Luther X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoprF-0006om-Nv e7be505bc9e80a566a90691b0c344cbf X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/49AC3EDE-F1DD-4CAD-A80C-BB6A05D231F0@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11270 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 22:21:38 +0000 Content-Transfer-Encoding: 7bit And x == GET(PUT(x)) is true for DAV servers which are usable (by your client, anyway) as file systems. I don't think it's reasonable to require that all DAV servers cater to file system clients. DAV wasn't designed to be an NFS replacement, and is, for the most part a pretty suboptimal protocol for building network file servers. -wsv On Dec 20, 2005, at 9:14 AM, Jim Luther wrote: > As the implementer of a WebDAV file system client, the whole idea > of x != GET(PUT(x)) makes my head hurt. For file systems to work, > they require x == GET(PUT(x)) if there have been no PUTs from other > clients between the PUT and the GET. From w3c-dist-auth-request@frink.w3.org Tue Dec 20 18:16:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoqik-00057m-LY for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 18:16:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14916 for ; Tue, 20 Dec 2005 18:15:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eoqgk-0002TS-JT for w3c-dist-auth-dist@listhub.w3.org; Tue, 20 Dec 2005 23:14:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EoqgS-0002Sf-60 for w3c-dist-auth@listhub.w3.org; Tue, 20 Dec 2005 23:14:16 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1EoqgP-0003nr-Ma for w3c-dist-auth@w3.org; Tue, 20 Dec 2005 23:14:15 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBKNE9gG020464; Tue, 20 Dec 2005 15:14:09 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 67520177; Tue, 20 Dec 2005 15:14:09 -0800 (PST) In-Reply-To: References: <43A7C4FC.6020209@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6EAB7570-CF68-446F-80AE-5F80502060DE@wsanchez.net> Cc: Julian Reschke , Dan Brotsky , Jim Whitehead , WebDav WG Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 20 Dec 2005 15:14:07 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EoqgP-0003nr-Ma b92a767253cf6ae3785f14f097741ca3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/6EAB7570-CF68-446F-80AE-5F80502060DE@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11271 X-Loop: w3c-dist-auth@w3.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, 20 Dec 2005 23:14:34 +0000 Content-Transfer-Encoding: quoted-printable This makes sense, assuming Content-MD5 on the PUT response =20 describes what the server is storing. The client can then use that =20 to compare with what they send and thus detect that the server stored =20= something different. This would avoid the need for a subsequent GET =20 request if the checksum matches what was sent. -wsv On Dec 20, 2005, at 2:06 PM, Lisa Dusseault wrote: > > Perhaps Content-MD5 would help solve a number of these issues in a =20 > much cleaner way. It doesn't do away with ETags I suspect, but can =20= > help with PUT equivalence. > > Lisa > > On Dec 20, 2005, at 1:54 PM, Wilfredo S=E1nchez Vega wrote: > >> >> I don't see how that would help. For one, I suspect may clients =20= >> will ask for this all the time, so then why not do it for all =20 >> clients all the time? I'm not opposed to giving you the strong =20 >> ETag, I just don't know how to do it. >> >> One possibility is not to return an ETag at all on PUT, nor for =20 >> GET requests in the first second, and only return the strong ETag =20 >> once we know what it is. This eliminates the weak ETag altogether. >> >> The advantage here is that while the client would have to poll a =20= >> few times to get the ETag, it would now when it got the "final" =20 >> ETag that Jim is advocating for, once it got any ETag at all. =20 >> However, for the first second, the file would not be cacheable, =20 >> which is more or less correct anyway. >> >> -wsv >> >> >> On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote: >> >>> But it seems that there's a simple way to fix this (for Apache): =20 >>> should a client require a strong ETag upon PUT, it could make =20 >>> that explicit in the request (new header?), so that the server =20 >>> can just special-case this, and do what's needed to ensure the =20 >>> ETag is stable. Wilfredo? >> >> > From w3c-dist-auth-request@frink.w3.org Tue Dec 20 19:36:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eorxw-0000rq-AN for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 19:36:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25429 for ; Tue, 20 Dec 2005 19:35:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eorvf-00032d-W6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 00:34:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EorvU-00031j-4a for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 00:33:52 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EorvR-0000VY-LJ for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 00:33:51 +0000 Received: (qmail invoked by alias); 21 Dec 2005 00:33:47 -0000 Received: from p508F9A53.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.154.83] by mail.gmx.net (mp031) with SMTP; 21 Dec 2005 01:33:47 +0100 X-Authenticated: #1915285 Message-ID: <43A8A295.8080507@gmx.de> Date: Wed, 21 Dec 2005 01:32:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Dan Brotsky , Jim Whitehead , WebDav WG References: <43A7C4FC.6020209@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EorvR-0000VY-LJ 872d6c5b2f9a351576f337e623daa423 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A8A295.8080507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11272 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 00:34:03 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA25429 Wilfredo S=E1nchez Vega wrote: >=20 > I don't see how that would help. For one, I suspect may clients will= =20 > ask for this all the time, so then why not do it for all clients all th= e=20 > time? I'm not opposed to giving you the strong ETag, I just don't know= =20 > how to do it. You could do it for the case of PUT by pausing for 1 second, right? This=20 is exactly why I wouldn't want that to be the default. > One possibility is not to return an ETag at all on PUT, nor for GET=20 > requests in the first second, and only return the strong ETag once we=20 > know what it is. This eliminates the weak ETag altogether. >=20 > The advantage here is that while the client would have to poll a few=20 > times to get the ETag, it would now when it got the "final" ETag that=20 > Jim is advocating for, once it got any ETag at all. However, for the=20 > first second, the file would not be cacheable, which is more or less=20 > correct anyway. That's correct, but how is a client supposed to know that retrying will=20 return a strong ETag later? It may talk to a resource that doesn't have=20 ETags at all. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 20 20:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EosKx-000241-Co for webdav-archive@megatron.ietf.org; Tue, 20 Dec 2005 20:00:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27884 for ; Tue, 20 Dec 2005 19:59:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EosJW-0007ye-Di for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 00:58:42 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EosJT-0007y4-6z for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 00:58:39 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1EosHH-0000OJ-6x for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 00:58:37 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBL0uHTj011293; Tue, 20 Dec 2005 16:56:17 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 6EE00324015; Tue, 20 Dec 2005 16:56:17 -0800 (PST) In-Reply-To: <43A8A295.8080507@gmx.de> References: <43A7C4FC.6020209@gmx.de> <43A8A295.8080507@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Dan Brotsky , Jim Whitehead , WebDav WG Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 20 Dec 2005 16:56:16 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EosHH-0000OJ-6x 93c5690c1fababe698c828f6bc202fa2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/D1BAEB14-DE96-47C6-886B-FF9CCAC02DCC@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11273 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 00:58:42 +0000 Content-Transfer-Encoding: quoted-printable Yeah, but I don't think I could sell that implementation to the =20 rest of httpd-dev, even optionally. -wsv On Dec 20, 2005, at 4:32 PM, Julian Reschke wrote: > Wilfredo S=E1nchez Vega wrote: >> I don't see how that would help. For one, I suspect may clients =20= >> will ask for this all the time, so then why not do it for all =20 >> clients all the time? I'm not opposed to giving you the strong =20 >> ETag, I just don't know how to do it. > > You could do it for the case of PUT by pausing for 1 second, right? =20= > This is exactly why I wouldn't want that to be the default. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 00:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EowvZ-0005Wu-SG for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 00:54:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26353 for ; Wed, 21 Dec 2005 00:53:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EowtY-0000Qw-7Y for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 05:52:12 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EowtL-0000PO-7b for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 05:51:59 +0000 Received: from exprod6og3.obsmtp.com ([64.18.1.123]) by aji.w3.org with smtp (Exim 4.50) id 1EowtB-00031x-3Q for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 05:51:57 +0000 Received: from source ([192.150.20.142]) by exprod6ob3.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 21:51:41 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL5pZFX021776; Tue, 20 Dec 2005 21:51:35 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL5pbHV008165; Tue, 20 Dec 2005 21:51:37 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 21:52:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2005 21:51:35 -0800 Message-ID: In-Reply-To: <43A7BB6F.9020409@gmx.de> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFPNOniuF8tmOGRFKewWmsdHQwrQAtR+cQ From: "Dan Brotsky" To: "Julian Reschke" , "Jim Whitehead" Cc: =?iso-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , "WebDav WG" X-OriginalArrivalTime: 21 Dec 2005 05:52:57.0092 (UTC) FILETIME=[CAE5CC40:01C605F2] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EowtB-00031x-3Q 3cdb5016d16d72c622dcacdd58199fec X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9349@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11274 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 05:52:12 +0000 Content-Transfer-Encoding: quoted-printable > Well. If the client has the lock, why would it need the ETag=20 > in the first place? Because servers can still write files when they are locked, and because = losing a lock doesn't mean that you don't have up-to-date content. One of the primary uses, if not *the primary use*, of etags in a = collaborative authoring environment is so clients can know whether or = not they have current content. When a client authors a file and places = it on the server, it doesn't want to have to fetch the file again unless = necessary, and it doesn't want to have to do more roundtrips before = continuing with work on that and other files. Let me ask the converse question: If the server has the file, why can't = it send the etag? That's all the spec is saying it should do. dan =20 From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eox6s-0000hH-UA for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:06:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27366 for ; Wed, 21 Dec 2005 01:04:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eox4y-0003Tf-OB for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:04:00 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eox4s-0003SZ-L1 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:03:55 +0000 Received: from exprod6og9.obsmtp.com ([64.18.1.21]) by aji.w3.org with smtp (Exim 4.50) id 1Eox4p-0007hm-7j for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:03:53 +0000 Received: from source ([192.150.20.142]) by exprod6ob9.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:03:41 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL63aFX022108; Tue, 20 Dec 2005 22:03:36 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBL63Xrs000508; Tue, 20 Dec 2005 22:03:34 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:04:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2005 22:03:31 -0800 Message-ID: In-Reply-To: <43A7C4FC.6020209@gmx.de> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFQlfaTMapu+F0Q+ixggUHh9i9mgAsG9tA From: "Dan Brotsky" To: "Julian Reschke" Cc: =?iso-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , "Jim Whitehead" , "WebDav WG" X-OriginalArrivalTime: 21 Dec 2005 06:04:52.0652 (UTC) FILETIME=[756796C0:01C605F4] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eox4p-0007hm-7j ea3c897ef3c8bf4c8896c3e2d7ed3340 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B934A@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11275 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:04:00 +0000 Content-Transfer-Encoding: quoted-printable > Depends on what the target platform is. Apache is built on=20 > top of APR, (Apache Portable Runtime) as I recall, and that=20 > API may not have a guarantee of a higher timer resolution.=20 > What would be your proposal to the Apache guys how to handle that? I gave one below. > Second, even in filesystems with millisecond resolutions,=20 > all the filesystem has to do is support exclusive=20 > write-locking and you can build a compliant server. The=20 > server must simply keep the file locked long enough to avoid=20 > the milllisecond window and then set the time back to the=20 > write time in order to ensure that any interference is noticeable. >=20 > You mean "second" resolution, right? No, I meant millisecond. Perhaps you are sugggesting that APR only = supports 1-second resolution? Why would that be? I know of no = filesystems with that kind of resolution. > Two problems here: >=20 > 1) Doing that may not be acceptable for mass uploads, where=20 > millions of documents need to be uploaded (don't tell me this=20 > isn't a use case...). Sure it's a use case. But you don't explain why it's not acceptable. >=20 > 2) Even then, it's not that simple. ETag and Last-Modified=20 > also have to be adjusted after COPY and notably MOVE (!). It's exactly that simple. Because COPY and MOVE don't suffer the = non-interference problem (on the target, that is), because the target = doesn't exist for someone to have open. > > I don't have any problem with a standard that can't be=20 > implemented in the simplest possible way against the weakest=20 > possible resources. All we are saying is that, if you really=20 > have a filesystem that allows multiple writers to interfere=20 > with one another undetectably, then you can't build a=20 > compliant WebDAV server against that filesystem. And that's=20 > just a fact: the server certainly can't guarantee anything=20 > without support from the filesystem. >=20 > I disagree with the statement that this kind of server is=20 > non-compliant.=20 > Are you saying that Apache/moddav is non-compliant? I have no opinion about this. If I were working on Apache I never would = have been returning weak etags in the first place. I would be putting = together the timestamp and filesize returned by the fs and using that as = the etag in the first place. If someone complained that they ran into a = case where some other process wrote the file at exactly the same = millisecond and exactly the same size and I reported the same etag when = in fact they claimed the content was different, then I would say = "whoops, sorry, that's a bug, and it's a never-fix bug because the use = cases where it's a problem so rare and so hard to fix (see = pain-in-the-rear solution above) that it's not worth fixing. If you = want to make that bug go away use a real filesystem with microsecond = resolution for your server." >=20 > >> Absent a workable solution, we're going to be moving=20 > Apache into=20 > >> the non-compliant category if this is a MUST-level requirement. > >=20 > > I think there are many workable solutions over standard=20 > filesystems for this problem. >=20 > This discussion isn't new. As a matter of fact, it started at=20 > least two years ago. As of now, nothing in Apache/moddav has=20 > changed. I take that as indication that changing the server=20 > may not be as trivial as some people think. No, I take that as an indication that everyone agrees that this bug is = only there conceptually and that it never actually occurs in the field. = I know for a fact that the Adobe client implementations just ignored the = weak marking on the etag and that's why they were interoperable with = Apache. >=20 > So, Dan, can you make a concrete proposal how to change Apache/moddav? Yes: stop returning weak etags. See above. dan From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:10:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxB8-0003yz-Qi for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:10:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27883 for ; Wed, 21 Dec 2005 01:09:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eox9f-0004Pt-6l for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:08:51 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eox9b-0004PK-B2 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:08:47 +0000 Received: from exprod6og2.obsmtp.com ([64.18.1.122]) by aji.w3.org with smtp (Exim 4.50) id 1Eox9X-00014k-Re for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:08:46 +0000 Received: from source ([192.150.11.134]) by exprod6ob2.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:08:39 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL68SYc014647; Tue, 20 Dec 2005 22:08:28 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBL68Ws0000786; Tue, 20 Dec 2005 22:08:37 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:09:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2005 22:08:34 -0800 Message-ID: In-Reply-To: <43A7CC10.6000502@gmx.de> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFRomd2q/0E/UxTfSbIBPqsyLPJgArfRgw From: "Dan Brotsky" To: "Julian Reschke" Cc: "Geoffrey M Clemm" , X-OriginalArrivalTime: 21 Dec 2005 06:09:55.0105 (UTC) FILETIME=[29AE4110:01C605F5] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eox9X-00014k-Re 11c978faec54cf73c52eaae8c0fe37fb X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B934C@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11276 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:08:51 +0000 Content-Transfer-Encoding: quoted-printable We're getting closer... :)=20 > So let's look at what clients are interested in again: >=20 > - they want to avoid fetching an ETag after PUT, Yes. >=20 > - in some cases, they want to be able to find out whether the=20 > server stored exactly what they sent, No. I claim no client wants to know this. Ever. If they really want to know that the content matches what they have, then they use a server that supports MD5 hashes and they rely on those. If they are worried about network corruption then TCP/IP has things for that. > - if they interleave PUT and PROPPATCH, they want their ETags=20 > to continue to work. Yes. >=20 > I believe all of these things can be accomplish by protocol=20 > extensions, and I'll be happy to spec them out. On the other=20 > hand, I don't think it would be a good idea to rush them into=20 > RFC2518bis, which was supposed to be finished around this=20 > time of year (if I may remember). I believe all of these things that clients want are accomplished with what we have, as long as we have servers hand back strong etags on PUT. dan From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:19:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxK3-0007N5-Fa for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:19:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28526 for ; Wed, 21 Dec 2005 01:18:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoxIU-0006x5-EU for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:17:58 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoxIF-0006vX-3H for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:17:43 +0000 Received: from exprod6og10.obsmtp.com ([64.18.1.22]) by aji.w3.org with smtp (Exim 4.50) id 1EoxHw-0004T0-Vi for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:17:41 +0000 Received: from source ([192.150.11.134]) by exprod6ob10.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:17:18 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL6H7Yc015081; Tue, 20 Dec 2005 22:17:07 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL6HIHV009423; Tue, 20 Dec 2005 22:17:18 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:18:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C605F6.61147174" Date: Tue, 20 Dec 2005 22:17:16 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFeclhsxyth0K5TsyrdW3zQCJwzAAe4fHw From: "Dan Brotsky" To: "Geoffrey M Clemm" , " webdav" X-OriginalArrivalTime: 21 Dec 2005 06:18:37.0793 (UTC) FILETIME=[613A1D10:01C605F6] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoxHw-0004T0-Vi b4ba11242317965fee88501150a6f53c X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B934F@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11277 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:17:58 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C605F6.61147174 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah, now I begin to understand what I believe is a big misimpression on the part of the server authors. (Sadly, I see almost no client authors in these discussions anymore, which has been a big part of my problem with the WebDAV process forever and why I've been quiet for so long now.) =20 Folks, clients are perfectly well aware that servers munge data when they store it. It's *way* outside the scope of WebDAV to try and match up the server-munging semantics with clients that rely on those semantics. If you are a client that's looking for a faithful dumb store and you stumble across a CVS-backed webdav server that does keyword expansion to your graphics files, you will figure this out quickly and stop using that server. That doesn't mean it's not a WebDAV-compliant server, just not one with the store semantics you were expecting. =20 Similarly, if you are a client expecting a CVS server and you use a file-backed Apache server, it also won't meet your needs. But it's still WebDAV-compliant. =20 The point of this effort is to define a greatest common denominator that can be divided evenly into the semantics of any server that's called WebDAV compliant. But believe me, every client in the world understands that there may be extra factors in that server's semantics that are relatively prime with the client's intent! =20 That's a good thing. =20 dan ________________________________ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Tuesday, December 20, 2005 07:23 To: webdav Subject: RE: Summary of ETag related issues in RFC2518bis =09 =09 "Dan Brotsky" wrote on 12/20/2005 12:09:21 AM: =09 > In no case does a client ever assume that "the text it sent with the PUT > is what would be retrieved by the GET."=20 =09 I agree.=20 =09 > That's not what the etag is for.=20 =09 That is what is up for debate. If a server has modified the text in a=20 way that the user needs to see (i.e., the modified text needs to be=20 the basis for subsequent edits), then there needs to be an efficient way=20 for the client to find this out.=20 =09 One technique would be to define the etag returned by the PUT as being the etag corresponding to PUT text. Then if a client wants to perform=20 further edits on that text, it should issue a GET with an If-None-Match=20 header containing that etag. If new text is returned, then it should=20 base its edits on that new text. If no new text is returned, it knows=20 it can continue editing the text that was submitted earlier with the PUT.=20 =09 > The etag is to reassure the client that the value on the server > *has not changed since the PUT completed*.=20 =09 How is that sufficient? If the changes made by the server are=20 substantive (and should be the basis for subsequent edits), returning=20 the etag that corresponds to the text on the server will mislead the=20 client into thinking it can make changes to the text it sent up with=20 the PUT, when in fact it should download the server text with a GET first.=20 =09 Cheers, Geoff=20 =09 =09 =09 =09 ------_=_NextPart_001_01C605F6.61147174 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ah, now I begin to understand what I = believe is a big=20 misimpression on the part of the server authors.  (Sadly, I see = almost no=20 client authors in these discussions anymore, which has been a big part = of my=20 problem with the WebDAV process forever and why I've been quiet for so = long=20 now.)
 
Folks, clients are perfectly well aware that = servers munge=20 data when they store it.  It's *way* outside the scope of WebDAV to = try and=20 match up the server-munging semantics with clients that rely on those=20 semantics.  If you are a client that's looking for a faithful dumb = store=20 and you stumble across a CVS-backed webdav server that does keyword = expansion to=20 your graphics files, you will figure this out quickly and stop using = that=20 server.  That doesn't mean it's not a WebDAV-compliant server, just = not one=20 with the store semantics you were expecting.
 
Similarly, if you are a client expecting a CVS = server and=20 you use a file-backed Apache server, it also won't meet your = needs.  But=20 it's still WebDAV-compliant.
 
The point of this effort is to define a = greatest common=20 denominator that can be divided evenly into the semantics of any = server=20 that's called WebDAV compliant.  But believe me, every client in = the world=20 understands that there may be extra factors in that server's semantics = that are=20 relatively prime with the client's intent!
 
That's a good thing.
 
    dan

From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M=20 Clemm
Sent: Tuesday, December 20, 2005 07:23
To:=20 webdav
Subject: RE: Summary of ETag related issues in=20 RFC2518bis


"Dan Brotsky" = <dbrotsky@adobe.com> wrote=20 on 12/20/2005 12:09:21 AM:

> In no case does a client ever = assume=20 that "the text it sent with the PUT
> is what would be retrieved = by the=20 GET."

I agree. =

> That's not what the etag is for. =

That is what is up for debate.  If a server has = modified the=20 text in a
way that the user needs = to see=20 (i.e., the modified text needs to be
the=20 basis for subsequent edits), then there needs to be an efficient=20 way
for the client to find this = out.=20

One technique would be to = define the etag=20 returned by the PUT as
being the = etag=20 corresponding to PUT text.  Then if a client wants to = perform=20
further edits on that text, it should issue a = GET with an=20 If-None-Match
header containing = that etag.=20  If new text is returned, then it should
base its edits on that new text.  If no new text is = returned,=20 it knows
it can continue editing = the text=20 that was submitted earlier with the PUT.

> The etag is to reassure the client that the value on = the=20 server
> *has not changed since the PUT completed*.=20

How is that sufficient?  If the = changes made by=20 the server are
substantive (and = should be the=20 basis for subsequent edits), returning
the=20 etag that corresponds to the text on the server will mislead = the=20
client into thinking it can make changes to the = text it=20 sent up with
the PUT, when in fact = it should=20 download the server text with a GET first.

Cheers,
Geoff



------_=_NextPart_001_01C605F6.61147174-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:24:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxOm-0000mP-VF for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:24:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28763 for ; Wed, 21 Dec 2005 01:23:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoxN9-0007ge-6t for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:22:47 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoxN6-0007fQ-D6 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:22:44 +0000 Received: from exprod6og10.obsmtp.com ([64.18.1.22]) by aji.w3.org with smtp (Exim 4.50) id 1EoxMo-0006dK-0W for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:22:43 +0000 Received: from source ([192.150.20.142]) by exprod6ob10.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:22:22 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL6MHFX022975; Tue, 20 Dec 2005 22:22:17 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBL6MJrs001504; Tue, 20 Dec 2005 22:22:20 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:23:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C605F7.14996394" Date: Tue, 20 Dec 2005 22:22:17 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFfMl14rdRLFYsTium+pIfnDu+yQAeYEyQ From: "Dan Brotsky" To: "Geoffrey M Clemm" , " webdav" X-OriginalArrivalTime: 21 Dec 2005 06:23:38.0725 (UTC) FILETIME=[1498B150:01C605F7] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoxMo-0006dK-0W a530333b4bc6e1a988652768b62804b3 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9352@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11278 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:22:47 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C605F7.14996394 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The last part is important for a WebDAV client, since it wants to use=20 > ETAG for optimistic locking. It is not really interested in ETAG for=20 > caching purposes. Actually, I think a WebDAV client cares about both optimistic locking=20 and caching. =20 =20 I strongly disagree. I think the first author's statement is correct. =20 Also note that they are rather intimately linked, since=20 optimistic locking is based on knowing that the client's edits are based on the=20 text that is currently on the server, while caching is based on knowing=20 that what the client currently has is based on the text that is currently on=20 the server. =20 =20 No. Optimistic locking is based on knowing that the client's edits are being applied to the content the client last sent to the server, and are not overwriting other client's edits. Caching is based on knowing that the content you *last received* is the same as what you *would receive* on your next get. =20 HTTP clients, whether webdav or not, know they must have *received* the content associated with an etag in order to avoid fetching it again. That's caching. =20 WebDAV clients only need to know that they *sent* the content associated with an etag in order to avoid overwriting someone else's edits. That's optimistic locking. =20 dan =20 ------_=_NextPart_001_01C605F7.14996394 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> The last part is = important for a=20 WebDAV client, since it wants to use
> ETAG for optimistic =  locking.=20 It is not really interested in ETAG for
> caching=20 purposes.

Actually, I think a = WebDAV client=20 cares about both optimistic locking
and=20 caching.   
 
I strongly disagree.  I think the = first author's=20 statement is correct.
 
 Also note that they are rather = intimately=20 linked, since
optimistic locking is = based on=20 knowing that the client's edits are based on the
text that is currently on the server, while caching is = based on=20 knowing
that what the client = currently has is=20 based on the text that is currently on
the=20 server.  
 
No.  Optimistic locking is based on = knowing that=20 the client's edits are being applied to the content the client last sent = to the=20 server, and are not overwriting other client's edits.  Caching is=20 based on knowing = that the=20 content you *last received* is the same as what you *would receive* on = your next=20 get.
 
HTTP clients, whether webdav or not, know they = must have=20 *received* the content associated with an etag in order to avoid = fetching it=20 again.  That's caching.
 
WebDAV clients only need to know that they = *sent* the=20 content associated with an etag in order to avoid overwriting someone = else's=20 edits.  That's optimistic locking.
 
    dan
 
------_=_NextPart_001_01C605F7.14996394-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:31:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxVG-00036b-9i for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:31:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29663 for ; Wed, 21 Dec 2005 01:30:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoxTY-0000tH-S2 for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:29:24 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoxTK-0000sA-Ir for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:29:10 +0000 Received: from exprod6og4.obsmtp.com ([64.18.1.124]) by aji.w3.org with smtp (Exim 4.50) id 1EoxTA-0000xs-Kd for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:29:09 +0000 Received: from source ([192.150.20.142]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:28:55 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL6SoFX023156; Tue, 20 Dec 2005 22:28:50 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBL6Sqrs001714; Tue, 20 Dec 2005 22:28:53 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:30:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2005 22:28:50 -0800 Message-ID: In-Reply-To: <465DBB27-5E7F-498B-A694-7476212F66F5@apple.com> Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFiUvHYv53ZegpT2CZ+kjjGp5+sAAbd0Vw From: "Dan Brotsky" To: "Jim Luther" , "webdav" X-OriginalArrivalTime: 21 Dec 2005 06:30:11.0932 (UTC) FILETIME=[FEF751C0:01C605F7] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoxTA-0000xs-Kd 52e7a6d457169fa46a9f44ee4649a488 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9356@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11279 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:29:24 +0000 Content-Transfer-Encoding: quoted-printable > As the implementer of a WebDAV file system client, the whole=20 > idea of x !=3D GET(PUT(x)) makes my head hurt. For file systems=20 > to work, they require x =3D=3D GET(PUT(x)) if there have been no=20 > PUTs from other clients between the PUT and the GET. Yes, but there are many other webdav servers out there that are *not* file systems. I strongly believe that WebDAV was not intended just for file-system access. By the way, everyone, please note that GET(PUT(x)) =3D=3D x does *not* = imply PUT(x) =3D=3D x. dan From w3c-dist-auth-request@frink.w3.org Wed Dec 21 01:35:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxZR-0004pH-48 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:35:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00160 for ; Wed, 21 Dec 2005 01:34:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EoxXx-0003r9-LX for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 06:33:57 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EoxXt-0003qa-4N for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 06:33:53 +0000 Received: from exprod6og6.obsmtp.com ([64.18.1.126]) by aji.w3.org with smtp (Exim 4.50) id 1EoxXo-0002XC-MS for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 06:33:52 +0000 Received: from source ([192.150.20.142]) by exprod6ob6.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 20 Dec 2005 22:33:42 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBL6XbFX023284; Tue, 20 Dec 2005 22:33:37 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBL6Xdrs001846; Tue, 20 Dec 2005 22:33:39 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 22:34:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2005 22:33:37 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYFj5U37W9UUDqlRi2gKoxXAmqGTwAaJJJA From: "Dan Brotsky" To: "Lisa Dusseault" Cc: , "Geoffrey M Clemm" X-OriginalArrivalTime: 21 Dec 2005 06:34:58.0403 (UTC) FILETIME=[A9B75330:01C605F8] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EoxXo-0002XC-MS eb39e56be60611686ca5a77af51a7b7b X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9358@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11280 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 06:33:57 +0000 Content-Transfer-Encoding: quoted-printable As to your last question: Yes it's OK and no the server needs to break the lock if it does this (because it's indistinguishable from another client's edit). Not all clients will work efficiently against servers that unexpectedly munge data after PUTs are complete but that's life. dan > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 > Sent: Tuesday, December 20, 2005 10:01 > To: Dan Brotsky > Cc: w3c-dist-auth@w3.org; Geoffrey M Clemm > Subject: Re: Summary of ETag related issues in RFC2518bis >=20 > So when is it OK for a client doing multiple edits to do=20 > several PUTs in a row without intermediate GET requests? >=20 > I'll take the example of a source code file which is being=20 > edited, and the source control server expands keywords in=20 > comments in the file. =20 > The client software could issue a PUT and get back an ETag,=20 > then when later changes are made, issue another PUT with=20 > If-Match with the ETag=20 > just received. Each time, the server could expand the keywords,=20 > without harm done from the client "losing" the server's changes. >=20 > In this case, multiple PUT without intermediate GET is OK to=20 > do -- the server is prepared to make the same changes on each=20 > PUT and doesn't really need the client to re-synchronize=20 > their changes. There are other cases like some CalDAV cases=20 > where the server adds an internal event identifier or=20 > alternate address to the event. I'd also bet that there are=20 > clients that already do multiple PUT requests without=20 > intermediate GETs especially if the client holds a lock. But=20 > if in some cases the server needs the client to do a GET=20 > between two subsequent PUTs because the changes are important=20 > to preserve, how can the server accomplish that? >=20 > I believe there is a way without any additional mechanisms: >=20 > - If the server is making changes that can be overwritten=20 > without harm, or if the server is making no changes, it can=20 > return an ETag in response to PUT and the client doesn't have=20 > to do a GET unless it later sees a different ETag. >=20 > - If the server is making changes that must be preserved,=20 > then the server can respond to the initial PUT with a=20 > throwaway ETag, then immediately update the ETag of the=20 > resource to a new and more permanent value. Now the client=20 > will be forced to recognize that there are new changes to be=20 > synched -- just as if another client had made the change in=20 > that period of time. Most clients would already be compliant=20 > with this. >=20 > If we decided to make this kind of recommendation, we'd also=20 > have to specify whether it's OK to do this while the client=20 > is holding a LOCK. >=20 > Lisa >=20 > On Dec 19, 2005, at 9:09 PM, Dan Brotsky wrote: >=20 > > > > Geoff, > > > > I don't follow your reasoning here when you say "the client will=20 > > incorrectly conclude that the text it sent with the PUT is=20 > what would=20 > > be retrieved by the GET." It seems like there are three > > cases: > > > > 1. The server modifies the value "on the way up", that is, before=20 > > returning from the PUT. (This is typically how a version control=20 > > system would expand keywords, as part of the checkin.) In=20 > this case=20 > > the value that would eventually be retrieved by GET is=20 > known and thus=20 > > its etag can be returned, even if that etag is a timestamp. > > > > 2. The server returns before modifying the value, but knows that it=20 > > will do so. In this case a synthetic value for the etag can be=20 > > generated and returned, as long as the server takes steps=20 > to make sure=20 > > that etag is returned with the eventual GET and all GETs requested=20 > > before the modifications are complete are blocked (e.g.,=20 > with "server=20 > > busy"). > > This > > etag can still be a timestamp, by the way, and can even be=20 > a timestamp=20 > > of the checkin, as long as the server associates that time with the=20 > > eventual result (which version control systems also typically do). > > > > 3. The server returns before modifying the value, and doesn't know=20 > > that a modification will take place. (For example, the=20 > "type" of the=20 > > file is later changed so that the file undergoes keyword expansion=20 > > later.) In this case, at the time the file is modified by=20 > the server,=20 > > it should assign a new etag, because indeed the etag=20 > returned at the=20 > > time of the PUT should not match what a client would=20 > eventually GET. =20 > > But before that later modification is done, the etag is correct. > > > > In no case does a client ever assume that "the text it sent=20 > with the=20 > > PUT is what would be retrieved by the GET." That's not=20 > what the etag=20 > > is for. The etag is to reassure the client that the value on the=20 > > server *has not changed since the PUT completed*. No=20 > guarantees are=20 > > issued that the value doesn't change as part of the PUT;=20 > that would be=20 > > a part of the PUT semantics for that server and are outside=20 > the scope=20 > > of WebDAV. > > > > dan > > > > > > > > ________________________________ > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > > Sent: Monday, December 19, 2005 19:47 > > To: w3c-dist-auth@w3.org > > Subject: Re: Summary of ETag related issues in RFC2518bis > > =09 > > =09 > > > > Jim: > > =09 > > What about the point made by an earlier poster, namely that > > a server is allowed to modify the content stored by a PUT, > > so that a GET following the PUT might return different content > > than was PUT (the earlier poster gave the example of a server > > that expands RCS keywords on PUT). > > =09 > > In this case (i.e. the server modifies the content stored by > > the PUT), if server returns the etag that would be returned > > on a GET, and the client requests a GET with an If-None-Match > > header with the etag returned by the PUT, the client will > > incorrectly conclude that the text it sent with the PUT is > > what would be retrieved by the GET. > > =09 > > So unless we are going to disallow servers from modifying the > > content stored from a PUT (note that our server does=20 > not do this, > > so I am speaking as a neutral party here :-), we pretty much > > have to have PUT return the entity tag of the content that was > > PUT, not what would be returned by the GET. > > =09 > > Then a client that wants to continue modifying a resource to > > which it has just done a PUT, would need to do a GET with > > an If-None-Match call following the PUT, to handle servers > > that do this kind of rewriting on PUT. > > =09 > > Note that this is just a single GET, not to be confused with > > the "polling" scenario described in "promotion from weak to > > strong etag" thread. > > =09 > > Cheers, > > Geoff > > =09 > > =09 > > Jim wrote on 12/19/2005 09:11:02 PM: > > > > > > Julian, > > > > > > Thanks for making this more clear -- you're right, there is a > > > > > significant issue here. > > > > > > > The question here is whether an ETag returned upon=20 > PUT is for the > > > > entity the client sent (1), or for the entity the=20 > server would=20 > > send > > > > upon a subsequent GET (2). > > > > > > > > There are cases where both will not be the same, so=20 > this needs to > > > > be clarified. In case of (2), a client will need a=20 > subsequent GET > > > > if it's planning to use the ETag for subsequent GET/Range=20 > > requests. > > > > > > > > > > I think option #2 is the best one here (the Etag=20 > returned by PUT is > > > the one a subsequent GET would retrieve). > > =09 > > =09 > > > > >=20 >=20 From w3c-dist-auth-request@frink.w3.org Wed Dec 21 05:08:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep0th-0004zo-I0 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:08:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18930 for ; Wed, 21 Dec 2005 05:07:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep0rU-0005lV-Ja for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 10:06:20 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep0rG-0005g9-BY for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 10:06:06 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep0rD-0007aJ-A9 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 10:06:05 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLA5iAQ025132; Wed, 21 Dec 2005 11:05:44 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLA5AhU024947; Wed, 21 Dec 2005 11:05:10 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBLA59j6025808; Wed, 21 Dec 2005 11:05:09 +0100 (MET) Date: Wed, 21 Dec 2005 11:05:08 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Dan Brotsky cc: Julian Reschke , =?iso-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Jim Whitehead , WebDav WG In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Wed, 21 Dec 2005 11:05:13 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (maggie.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ep0rD-0007aJ-A9 3866d59c8c1e407c037fc0e2f6a4cc4d X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512211057420.25324@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11281 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 10:06:20 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2005, Dan Brotsky wrote: > >> Depends on what the target platform is. Apache is built on >> top of APR, (Apache Portable Runtime) as I recall, and that >> API may not have a guarantee of a higher timer resolution. >> What would be your proposal to the Apache guys how to handle that? > > I gave one below. > >> Second, even in filesystems with millisecond resolutions, >> all the filesystem has to do is support exclusive >> write-locking and you can build a compliant server. The >> server must simply keep the file locked long enough to avoid >> the milllisecond window and then set the time back to the >> write time in order to ensure that any interference is noticeable. >> >> You mean "second" resolution, right? > > No, I meant millisecond. Perhaps you are sugggesting that APR only suppo= rts 1-second resolution? Why would that be? I know of no filesystems with= that kind of resolution. Well, the issue started with Apache using weak ETags, then strong ones.=20 Note that the ETag is an opaque string, the way it is computed is up to=20 the server. If a server want to use the md5 sum as the ETag, it is=20 entirely possible, the choice to use the timestamp and length is part of=20 Apache's design. Try to use "ContentDigest on" on big files and you will=20 understand why. My server knows how to handle x !=3D GET(PUT(x)) for subsequent revision=20 (well because cvs knows), it handles itself the issue, without any need=20 from the client to know what's really going on behind the scene. The discussion boils down to: After a PUT, is it safe to continue to edit the resource without doing=20 a reload? And the server should give the answer. 205 if it is not safe, 204=20 otherwise, with the ETag that someone will get in a subsequent GET. > Yes: stop returning weak etags. See above. "on PUT". Agreed. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Wed Dec 21 05:11:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep0wH-0005yz-GL for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:11:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19111 for ; Wed, 21 Dec 2005 05:10:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep0ul-0006Mk-Ka for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 10:09:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep0ui-0006M3-2m for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 10:09:40 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep0ue-0007Bb-Tt for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 10:09:39 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLA9MIS026527; Wed, 21 Dec 2005 11:09:22 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLA8vSv026407; Wed, 21 Dec 2005 11:08:57 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBLA8u8Z025836; Wed, 21 Dec 2005 11:08:56 +0100 (MET) Date: Wed, 21 Dec 2005 11:08:56 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Lisa Dusseault cc: Dan Brotsky , w3c-dist-auth@w3.org, Geoffrey M Clemm In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Wed, 21 Dec 2005 11:09:00 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Ep0ue-0007Bb-Tt b01e2bbb356f3bde65770987958f57e5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512211107020.25324@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11282 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 10:09:43 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2005, Lisa Dusseault wrote: > In this case, multiple PUT without intermediate GET is OK to do -- the se= rver=20 > is prepared to make the same changes on each PUT and doesn't really need = the=20 > client to re-synchronize their changes. There are other cases like some= =20 > CalDAV cases where the server adds an internal event identifier or altern= ate=20 > address to the event. I'd also bet that there are clients that already d= o=20 > multiple PUT requests without intermediate GETs especially if the client= =20 > holds a lock. But if in some cases the server needs the client to do a G= ET=20 > between two subsequent PUTs because the changes are important to preserve= ,=20 > how can the server accomplish that? How about reusing 205 (Reset Content) when the server knows a subsequent=20 PUT would be harmful? --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Wed Dec 21 05:13:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep0yZ-0007Xb-Cp for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:13:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19436 for ; Wed, 21 Dec 2005 05:12:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep0xC-000784-2o for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 10:12:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep0x9-00077W-Ku for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 10:12:11 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep0x6-0008Oi-Tu for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 10:12:11 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLABuQK027516; Wed, 21 Dec 2005 11:11:56 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBLABYNB027400; Wed, 21 Dec 2005 11:11:34 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBLABXCN025902; Wed, 21 Dec 2005 11:11:33 +0100 (MET) Date: Wed, 21 Dec 2005 11:11:33 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Ted Hardie cc: Julian Reschke , Jim Whitehead , Cullen Jennings , WebDav In-Reply-To: Message-ID: References: <03C3B88B-DC1B-42E5-934D-D34B000FBAF1@cs.ucsc.edu> <43A73936.6020806@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Wed, 21 Dec 2005 11:11:35 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (lisa.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Ep0x6-0008Oi-Tu 274129b985ae46683c20b5bb77b829ec X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512211109590.25324@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11283 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 10:12:14 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 19 Dec 2005, Ted Hardie wrote: > At 12:09 AM +0100 12/20/05, Yves Lafon wrote: >> >> >> My implementation returns the ETag that asubsequent GET would see, so=20 >> option (2). Ans I am in the case where the PUT entity and the served=20 >> entity will not be the same, as there are CVS actions done during the=20 >> PUT, so possible keyword extensions, etc... > > Are these property changes, or changes to the entity itself? If to the= =20 > entity, how does a get-range work? To the entity itself, a GET-range based on what has been PUT will=20 obiouvsly fail (but it can fail for many other reason, like going through= =20 a proxy cache that goes offline between the PUT and the GET and serv stale= =20 content). --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Wed Dec 21 06:15:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep1wU-0000Tr-Kc for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 06:15:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25451 for ; Wed, 21 Dec 2005 06:14:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep1uX-0000OT-Nl for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 11:13:33 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep1uM-0000Mm-5f for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 11:13:22 +0000 Received: from pd95b23e9.dip0.t-ipconnect.de ([217.91.35.233] helo=joe.greenbytes.de) by aji.w3.org with esmtp (Exim 4.50) id 1Ep1sz-0001Fn-SS for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 11:13:21 +0000 Received: from [192.168.1.3] (H18e6.h.pppool.de [85.72.24.230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 9453D33D2B; Wed, 21 Dec 2005 12:17:05 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <725bbae5d6ae6cc178b3eb62ebb812f7@greenbytes.de> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Stefan Eissing Date: Wed, 21 Dec 2005 12:11:45 +0100 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: none (aji.w3.org: domain of stefan.eissing@greenbytes.de does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep1sz-0001Fn-SS f54e729d84607639f93d61ea4fc9e2df X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/725bbae5d6ae6cc178b3eb62ebb812f7@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11284 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 11:13:33 +0000 Content-Transfer-Encoding: quoted-printable Am 20.12.2005 um 21:42 schrieb Geoffrey M Clemm: > Stefan Eissing wrote on 12/20/2005=20 > 11:58:01 AM: > > Case b) seems to be what you mean with "substantive" changes. My > > interpretation would be that the server shall either be silent with > > regards to ETAG on the PUT response. And that a client which does=20= > not > > see an ETAG in a PUT response, should make a GET afterwards. If it > > wants to avoid concurrent updates, it could lock the resource just=20= > for > > the PUT with subsequent GET. > > If the server includes the etag corresponding to the PUT content, > standard If-Match and If-None-Match processing works properly. =A0 > Isn't supporting the standard semantics better than hoping clients = will > interpret the absence of an etag header in a certain way? I was looking for a way to tell the client that it has to refetch the=20 content. If the server just answers with a temp ETAG, the client will=20 find out on the next PUT that "someone" changed the content and=20 probably needs to ask its user what to do about it. Yves proposed 205 answer however sounds like a much better approach. //Stefan= From w3c-dist-auth-request@frink.w3.org Wed Dec 21 09:20:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep4p9-0003NZ-Ps for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 09:20:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18552 for ; Wed, 21 Dec 2005 09:19:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep4nD-0006c3-Ch for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 14:18:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep4n0-0006ao-AD for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 14:17:58 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep4ml-0001Bh-Pe for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 14:17:57 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLEHQHH025870 for ; Wed, 21 Dec 2005 09:17:26 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLEHQQ6120270 for ; Wed, 21 Dec 2005 09:17:26 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLEHPRJ010467 for ; Wed, 21 Dec 2005 09:17:25 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLEHP1f010440 for ; Wed, 21 Dec 2005 09:17:25 -0500 In-Reply-To: <725bbae5d6ae6cc178b3eb62ebb812f7@greenbytes.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 09:17:22 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 09:17:25, Serialize complete at 12/21/2005 09:17:25 Content-Type: multipart/alternative; boundary="=_alternative 004E7E0C852570DE_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Ep4ml-0001Bh-Pe dfa550375ee72feaf6ea817ca135c299 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF0E85A15F.C0E4E1A2-ON852570DE.004E21CB-852570DE.004E7EA4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11285 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 14:18:11 +0000 This is a multipart message in MIME format. --=_alternative 004E7E0C852570DE_= Content-Type: text/plain; charset="US-ASCII" I agree that returning a 205 is a good way to signal this. But I also maintain that returning a 205 *and* returning an ETAG for the PUT content is even better, since existing clients that use If-Match and If-None-Match (and don't know about the new 205 convention) will work properly. Was there some reason why you thought returning a 205 and not returning an ETAG was preferable? Cheers, Geoff Stefan Eissing wrote on 12/21/2005 06:11:45 AM: > > Am 20.12.2005 um 21:42 schrieb Geoffrey M Clemm: > > Stefan Eissing wrote on 12/20/2005 > > 11:58:01 AM: > > > Case b) seems to be what you mean with "substantive" changes. My > > > interpretation would be that the server shall either be silent with > > > regards to ETAG on the PUT response. And that a client which does > > not > > > see an ETAG in a PUT response, should make a GET afterwards. If it > > > wants to avoid concurrent updates, it could lock the resource just > > for > > > the PUT with subsequent GET. > > > > If the server includes the etag corresponding to the PUT content, > > standard If-Match and If-None-Match processing works properly. > > Isn't supporting the standard semantics better than hoping clients will > > interpret the absence of an etag header in a certain way? > > I was looking for a way to tell the client that it has to refetch the > content. If the server just answers with a temp ETAG, the client will > find out on the next PUT that "someone" changed the content and > probably needs to ask its user what to do about it. > > Yves proposed 205 answer however sounds like a much better approach. > > //Stefan --=_alternative 004E7E0C852570DE_= Content-Type: text/html; charset="US-ASCII"
I agree that returning a 205 is a good way to signal this.

But I also maintain that returning a 205 *and* returning an
ETAG for the PUT content is even better, since existing clients
that use If-Match and If-None-Match (and don't know about the
new 205 convention) will work properly.

Was there some reason why you thought returning a 205 and
not returning an ETAG was preferable?

Cheers,
Geoff

Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/21/2005 06:11:45 AM:

>
> Am 20.12.2005 um 21:42 schrieb Geoffrey M Clemm:
> > Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/20/2005
> > 11:58:01 AM:
> >  > Case b) seems to be what you mean with "substantive" changes. My
> >  > interpretation would be that the server shall either be silent with
> >  > regards to ETAG on the PUT response. And that a client which does
> > not
> >  > see an ETAG in a PUT response, should make a GET afterwards. If it
> >  > wants to avoid concurrent updates, it could lock the resource just
> > for
> >  > the PUT with subsequent GET.
> >
> > If the server includes the etag corresponding to the PUT content,
> > standard If-Match and If-None-Match processing works properly.  
> > Isn't supporting the standard semantics better than hoping clients will
> > interpret the absence of an etag header in a certain way?
>
> I was looking for a way to tell the client that it has to refetch the
> content. If the server just answers with a temp ETAG, the client will
> find out on the next PUT that "someone" changed the content and
> probably needs to ask its user what to do about it.
>
> Yves proposed 205 answer however sounds like a much better approach.
>
> //Stefan
 --=_alternative 004E7E0C852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 09:58:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5Pw-0001Su-6l for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 09:58:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25040 for ; Wed, 21 Dec 2005 09:57:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep5OH-00017n-JI for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 14:56:29 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep5O1-00013w-Vh for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 14:56:14 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Ep5Ny-0000XZ-Dy for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 14:56:12 +0000 Received: (qmail invoked by alias); 21 Dec 2005 14:55:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 21 Dec 2005 15:55:44 +0100 X-Authenticated: #1915285 Message-ID: <43A96C93.2080908@gmx.de> Date: Wed, 21 Dec 2005 15:54:11 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: Lisa Dusseault , w3c-dist-auth@w3.org, Geoffrey M Clemm References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ep5Ny-0000XZ-Dy db13afda6eb96bb99853798539ac50c4 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A96C93.2080908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11286 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 14:56:29 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: > As to your last question: Yes it's OK and no the server needs to break > the lock if it does this (because it's indistinguishable from another > client's edit). Not all clients will work efficiently against servers > that unexpectedly munge data after PUTs are complete but that's life. For the record: I think that linking the ETag behavior for PUT to the fact whether the resource was locked or not would be a really bad idea. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 21 09:59:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5R8-0001wz-8D for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 09:59:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25342 for ; Wed, 21 Dec 2005 09:58:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep5Pm-0001JU-7z for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 14:58:02 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep5Ph-0001It-IU for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 14:57:57 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1Ep5PU-0007EC-48 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 14:57:56 +0000 Received: (qmail invoked by alias); 21 Dec 2005 14:57:38 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 21 Dec 2005 15:57:38 +0100 X-Authenticated: #1915285 Message-ID: <43A96D05.2060808@gmx.de> Date: Wed, 21 Dec 2005 15:56:05 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: Geoffrey M Clemm , webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep5PU-0007EC-48 615e38ece9d88f19549ca1e341343445 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A96D05.2060808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11287 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 14:58:02 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: > Ah, now I begin to understand what I believe is a big misimpression on > the part of the server authors. (Sadly, I see almost no client authors > in these discussions anymore, which has been a big part of my problem > with the WebDAV process forever and why I've been quiet for so long now.) Dan, it's good that you're back here. At least Apple and ourselves (remember, we also have a client) are following this as well. Of course it would be good if Microsoft was around here as well :-). > Folks, clients are perfectly well aware that servers munge data when > they store it. It's *way* outside the scope of WebDAV to try and match > up the server-munging semantics with clients that rely on those > semantics. If you are a client that's looking for a faithful dumb store > and you stumble across a CVS-backed webdav server that does keyword > expansion to your graphics files, you will figure this out quickly and > stop using that server. That doesn't mean it's not a WebDAV-compliant > server, just not one with the store semantics you were expecting. > > Similarly, if you are a client expecting a CVS server and you use a > file-backed Apache server, it also won't meet your needs. But it's > still WebDAV-compliant. > > The point of this effort is to define a greatest common denominator that > can be divided evenly into the semantics of any server that's called > WebDAV compliant. But believe me, every client in the world understands > that there may be extra factors in that server's semantics that are > relatively prime with the client's intent! > > That's a good thing. +1 on that summary. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 21 10:05:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5XB-0000M6-20 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 10:05:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26863 for ; Wed, 21 Dec 2005 10:04:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep5Vl-0004hq-Qd for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 15:04:13 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep5Vb-0004fY-TE for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 15:04:04 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1Ep5VX-0001xu-PF for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 15:04:02 +0000 Received: (qmail invoked by alias); 21 Dec 2005 15:03:57 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 21 Dec 2005 16:03:57 +0100 X-Authenticated: #1915285 Message-ID: <43A96E7F.7060309@gmx.de> Date: Wed, 21 Dec 2005 16:02:23 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: Geoffrey M Clemm , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep5VX-0001xu-PF c3f093ae20b43c2539f35c72a39d8f05 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A96E7F.7060309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11288 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 15:04:13 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: > We're getting closer... :) > >> So let's look at what clients are interested in again: >> >> - they want to avoid fetching an ETag after PUT, > > Yes. > >> - in some cases, they want to be able to find out whether the >> server stored exactly what they sent, > > No. I claim no client wants to know this. Ever. If they really want > to know that the content matches what they have, then they use a server > that supports MD5 hashes and they rely on those. It seems to me that many client implementors want this, because they may want to do Get/Range requests. > If they are worried about network corruption then TCP/IP has things for > that. > >> - if they interleave PUT and PROPPATCH, they want their ETags >> to continue to work. > > Yes. > >> I believe all of these things can be accomplish by protocol >> extensions, and I'll be happy to spec them out. On the other >> hand, I don't think it would be a good idea to rush them into >> RFC2518bis, which was supposed to be finished around this >> time of year (if I may remember). > > I believe all of these things that clients want are accomplished with > what we have, as long as we have servers hand back strong etags on PUT. 1) Servers may not be able to return strong ETags upon PUT. Again, let's consider adding an indicator to PUT that let's the server know the client really needs a strong ETag, so that the server can optimize it's behavior for that case. 2) It seems to me that we can't rule out that servers touch the ETag upon PROPPATCH (for instance, because they are indeed updating metadata in the file content, such as with XMP). In which case telling the server to return the new ETag upon PUT seems to be a very good idea. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 21 10:28:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep5sq-0000sS-JH for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 10:28:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29970 for ; Wed, 21 Dec 2005 10:26:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep5r7-00033l-9i for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 15:26:17 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep5qu-00031G-HB for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 15:26:04 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Ep5ql-0004WA-Jv for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 15:26:03 +0000 Received: (qmail invoked by alias); 21 Dec 2005 15:24:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 21 Dec 2005 16:24:39 +0100 X-Authenticated: #1915285 Message-ID: <43A97355.9020808@gmx.de> Date: Wed, 21 Dec 2005 16:23:01 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , Jim Whitehead , WebDav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ep5ql-0004WA-Jv 3ba23b19f34c083b89b9d88b2dcd61e7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A97355.9020808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11289 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 15:26:17 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: >> Depends on what the target platform is. Apache is built on >> top of APR, (Apache Portable Runtime) as I recall, and that >> API may not have a guarantee of a higher timer resolution. >> What would be your proposal to the Apache guys how to handle that? > > I gave one below. Sorry, I don't understand what your proposal exactly is. >> Second, even in filesystems with millisecond resolutions, >> all the filesystem has to do is support exclusive >> write-locking and you can build a compliant server. The >> server must simply keep the file locked long enough to avoid >> the milllisecond window and then set the time back to the >> write time in order to ensure that any interference is noticeable. >> >> You mean "second" resolution, right? > > No, I meant millisecond. Perhaps you are sugggesting that APR only supports 1-second resolution? Why would that be? I know of no filesystems with that kind of resolution. I'm not sure why that would be, but the code in http_etag.c certainly uses a hardwired constant for this. Maybe this is fixable, in which case the problem would go away. Wilfredo? >> Two problems here: >> >> 1) Doing that may not be acceptable for mass uploads, where >> millions of documents need to be uploaded (don't tell me this >> isn't a use case...). > > Sure it's a use case. But you don't explain why it's not acceptable. On a fast link, it would slow down mass uploads unacceptably. >> 2) Even then, it's not that simple. ETag and Last-Modified >> also have to be adjusted after COPY and notably MOVE (!). > > It's exactly that simple. Because COPY and MOVE don't suffer the non-interference problem (on the target, that is), because the target doesn't exist for someone to have open. I'm not sure I understand this. Let's try again; the considerations for generating valid ETags apply to all methods that change URL mappings (COPY, MOVE, PUT) as well. Are you disagreeing with that? > ... > No, I take that as an indication that everyone agrees that this bug is only there conceptually and that it never actually occurs in the field. I know for a fact that the Adobe client implementations just ignored the weak marking on the etag and that's why they were interoperable with Apache. > >> So, Dan, can you make a concrete proposal how to change Apache/moddav? > > Yes: stop returning weak etags. See above. So instead return nothing at all, or a strong one? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:05:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Su-0001fg-Ti for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:05:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07216 for ; Wed, 21 Dec 2005 11:04:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6RU-0006Zp-Ck for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:03:52 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6RF-0006Xf-NL for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:03:38 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep6QR-0005To-WE for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:03:36 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLG2hVp021451 for ; Wed, 21 Dec 2005 11:02:43 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLG2hQ6079122 for ; Wed, 21 Dec 2005 11:02:43 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLG2hie011040 for ; Wed, 21 Dec 2005 11:02:43 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLG2hWx011034 for ; Wed, 21 Dec 2005 11:02:43 -0500 In-Reply-To: <43A96E7F.7060309@gmx.de> To: Julian Reschke Cc: Dan Brotsky , w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 11:02:43 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 11:02:43, Serialize complete at 12/21/2005 11:02:43 Content-Type: multipart/alternative; boundary="=_alternative 005822FC852570DE_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1Ep6QR-0005To-WE e1c3a25ecba61c8587926a7124cd848c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF2EB54D6D.B6FE006C-ON852570DE.0057CBBF-852570DE.005823C3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11290 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:03:52 +0000 This is a multipart message in MIME format. --=_alternative 005822FC852570DE_= Content-Type: text/plain; charset="US-ASCII" Julian Reschke wrote on 12/21/2005 10:02:23 AM: > Dan Brotsky wrote: > > I believe all of these things that clients want are accomplished with > > what we have, as long as we have servers hand back strong etags on PUT. > > 1) Servers may not be able to return strong ETags upon PUT. Again, let's > consider adding an indicator to PUT that let's the server know the > client really needs a strong ETag, so that the server can optimize it's > behavior for that case. I agree. > 2) It seems to me that we can't rule out that servers touch the ETag > upon PROPPATCH (for instance, because they are indeed updating metadata > in the file content, such as with XMP). In which case telling the server > to return the new ETag upon PUT seems to be a very good idea. Did you mean, return the new ETag upon PROPPATCH? Cheers, Geoff --=_alternative 005822FC852570DE_= Content-Type: text/html; charset="US-ASCII"

Julian Reschke <julian.reschke@gmx.de> wrote on 12/21/2005 10:02:23 AM:

> Dan Brotsky wrote:

> > I believe all of these things that clients want are accomplished with
> > what we have, as long as we have servers hand back strong etags on PUT.
>
> 1) Servers may not be able to return strong ETags upon PUT. Again, let's
> consider adding an indicator to PUT that let's the server know the
> client really needs a strong ETag, so that the server can optimize it's
> behavior for that case.

I agree.

> 2) It seems to me that we can't rule out that servers touch the ETag
> upon PROPPATCH (for instance, because they are indeed updating metadata
> in the file content, such as with XMP). In which case telling the server
> to return the new ETag upon PUT seems to be a very good idea.

Did you mean, return the new ETag upon PROPPATCH?

Cheers,
Geoff

--=_alternative 005822FC852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:10:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6Xz-0003ua-QV for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:10:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08238 for ; Wed, 21 Dec 2005 11:09:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6Wg-0007Zc-0M for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:09:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6Wb-0007Z4-E8 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:09:09 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Ep6WX-0005Zd-PK for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:09:08 +0000 Received: (qmail invoked by alias); 21 Dec 2005 16:08:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 21 Dec 2005 17:08:37 +0100 X-Authenticated: #1915285 Message-ID: <43A97DA4.5080105@gmx.de> Date: Wed, 21 Dec 2005 17:07:00 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Geoffrey M Clemm CC: Dan Brotsky , w3c-dist-auth@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Ep6WX-0005Zd-PK d7b973078d313668f8cd5d0bf87c1307 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43A97DA4.5080105@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11291 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:09:14 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > Julian Reschke wrote on 12/21/2005 10:02:23 AM: > > > Dan Brotsky wrote: > > > > I believe all of these things that clients want are accomplished with > > > what we have, as long as we have servers hand back strong etags on PUT. > > > > 1) Servers may not be able to return strong ETags upon PUT. Again, let's > > consider adding an indicator to PUT that let's the server know the > > client really needs a strong ETag, so that the server can optimize it's > > behavior for that case. > > I agree. > > > 2) It seems to me that we can't rule out that servers touch the ETag > > upon PROPPATCH (for instance, because they are indeed updating metadata > > in the file content, such as with XMP). In which case telling the server > > to return the new ETag upon PUT seems to be a very good idea. > > Did you mean, return the new ETag upon PROPPATCH? Yep. Thanks for the correction :-) From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6e2-0007RU-9n for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:16:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09069 for ; Wed, 21 Dec 2005 11:15:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6cV-0001Ty-Vc for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:15:16 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6cQ-00018M-F4 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:15:10 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep6cH-0007yW-UW for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:15:09 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGEdfJ001910 for ; Wed, 21 Dec 2005 11:14:39 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLGEdQ6086098 for ; Wed, 21 Dec 2005 11:14:39 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLGEcIw028387 for ; Wed, 21 Dec 2005 11:14:38 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGEcWO028377 for ; Wed, 21 Dec 2005 11:14:38 -0500 In-Reply-To: <43A97DA4.5080105@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 11:14:35 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 11:14:38, Serialize complete at 12/21/2005 11:14:38 Content-Type: multipart/alternative; boundary="=_alternative 005939A6852570DE_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep6cH-0007yW-UW a34097019dea5733415d78858d3c924f X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFDAAE9732.7E0F1D82-ON852570DE.00590D8F-852570DE.00593A1E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11292 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:15:15 +0000 This is a multipart message in MIME format. --=_alternative 005939A6852570DE_= Content-Type: text/plain; charset="US-ASCII" Julian Reschke wrote on 12/21/2005 11:07:00 AM: > Geoffrey M Clemm wrote: > > Julian Reschke wrote on 12/21/2005 10:02:23 AM: > > > 2) It seems to me that we can't rule out that servers touch the ETag > > > upon PROPPATCH (for instance, because they are indeed updating metadata > > > in the file content, such as with XMP). In which case telling the server > > > to return the new ETag upon PUT seems to be a very good idea. > > > > Did you mean, return the new ETag upon PROPPATCH? > > Yep. Thanks for the correction :-) In that case, yes, I agree. Also note that there is no issue wrt PUT-content vs. GET-content for PROPPATCH, so that happily that issue does not arise for a PROPPATCH etag (:-). Cheers, Geoff --=_alternative 005939A6852570DE_= Content-Type: text/html; charset="US-ASCII"
Julian Reschke <julian.reschke@gmx.de> wrote on 12/21/2005 11:07:00 AM:

> Geoffrey M Clemm wrote:
> > Julian Reschke <julian.reschke@gmx.de> wrote on 12/21/2005 10:02:23 AM:
> >  > 2) It seems to me that we can't rule out that servers touch the ETag
> >  > upon PROPPATCH (for instance, because they are indeed updating metadata
> >  > in the file content, such as with XMP). In which case telling the server
> >  > to return the new ETag upon PUT seems to be a very good idea.
> >
> > Did you mean, return the new ETag upon PROPPATCH?
>
> Yep. Thanks for the correction :-)
In that case, yes, I agree.

Also note that there is no issue wrt PUT-content vs. GET-content for
PROPPATCH, so that happily that issue does not arise for a PROPPATCH
etag (:-).

Cheers,
Geoff
  --=_alternative 005939A6852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:22:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6ju-0001Af-KQ for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:22:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09953 for ; Wed, 21 Dec 2005 11:21:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6iS-0003rw-HP for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:21:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6iK-0003qD-Du for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:21:16 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep6iB-00021e-Lu for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:21:15 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGKklx012433 for ; Wed, 21 Dec 2005 11:20:46 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLGKkgh122166 for ; Wed, 21 Dec 2005 11:20:46 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLGKkXI016837 for ; Wed, 21 Dec 2005 11:20:46 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGKkuW016830 for ; Wed, 21 Dec 2005 11:20:46 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 11:20:44 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 11:20:45, Serialize complete at 12/21/2005 11:20:45 Content-Type: multipart/alternative; boundary="=_alternative 0059C996852570DE_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep6iB-00021e-Lu 227ba25a7439e431004cb98530f74426 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFB4AA8660.C7DEB4A3-ON852570DE.00595B52-852570DE.0059CA1D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11293 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:21:24 +0000 This is a multipart message in MIME format. --=_alternative 0059C996852570DE_= Content-Type: text/plain; charset="US-ASCII" I like Dan's answer better than mine, so I switch my vote to what Dan says below. Cheers, Geoff Dan wrote on 12/21/2005 01:33:37 AM: > > As to your last question: Yes it's OK and no the server needs to break > the lock if it does this (because it's indistinguishable from another > client's edit). Not all clients will work efficiently against servers > that unexpectedly munge data after PUTs are complete but that's life. > > dan > > > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > > - If the server is making changes that must be preserved, > > ... we'd also > > have to specify whether it's OK to do this while the client > > is holding a LOCK. --=_alternative 0059C996852570DE_= Content-Type: text/html; charset="US-ASCII"
I like Dan's answer better than mine, so I switch my vote to what Dan
says below.

Cheers,
Geoff


Dan wrote on 12/21/2005 01:33:37 AM:
>
> As to your last question: Yes it's OK and no the server needs to break
> the lock if it does this (because it's indistinguishable from another
> client's edit).  Not all clients will work efficiently against servers
> that unexpectedly munge data after PUTs are complete but  that's life.
>
>     dan
>
> > From: Lisa Dusseault [mailto:lisa@osafoundation.org]

> >   - If the server is making changes that must be preserved,
> > ... we'd also
> > have to specify whether it's OK to do this while the client
> > is holding a LOCK.
 --=_alternative 0059C996852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:28:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6pb-0003cV-Tp for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:28:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10784 for ; Wed, 21 Dec 2005 11:27:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6nu-0005m9-Um for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:27:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6nq-0005kk-9J for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:26:58 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep6nm-0005fq-EM for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:26:58 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGQrIQ009749 for ; Wed, 21 Dec 2005 11:26:53 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLGQrQ6123144 for ; Wed, 21 Dec 2005 11:26:53 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLGQqYR024742 for ; Wed, 21 Dec 2005 11:26:52 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLGQq4Q024739 for ; Wed, 21 Dec 2005 11:26:52 -0500 In-Reply-To: <43A96C93.2080908@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 11:26:51 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 11:26:52, Serialize complete at 12/21/2005 11:26:52 Content-Type: multipart/alternative; boundary="=_alternative 005A5918852570DE_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep6nm-0005fq-EM 7138564b2518c86ab7cab491d6e50d16 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OFB6B4D535.63DAA71A-ON852570DE.005A1388-852570DE.005A5956@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11294 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:27:02 +0000 This is a multipart message in MIME format. --=_alternative 005A5918852570DE_= Content-Type: text/plain; charset="US-ASCII" Julian wrote on 12/21/2005 09:54:11 AM: > > Dan Brotsky wrote: > > As to your last question: Yes it's OK and no the server needs to break > > the lock if it does this (because it's indistinguishable from another > > client's edit). Not all clients will work efficiently against servers > > that unexpectedly munge data after PUTs are complete but that's life. > > For the record: I think that linking the ETag behavior for PUT to the > fact whether the resource was locked or not would be a really bad idea. Julian: I agree with you, but did you think Dan was suggesting otherwise, or were you just agreeing with Dan's statement (or at least, with the "yes, it's OK" part)? I am assuming that you were not disagreeing with Dan, since I don't believe he suggests anything that would make ETag behavior depend on whether the resource was locked or not. Cheers, Geoff --=_alternative 005A5918852570DE_= Content-Type: text/html; charset="US-ASCII"
Julian wrote on 12/21/2005 09:54:11 AM:
>
> Dan Brotsky wrote:
> > As to your last question: Yes it's OK and no the server needs to break
> > the lock if it does this (because it's indistinguishable from another
> > client's edit).  Not all clients will work efficiently against servers
> > that unexpectedly munge data after PUTs are complete but  that's life.
>
> For the record: I think that linking the ETag behavior for PUT to the
> fact whether the resource was locked or not would be a really bad idea.
Julian: I agree with you, but did you think Dan was suggesting otherwise,
or were you just agreeing with Dan's statement (or at least, with the
"yes, it's OK" part)?   I am assuming that you were not disagreeing
with Dan, since I don't believe he suggests anything that would make ETag
behavior depend on whether the resource was locked or not.

Cheers,
Geoff

--=_alternative 005A5918852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:31:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep6sP-0004aU-PK for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:31:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11337 for ; Wed, 21 Dec 2005 11:30:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep6r6-000794-AN for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:30:20 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep6r0-0006vp-Je for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:30:15 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep6qt-0002Fi-8C for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 16:30:13 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 86A911422B1; Wed, 21 Dec 2005 09:32:39 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-10-109093566 Message-Id: Cc: " webdav" , "Geoffrey M Clemm" From: Lisa Dusseault Date: Wed, 21 Dec 2005 08:29:59 -0800 To: "Dan Brotsky" X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep6qt-0002Fi-8C baa0f9af319b4142e7fcd071b55e9118 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/caa84c1fb7f59151e8b606fd99e22619@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11295 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:30:20 +0000 --Apple-Mail-10-109093566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hey Dan, I'm a client developer now and Chandler definitely cares about=20= both optimistic locking and caching :) We want to be able to share=20 collections of arbitrary files between users, but those collections=20 should also be accessible offline. The client can be responsible for=20 merging content in case there's already a change to a cached resource=20 changed while offline. Lisa On Dec 20, 2005, at 10:22 PM, Dan Brotsky wrote: > > The last part is important for a WebDAV client, since it wants to = use > > ETAG for optimistic =A0locking. It is not really interested in ETAG = for > > caching purposes. > > Actually, I think a WebDAV client cares about both optimistic locking > and caching.=A0=A0=A0 > =A0 > I strongly disagree.=A0 I think the first author's statement is = correct. > =A0 > =A0Also note that they are rather intimately linked, since > optimistic locking is based on knowing that the client's edits are=20 > based on the > text that is currently on the server, while caching is based on = knowing > that what the client currently has is based on the text that is=20 > currently on > the server.=A0=A0 > =A0 > No.=A0 Optimistic locking=A0is based on knowing that the client's = edits=20 > are being applied to the content the client last sent to the server,=20= > and are not overwriting other client's edits.=A0 Caching is based=A0on=20= > knowing that the content you *last received* is the same as what you=20= > *would receive* on your next get. > =A0 > HTTP clients, whether webdav or not, know they must have *received*=20 > the content associated with an etag in order to avoid fetching it=20 > again.=A0 That's caching. > =A0 > WebDAV clients only need to know that they *sent* the content=20 > associated with an etag in order to avoid overwriting someone else's=20= > edits.=A0 That's optimistic locking. > =A0 > =A0=A0=A0 dan > =A0 --Apple-Mail-10-109093566 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Dan, I'm a client developer now and Chandler definitely cares about both optimistic locking and caching :) We want to be able to share collections of arbitrary files between users, but those collections should also be accessible offline. The client can be responsible for merging content in case there's already a change to a cached resource changed while offline. =20 Lisa On Dec 20, 2005, at 10:22 PM, Dan Brotsky wrote: > The last part is important for a WebDAV client, since it wants to use > ETAG for optimistic =A0locking. It is not really interested in ETAG for > caching purposes. Actually, I think a WebDAV client cares about both optimistic locking=20 and = caching.=A0=A0Arial0000,0= 000,FFFF=A0 =A0 = Arial0000,0000,FFFFI strongly disagree.=A0 I think the first author's statement is = correct. =A0 =A0Also note that they are rather intimately linked, since=20 optimistic locking is based on knowing that the client's edits are based on the=20 text that is currently on the server, while caching is based on knowing=20 that what the client currently has is based on the text that is currently on=20 the = server.=A0Arial<= param>0000,0000,FFFF=A0 =A0 = Arial0000,0000,FFFFNo.=A0 Optimistic locking=A0is based on knowing that the client's edits are being applied to the content the client last sent to the server, and are not overwriting other client's edits.=A0 Caching is = based=A0Arial0000,0000,FFFFon knowing that the content you *last received* is the same as what you *would receive* on your next get. =A0 = Arial0000,0000,FFFFHTTP clients, whether webdav or not, know they must have *received* the content associated with an etag in order to avoid fetching it again.=A0 That's caching. =A0 = Arial0000,0000,FFFFWebDAV clients only need to know that they *sent* the content associated with an etag in order to avoid overwriting someone else's edits.=A0 That's optimistic locking. =A0 = Arial0000,0000,FFFF=A0=A0=A0 dan =A0 = --Apple-Mail-10-109093566-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 11:43:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep73a-0001jY-Ix for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:43:14 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13156 for ; Wed, 21 Dec 2005 11:42:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep722-00033p-OL for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 16:41:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep71u-00031U-N8 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 16:41:30 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep6yX-0002TD-Jq; Wed, 21 Dec 2005 16:41:29 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0453D1422DA; Wed, 21 Dec 2005 09:40:33 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26dcc10da7f6145cb2ce36510ce9e206@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDav WG From: Lisa Dusseault Date: Wed, 21 Dec 2005 08:37:54 -0800 To: Yves Lafon X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Ep6yX-0002TD-Jq 5e92df1595e13d4325b5cd46a633d127 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/26dcc10da7f6145cb2ce36510ce9e206@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11296 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 16:41:38 +0000 Content-Transfer-Encoding: 7bit On Dec 21, 2005, at 2:05 AM, Yves Lafon wrote: > > The discussion boils down to: > After a PUT, is it safe to continue to edit the resource without doing > a reload? > And the server should give the answer. 205 if it is not safe, 204 > otherwise, with the ETag that someone will get in a subsequent GET. > Thanks Yves, I can't believe nobody noticed the relevance of 205 earlier in these discussions. It would indeed be a good response to use and could even include an ETag if we define what that means. Lisa From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:05:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8Ks-0003Nv-GB for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:05:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24547 for ; Wed, 21 Dec 2005 13:04:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8Iv-0001a0-HE for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:03:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8Ij-0001YF-1E for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:02:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8If-00087N-4S for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:02:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLI2oeZ014875; Wed, 21 Dec 2005 10:02:50 -0800 Date: Wed, 21 Dec 2005 10:02:50 -0800 Message-Id: <200512211802.jBLI2oeZ014875@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8If-00087N-4S 23b66d688968da7ad14ab8ae02e2bd1a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512211802.jBLI2oeZ014875@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11297 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:03:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 10:02 ------- Rough consensus reached during 12/21 telecon to move historical discussion to an appendix treating lock-null resources. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:05:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8Ks-0003Nw-I8 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:05:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24548 for ; Wed, 21 Dec 2005 13:04:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8JT-0001cB-2y for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:03:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8JO-0001bN-Q9 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:03:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep8JG-0005nh-CB for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:03:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLI3Sws014911; Wed, 21 Dec 2005 10:03:28 -0800 Date: Wed, 21 Dec 2005 10:03:28 -0800 Message-Id: <200512211803.jBLI3Sws014911@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep8JG-0005nh-CB c85b70fd1a538c630ed03944ca9b6945 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512211803.jBLI3Sws014911@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11298 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:03:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:21:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8aw-0001Rs-CR for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:21:46 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26788 for ; Wed, 21 Dec 2005 13:20:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8Z7-0006qO-Vk for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:19:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8Z4-0006pH-Vt for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:19:51 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8Yx-0005w7-4c for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:19:50 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIJW5J014944; Wed, 21 Dec 2005 10:19:32 -0800 Date: Wed, 21 Dec 2005 10:19:32 -0800 Message-Id: <200512211819.jBLIJW5J014944@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8Yx-0005w7-4c 322a607e2f35909b079b42ce6b0cfaea X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 198] LOCK_ISSUES_SHARED_LOCKS X-Archived-At: http://www.w3.org/mid/200512211819.jBLIJW5J014944@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11299 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:19:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=198 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 10:19 ------- The existing text (section 6.1) seems to offer satisfactory explanation for the existence of lock-null resources, and additional justification regarding shared editing sessions was provided in the 12/21 telecon. Rather than add additional justification to 2518-bis, we are going to let this issue lie and resolve it as a 'WONTFIX'. Further, the issue of /shared read locks/ is beyond the scope of the current WG charter to finish 2518-bis... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:26:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8fr-000394-AZ for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:26:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27844 for ; Wed, 21 Dec 2005 13:25:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8eG-0008Dt-1h for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:25:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8e9-0008Cc-EP for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:25:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8e3-0007jD-O8 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:25:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIOT0p014974; Wed, 21 Dec 2005 10:24:29 -0800 Date: Wed, 21 Dec 2005 10:24:29 -0800 Message-Id: <200512211824.jBLIOT0p014974@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8e3-0007jD-O8 e7c5456c1e37f963427e1161ac55342a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512211824.jBLIOT0p014974@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11300 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:25:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 10:24 ------- New direction (again from 12/21 telecon): Lisa to propose spec text that introduces preferred behavior for 'empty locked resources' but allows for olod servers to still be (barely?) compliant... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:29:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8ie-0004Iq-Kk for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:29:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28179 for ; Wed, 21 Dec 2005 13:28:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8hN-00009H-Ve for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:28:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8hL-00008j-MS for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:28:23 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep8hI-0007Qv-4l for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:28:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIS1bf015001; Wed, 21 Dec 2005 10:28:01 -0800 Date: Wed, 21 Dec 2005 10:28:01 -0800 Message-Id: <200512211828.jBLIS1bf015001@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep8hI-0007Qv-4l 019470597c863e36486f379327d66929 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 197] LOCK_ISSUES_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512211828.jBLIS1bf015001@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11301 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:28:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=197 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:32:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8kw-00054O-8b for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:32:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28397 for ; Wed, 21 Dec 2005 13:31:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8jV-0002SZ-Uj for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:30:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8jS-0002Oi-7s for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:30:34 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep8iu-0004hV-7r for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:30:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLITvia015025; Wed, 21 Dec 2005 10:29:57 -0800 Date: Wed, 21 Dec 2005 10:29:57 -0800 Message-Id: <200512211829.jBLITvia015025@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep8iu-0004hV-7r abe66cf856cb4de672c2a9897b8be2cf X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 197] LOCK_ISSUES_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512211829.jBLITvia015025@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11302 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:30:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=197 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 10:29 ------- Julian to split into seperate issues... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:32:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8lM-0005Jr-Ow for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:32:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28426 for ; Wed, 21 Dec 2005 13:31:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8jv-0002UD-0h for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:31:03 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8jq-0002Td-BC for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:30:58 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep8jX-0004w1-4j for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:30:57 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLIUZRV021633 for ; Wed, 21 Dec 2005 13:30:35 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLIUZQ6109882 for ; Wed, 21 Dec 2005 13:30:35 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLIUZl6012841 for ; Wed, 21 Dec 2005 13:30:35 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLIUZY4012834 for ; Wed, 21 Dec 2005 13:30:35 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 13:30:33 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 13:30:34, Serialize complete at 12/21/2005 13:30:34 Content-Type: multipart/alternative; boundary="=_alternative 0065B985852570DE_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1Ep8jX-0004w1-4j c24622cefaa4a918fd1781c42cc20e7e X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF64913BF6.D2A0024F-ON852570DE.0064861F-852570DE.0065B9E6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11303 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:31:03 +0000 This is a multipart message in MIME format. --=_alternative 0065B985852570DE_= Content-Type: text/plain; charset="US-ASCII" "Dan Brotsky" wrote on 12/21/2005 01:22:17 AM: >> I think a WebDAV client cares about both optimistic locking >> and caching. > > I strongly disagree. Like Lisa, our client writers care about both optimistic locking and caching. And I don't think we are the only ones that feel that way. >> Also note that they are rather intimately linked, since >> optimistic locking is based on knowing that the client's edits are >> based on the >> text that is currently on the server, while caching is based on knowing >> that what the client currently has is based on the text that is currently on >> the server. > No. Optimistic locking is based on knowing that the client's edits > are being applied to the content the client last sent to the server, > and are not overwriting other client's edits. Caching is based on > knowing that the content you *last received* is the same as what you > *would receive* on your next get. Our client writers care about all three, i.e. optimistic locking (whose definition we appear to agree on), GET caching (i.e., what you define as caching), and re-use of the content submitted for a PUT (included in my more general definition of caching). > HTTP clients, whether webdav or not, know they must have *received* > the content associated with an etag in order to avoid fetching it > again. That's caching. I am happy to use "caching" to only mean "GET caching" if that's what you prefer, but our clients also care about the more general form of caching that I described, whatever name we use for it. One of the points of this discussion is to determine whether clients should be able to use etags returned by PUT for this other kind of caching. > WebDAV clients only need to know that they *sent* the content > associated with an etag in order to avoid overwriting someone else's > edits. That's optimistic locking. Our WebDAV clients also care about performance, so they also care about caching, not just about optimistic locking. Cheers, Geoff --=_alternative 0065B985852570DE_= Content-Type: text/html; charset="US-ASCII"
"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/21/2005 01:22:17 AM:

>> I think a WebDAV client cares about both optimistic locking
>> and caching.  
>  
> I strongly disagree.

Like Lisa, our client writers care about both optimistic locking
and caching.  And I don't think we are the only ones that feel that way.

>>  Also note that they are rather intimately linked, since
>> optimistic locking is based on knowing that the client's edits are
>> based on the
>> text that is currently on the server, while caching is based on knowing
>> that what the client currently has is based on the text that is currently on
>> the server.  
 
> No.  Optimistic locking is based on knowing that the client's edits
> are being applied to the content the client last sent to the server,
> and are not overwriting other client's edits.  Caching is based on
> knowing that the content you *last received* is the same as what you
> *would receive* on your next get.

Our client writers care about all three, i.e. optimistic locking (whose
definition we appear to agree on), GET caching (i.e., what you define as
caching), and re-use of the content submitted for a PUT (included in my
more general definition of caching).

> HTTP clients, whether webdav or not, know they must have *received*
> the content associated with an etag in order to avoid fetching it
> again.  That's caching.

I am happy to use "caching" to only mean "GET caching"
if that's what you prefer, but our clients also care about the more general
form of caching that I described, whatever name we use for it.
One of the points of this discussion is to determine whether clients should
be able to use etags returned by PUT for this other kind of caching.

> WebDAV clients only need to know that they *sent* the content
> associated with an etag in order to avoid overwriting someone else's
> edits.  That's optimistic locking.

Our WebDAV clients also care about performance, so they also care about
caching, not just about optimistic locking.

Cheers,
Geoff
--=_alternative 0065B985852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:32:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8lQ-0005MX-Md for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:32:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28434 for ; Wed, 21 Dec 2005 13:31:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8k4-0002VA-OU for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:31:12 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8k0-0002UU-Fo for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:31:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8jr-0001gm-CO for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:31:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIUok3015045; Wed, 21 Dec 2005 10:30:50 -0800 Date: Wed, 21 Dec 2005 10:30:50 -0800 Message-Id: <200512211830.jBLIUok3015045@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8jr-0001gm-CO 4bd4cb7f42b10b8e6817d3e3cd597dfd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 197] LOCK_ISSUES_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512211830.jBLIUok3015045@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11304 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:31:12 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=197 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:35:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8oe-00070l-Bt for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:35:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28633 for ; Wed, 21 Dec 2005 13:34:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8nO-00036y-Pu for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:34:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8nJ-00036H-VY for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:34:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep8nH-0001hp-44 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:34:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIYQi7015070; Wed, 21 Dec 2005 10:34:26 -0800 Date: Wed, 21 Dec 2005 10:34:26 -0800 Message-Id: <200512211834.jBLIYQi7015070@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep8nH-0001hp-44 be5cdfe6190a8b39643b7abf4fa80b33 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 196] LOCK_ISSUES_ERROR_CODES X-Archived-At: http://www.w3.org/mid/200512211834.jBLIYQi7015070@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11305 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:34:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=196 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:36:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8oz-0007Cw-60 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:36:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28660 for ; Wed, 21 Dec 2005 13:35:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8nd-00038U-3l for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:34:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8na-00037m-BP for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:34:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8nV-0003FB-Nt for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:34:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIYa6E015088; Wed, 21 Dec 2005 10:34:36 -0800 Date: Wed, 21 Dec 2005 10:34:36 -0800 Message-Id: <200512211834.jBLIYa6E015088@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8nV-0003FB-Nt a5f43384f8512e6a301291c85c6a0431 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 196] LOCK_ISSUES_ERROR_CODES X-Archived-At: http://www.w3.org/mid/200512211834.jBLIYa6E015088@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11306 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:34:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=196 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:36:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8p5-0007DQ-SU for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:36:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28668 for ; Wed, 21 Dec 2005 13:35:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8ns-0003VR-Vc for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:35:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8nq-0003Ut-Df for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:35:06 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8nm-0003K9-VL for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:35:05 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIYpRP015106; Wed, 21 Dec 2005 10:34:51 -0800 Date: Wed, 21 Dec 2005 10:34:51 -0800 Message-Id: <200512211834.jBLIYpRP015106@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8nm-0003K9-VL f8f61b8d133abd4296c70c2a359601b8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 196] LOCK_ISSUES_ERROR_CODES X-Archived-At: http://www.w3.org/mid/200512211834.jBLIYpRP015106@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11307 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:35:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=196 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:41:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8tf-0000Mc-7X for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:41:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29199 for ; Wed, 21 Dec 2005 13:40:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8sG-0004Kv-5Z for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:39:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8sD-0004KH-RF for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:39:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep8s9-0004w0-UM for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:39:37 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIdVgQ015148; Wed, 21 Dec 2005 10:39:31 -0800 Date: Wed, 21 Dec 2005 10:39:31 -0800 Message-Id: <200512211839.jBLIdVgQ015148@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep8s9-0004w0-UM e52fee462707407e3575147dd5873499 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 195] LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE X-Archived-At: http://www.w3.org/mid/200512211839.jBLIdVgQ015148@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11308 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:39:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=195 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:42:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8vL-0000aN-PW for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:42:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29363 for ; Wed, 21 Dec 2005 13:41:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8tq-0004qb-09 for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:41:18 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8tn-0004q2-Iy for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:41:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep8tH-0000rI-Oq for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:41:14 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIehpA015176; Wed, 21 Dec 2005 10:40:43 -0800 Date: Wed, 21 Dec 2005 10:40:43 -0800 Message-Id: <200512211840.jBLIehpA015176@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep8tH-0000rI-Oq 6f92e0c1774ef067c48569caca7f8c28 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 195] LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE X-Archived-At: http://www.w3.org/mid/200512211840.jBLIehpA015176@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11310 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:41:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=195 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |ejw@cs.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 10:40 ------- Jim to provide text on the rationale for why it is a bad idea for a lock to follow a resource on a MOVE. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 13:43:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8vz-0000et-8B for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:43:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29433 for ; Wed, 21 Dec 2005 13:42:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8ul-0004t3-Dv for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:42:15 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8ui-0004sT-92 for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:42:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep8tx-0001A7-FV for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:42:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLIfPje015196; Wed, 21 Dec 2005 10:41:25 -0800 Date: Wed, 21 Dec 2005 10:41:25 -0800 Message-Id: <200512211841.jBLIfPje015196@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep8tx-0001A7-FV c7e21af1ac62198aa660141471ed84b2 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 195] LOCK_ISSUES_WRITE_LOCKS_AND_COPYMOVE X-Archived-At: http://www.w3.org/mid/200512211841.jBLIfPje015196@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11311 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:42:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=195 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:05:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9H7-00018p-Gl for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:05:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01730 for ; Wed, 21 Dec 2005 14:04:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep8t9-0004m3-U5 for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 18:40:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep8sz-0004lK-Ul for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 18:40:28 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep8sw-0003rb-A1 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 18:40:25 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBLIeLvI026771 for ; Wed, 21 Dec 2005 13:40:21 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBLIeLgh119674 for ; Wed, 21 Dec 2005 13:40:21 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBLIeKRg020418 for ; Wed, 21 Dec 2005 13:40:21 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBLIeKm3020392 for ; Wed, 21 Dec 2005 13:40:20 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 21 Dec 2005 13:40:18 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 13:40:19, Serialize complete at 12/21/2005 13:40:20, Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/21/2005 13:40:20 Content-Type: multipart/alternative; boundary="=_alternative 00669DD0852570DE_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Ep8sw-0003rb-A1 a28927b65d855bcd2d3a3368ecc68bd4 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF6436E5D7.E0D6E897-ON852570DE.0065C696-852570DE.00669E88@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11309 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 18:40:35 +0000 This is a multipart message in MIME format. --=_alternative 00669DD0852570DE_= Content-Type: text/plain; charset="US-ASCII" I agree that there may be a big misimpression on the part of server authors (but probably we differ on who we think those server authors are :-). In particular, I don't think anyone is suggesting/expecting that we match up server munging semantics ... all that some of us are suggesting/expecting is that there be a well-defined way in which a server can let a client know that it has significantly modified the submitted text, preferably in a way that will automatically work for (at least some) existing clients. That is the reason for focusing on etags, since an existing client that does an If-Match or If-None-Match with the etag returned by PUT will work properly on server-munged content if we return an etag for the PUT content that is different from the etag for the subsequent GET content. Using the 205 return code is also desireable, although this would primarily be for the benefit of future clients, since I doubt many existing clients have special handling for when 205 is returned by PUT. Cheers, Geoff "Dan Brotsky" wrote on 12/21/2005 01:17:16 AM: > Ah, now I begin to understand what I believe is a big misimpression > on the part of the server authors. (Sadly, I see almost no client > authors in these discussions anymore, which has been a big part of > my problem with the WebDAV process forever and why I've been quiet > for so long now.) > > Folks, clients are perfectly well aware that servers munge data when > they store it. It's *way* outside the scope of WebDAV to try and > match up the server-munging semantics with clients that rely on > those semantics. If you are a client that's looking for a faithful > dumb store and you stumble across a CVS-backed webdav server that > does keyword expansion to your graphics files, you will figure this > out quickly and stop using that server. That doesn't mean it's not > a WebDAV-compliant server, just not one with the store semantics you > were expecting. > > Similarly, if you are a client expecting a CVS server and you use a > file-backed Apache server, it also won't meet your needs. But it's > still WebDAV-compliant. > > The point of this effort is to define a greatest common denominator > that can be divided evenly into the semantics of any server that's > called WebDAV compliant. But believe me, every client in the world > understands that there may be extra factors in that server's > semantics that are relatively prime with the client's intent! > > That's a good thing. > > dan > > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Geoffrey M Clemm > Sent: Tuesday, December 20, 2005 07:23 > To: webdav > Subject: RE: Summary of ETag related issues in RFC2518bis > > "Dan Brotsky" wrote on 12/20/2005 12:09:21 AM: > > > In no case does a client ever assume that "the text it sent with the PUT > > is what would be retrieved by the GET." > > I agree. > > > That's not what the etag is for. > > That is what is up for debate. If a server has modified the text in a > way that the user needs to see (i.e., the modified text needs to be > the basis for subsequent edits), then there needs to be an efficient way > for the client to find this out. > > One technique would be to define the etag returned by the PUT as > being the etag corresponding to PUT text. Then if a client wants to perform > further edits on that text, it should issue a GET with an If-None-Match > header containing that etag. If new text is returned, then it should > base its edits on that new text. If no new text is returned, it knows > it can continue editing the text that was submitted earlier with the PUT. > > > The etag is to reassure the client that the value on the server > > *has not changed since the PUT completed*. > > How is that sufficient? If the changes made by the server are > substantive (and should be the basis for subsequent edits), returning > the etag that corresponds to the text on the server will mislead the > client into thinking it can make changes to the text it sent up with > the PUT, when in fact it should download the server text with a GET first. > > Cheers, > Geoff > > --=_alternative 00669DD0852570DE_= Content-Type: text/html; charset="US-ASCII"
I agree that there may be a big misimpression on the part of server
authors (but probably we differ on who we think those server authors
are :-).

In particular, I don't think anyone is suggesting/expecting that
we match up server munging semantics ... all that some of us
are suggesting/expecting is that there be a well-defined way in
which a server can let a client know that it has significantly modified
the submitted text, preferably in a way that will automatically work
for (at least some) existing clients.  That is the reason for
focusing on etags, since an existing client that does an If-Match
or If-None-Match with the etag returned by PUT will work properly
on server-munged content if we return an etag for the PUT content
that is different from the etag for the subsequent GET content.

Using the 205 return code is also desireable, although this would
primarily be for the benefit of future clients, since I doubt many
existing clients have special handling for when 205 is returned by PUT.

Cheers,
Geoff




"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/21/2005 01:17:16 AM:

> Ah, now I begin to understand what I believe is a big misimpression
> on the part of the server authors.  (Sadly, I see almost no client
> authors in these discussions anymore, which has been a big part of
> my problem with the WebDAV process forever and why I've been quiet
> for so long now.)
>  
> Folks, clients are perfectly well aware that servers munge data when
> they store it.  It's *way* outside the scope of WebDAV to try and
> match up the server-munging semantics with clients that rely on
> those semantics.  If you are a client that's looking for a faithful
> dumb store and you stumble across a CVS-backed webdav server that
> does keyword expansion to your graphics files, you will figure this
> out quickly and stop using that server.  That doesn't mean it's not
> a WebDAV-compliant server, just not one with the store semantics you
> were expecting.
>  
> Similarly, if you are a client expecting a CVS server and you use a
> file-backed Apache server, it also won't meet your needs.  But it's
> still WebDAV-compliant.
>  
> The point of this effort is to define a greatest common denominator
> that can be divided evenly into the semantics of any server that's
> called WebDAV compliant.  But believe me, every client in the world
> understands that there may be extra factors in that server's
> semantics that are relatively prime with the client's intent!
>  
> That's a good thing.
>  
>     dan
>
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Geoffrey M Clemm
> Sent: Tuesday, December 20, 2005 07:23
> To: webdav
> Subject: RE: Summary of ETag related issues in RFC2518bis
>
> "Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/20/2005 12:09:21 AM:
>
> > In no case does a client ever assume that "the text it sent with the PUT
> > is what would be retrieved by the GET."
>
> I agree.
>
> > That's not what the etag is for.
>
> That is what is up for debate.  If a server has modified the text in a
> way that the user needs to see (i.e., the modified text needs to be
> the basis for subsequent edits), then there needs to be an efficient way
> for the client to find this out.
>
> One technique would be to define the etag returned by the PUT as
> being the etag corresponding to PUT text.  Then if a client wants to perform
> further edits on that text, it should issue a GET with an If-None-Match
> header containing that etag.  If new text is returned, then it should
> base its edits on that new text.  If no new text is returned, it knows
> it can continue editing the text that was submitted earlier with the PUT.
>
> > The etag is to reassure the client that the value on the server
> > *has not changed since the PUT completed*.
>
> How is that sufficient?  If the changes made by the server are
> substantive (and should be the basis for subsequent edits), returning
> the etag that corresponds to the text on the server will mislead the
> client into thinking it can make changes to the text it sent up with
> the PUT, when in fact it should download the server text with a GET first.
>
> Cheers,
> Geoff
>
>
--=_alternative 00669DD0852570DE_=-- From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:10:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9M2-0002gX-2o for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:10:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02915 for ; Wed, 21 Dec 2005 14:09:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9KZ-0003ts-5Q for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:08:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9KO-0003sa-FI for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:08:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep9KC-0005sQ-W8 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:08:43 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJ8U0Q015256; Wed, 21 Dec 2005 11:08:30 -0800 Date: Wed, 21 Dec 2005 11:08:30 -0800 Message-Id: <200512211908.jBLJ8U0Q015256@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep9KC-0005sQ-W8 0186134b86be7fad4dfe707b02abe82c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512211908.jBLJ8U0Q015256@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11312 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:08:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 11:08 ------- Following WG discussion on the ordering of authentication / authorization and If header checks (144), the If header approach has been recognized as the best approach. Agreement reached NOT to mention the 100-continue approach as this may cause significant client / server confusion. An additional approach related to spoofing the realm of an auth header has also been suggested but not tested for interoperability (and consulting the relevant specs didn't make things clear)... Lisa to draft text for review... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:17:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9SP-0004iQ-O2 for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:17:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04713 for ; Wed, 21 Dec 2005 14:15:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9Qp-0006Iy-GG for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:15:23 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9Ql-000670-Fz for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:15:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep9Pv-0005z8-Ia for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:15:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJEPfv015293; Wed, 21 Dec 2005 11:14:25 -0800 Date: Wed, 21 Dec 2005 11:14:25 -0800 Message-Id: <200512211914.jBLJEPfv015293@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep9Pv-0005z8-Ia 6a5c5c74577cfccfd479741fed268c7c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 194] LOCK_ISSUES_WRITE_LOCKS_AND_COLLECTIONS X-Archived-At: http://www.w3.org/mid/200512211914.jBLJEPfv015293@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11313 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:15:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=194 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 11:14 ------- Already resolved in section 7.7 of -09 draft. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:22:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9Y3-0006hY-Az for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:22:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06333 for ; Wed, 21 Dec 2005 14:21:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9Wd-0007iQ-AG for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:21:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9WZ-0007ge-Sr for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:21:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Ep9WV-0002YP-TU for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:21:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJLE00015324; Wed, 21 Dec 2005 11:21:14 -0800 Date: Wed, 21 Dec 2005 11:21:14 -0800 Message-Id: <200512211921.jBLJLE00015324@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Ep9WV-0002YP-TU 4eb508b2c48e059074480f59d3e62d17 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 193] LOCK_ISSUES_WRITE_LOCK X-Archived-At: http://www.w3.org/mid/200512211921.jBLJLE00015324@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11314 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:21:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=193 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-21 11:21 ------- Issue mostly resolved in -09 draft but for the following... A shared write lock allows additional shared write locks to be taken out on the resource. Hence, consensus is to replace: "A shared write lock prevents the same operations, however it also allows access by any principal that has a shared write lock on the same resource." with: "A shared write lock prevents the same operations (except additional requests for shared write locks), however it also allows access by any principal that has a shared write lock on the same resource." or something substantially similar... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:24:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9ZN-0007M5-Bf for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:24:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06943 for ; Wed, 21 Dec 2005 14:23:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9Xy-0007ts-Iy for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:22:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9Xt-0007sl-BY for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:22:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep9Xm-0002Sg-JM for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:22:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJLS1g015346; Wed, 21 Dec 2005 11:21:28 -0800 Date: Wed, 21 Dec 2005 11:21:28 -0800 Message-Id: <200512211921.jBLJLS1g015346@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep9Xm-0002Sg-JM 4ea3eb2195c4f148069e591402f7eb58 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 193] LOCK_ISSUES_WRITE_LOCK X-Archived-At: http://www.w3.org/mid/200512211921.jBLJLS1g015346@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11315 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:22:46 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=193 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:28:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9du-0005V8-Lw for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:28:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08188 for ; Wed, 21 Dec 2005 14:27:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9cR-0000LK-Mf for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:27:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9cP-0000Js-1Z for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:27:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Ep9cH-00049q-52 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:27:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJQP7F015367; Wed, 21 Dec 2005 11:26:25 -0800 Date: Wed, 21 Dec 2005 11:26:25 -0800 Message-Id: <200512211926.jBLJQP7F015367@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Ep9cH-00049q-52 4e777395e22dd1de7eaa385038306216 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 193] LOCK_ISSUES_WRITE_LOCK X-Archived-At: http://www.w3.org/mid/200512211926.jBLJQP7F015367@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11316 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:27:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=193 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:46:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep9uj-0004N4-CR for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:46:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10294 for ; Wed, 21 Dec 2005 14:45:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ep9t8-00043g-0B for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:44:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ep9sx-00041m-OT for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:44:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ep9sf-0002lq-54 for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:44:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJi4fw015404; Wed, 21 Dec 2005 11:44:04 -0800 Date: Wed, 21 Dec 2005 11:44:04 -0800 Message-Id: <200512211944.jBLJi4fw015404@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ep9sf-0002lq-54 1bc96953267f56cf1e1e8f645a59e878 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512211944.jBLJi4fw015404@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11317 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:44:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 ------- Additional Comments From lisa@osafoundation.org 2005-12-21 11:44 ------- The next version of the spec will have proposed text which I'm sure we'll have to review. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 21 14:54:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpA38-0000NA-OF for webdav-archive@megatron.ietf.org; Wed, 21 Dec 2005 14:54:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12762 for ; Wed, 21 Dec 2005 14:53:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpA1f-0007Ic-8J for w3c-dist-auth-dist@listhub.w3.org; Wed, 21 Dec 2005 19:53:27 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpA1a-0007Hz-2e for w3c-dist-auth@listhub.w3.org; Wed, 21 Dec 2005 19:53:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EpA1W-00073l-II for w3c-dist-auth@w3.org; Wed, 21 Dec 2005 19:53:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBLJrIti015462; Wed, 21 Dec 2005 11:53:18 -0800 Date: Wed, 21 Dec 2005 11:53:18 -0800 Message-Id: <200512211953.jBLJrIti015462@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpA1W-00073l-II 8564ebe4d6a9e55dc44377c7aabea7b7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512211953.jBLJrIti015462@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11318 X-Loop: w3c-dist-auth@w3.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, 21 Dec 2005 19:53:27 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-21 11:53 ------- I've made changes to this text, the most important one being to require that servers MUST support either the old model or the new one, but SHOULD support the new one -- this is much better than saying that servers MAY support the old model but SHOULD support the new model. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 22 00:58:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpJSl-0005ka-3b for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 00:58:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01735 for ; Thu, 22 Dec 2005 00:56:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpJR7-0008CJ-CO for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 05:56:21 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpJQv-0008Bi-9O for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 05:56:09 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by aji.w3.org with esmtp (Exim 4.50) id 1EpJQM-0000QL-RN for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 05:56:07 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Dec 2005 21:55:30 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBM5tSpf017663 for ; Wed, 21 Dec 2005 21:55:29 -0800 (PST) Received: from 10.21.112.111 ([10.21.112.111]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Dec 2005 05:55:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 21 Dec 2005 21:55:38 -0800 From: Cullen Jennings To: WebDav Message-ID: Thread-Topic: Schedule for finishing Thread-Index: AcYGvFU4k79UmHKvEdqVpgARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (aji.w3.org: domain of fluffy@cisco.com designates 171.68.10.86 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1EpJQM-0000QL-RN 2c7af9317f93e68190bbfa132264f534 X-Original-To: w3c-dist-auth@w3.org Subject: Schedule for finishing X-Archived-At: http://www.w3.org/mid/BFCF7FDA.6680E%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11319 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 05:56:21 +0000 Content-Transfer-Encoding: 7bit I have had conversations with many of the key contributors, document editors, and our AD about completing the work so I thought this would be a good time to provide a bit of update on schedule for this WG. We have been making fairly good progress on 2518bis but still have a ways to go. We have been coming to resolution on about 25 bugs a week and have less than 50 to go. We have some hard issues in that 50. By Jan 15, I would like to see us down to 15 bugs where we don't know how we want to resolve them. By the end of January, I would like to have a draft ready for WGLC. I believe this is possible if we keep working very hard on the draft and work hard to find reasonable solutions to the hard problems without getting entrenched in what a single person feels is the best solution or things that are effectively editorial issues. Once we get 2518bis well into WGLC, I will try and ramp up work to finalize BIND. Given our rate of progress, and the assumption that people are willing to work really hard to have 2518bis in WGLC by the end of January, Ted and I are both comfortable keeping the WG open. I would like to sincerely thank the Elias, Jim, Julian, Lisa, and the rest of folks that are helping for the huge amount of time they are putting in to this. I am not aware of any other draft in the IETF that is getting as many person hours per week as 2518bis. I would also strongly encourage, implore, and basically beg for people who have not been deeply involved to set aside some time and read this document when it does reach WGLC. We need your insight to make sure that this specification is usable for a large community of developers. Thanks, Cullen (with my WG Chair hat on) From w3c-dist-auth-request@frink.w3.org Thu Dec 22 01:35:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpK3G-0002jR-Oq for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 01:35:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04224 for ; Thu, 22 Dec 2005 01:34:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpK0j-0006nd-GU for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 06:33:09 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpK0T-0006l6-T6 for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 06:32:54 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1EpK00-0006jW-IZ for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 06:32:52 +0000 Received: (qmail invoked by alias); 22 Dec 2005 06:32:19 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp033) with SMTP; 22 Dec 2005 07:32:19 +0100 X-Authenticated: #1915285 Message-ID: <43AA4816.5090703@gmx.de> Date: Thu, 22 Dec 2005 07:30:46 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dan Brotsky CC: Jim Whitehead , =?ISO-8859-1?Q?Wilfredo_S=E1nchez?= =?ISO-8859-1?Q?_Vega?= , WebDav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpK00-0006jW-IZ 13bcfad6a1e34efa32ba0434d32ece39 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43AA4816.5090703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11320 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 06:33:09 +0000 Content-Transfer-Encoding: 7bit Dan Brotsky wrote: >> Well. If the client has the lock, why would it need the ETag >> in the first place? > > Because servers can still write files when they are locked, and because losing a lock doesn't mean that you don't have up-to-date content. 1) If a server changes the contents of the file, and the client updates it again, without resyncing, why would that be a problem? I would assume that after applying the server-rewrite functionality (keyword expansion, virus checking, script stripping, property inclusion into the resource....), the result will be the same in both cases. 2) I still think that losing a lock is an edge case that we don't need to optimize for. > One of the primary uses, if not *the primary use*, of etags in a collaborative authoring environment is so clients can know whether or not they have current content. When a client authors a file and places it on the server, it doesn't want to have to fetch the file again unless necessary, and it doesn't want to have to do more roundtrips before continuing with work on that and other files. Yes. > Let me ask the converse question: If the server has the file, why can't it send the etag? That's all the spec is saying it should do. 1) RFC2518 isn't saying it 2) RFC2616 doesn't say what that means (or if it does it's doing that in such a vague way that reasonable people disagreed about what it means) 3) The most widely deployed servers do not return an ETag (IIS 5.1, does anybody know about IIS 6), or return a weak ETag first So this would be a normative change introducing a less-than-well-defined requirement, which doesn't even reflect what most servers do today. So my proposal is to resolve 2) first, and then discuss an extension of RFC2518 that relies on it (conceivably containing other stuff like the requirement to store arbitrary dead properties and such). I really don't see how we can get this done in the time that has been allocated to us. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 22 01:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpK3d-0002uK-Jw for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 01:36:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04234 for ; Thu, 22 Dec 2005 01:35:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpK1g-0006qt-UF for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 06:34:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EpK1b-0006pu-DO for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 06:34:03 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EpK1Y-0002WG-Ak for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 06:34:02 +0000 Received: (qmail invoked by alias); 22 Dec 2005 06:33:50 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp010) with SMTP; 22 Dec 2005 07:33:50 +0100 X-Authenticated: #1915285 Message-ID: <43AA4876.7060306@gmx.de> Date: Thu, 22 Dec 2005 07:32:22 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Geoffrey M Clemm CC: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EpK1Y-0002WG-Ak dfa9401fb9db6bac01f7f3221965dca2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43AA4876.7060306@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11321 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 06:34:08 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Julian wrote on 12/21/2005 09:54:11 AM: > > > > Dan Brotsky wrote: > > > As to your last question: Yes it's OK and no the server needs to break > > > the lock if it does this (because it's indistinguishable from another > > > client's edit). Not all clients will work efficiently against servers > > > that unexpectedly munge data after PUTs are complete but that's life. > > > > For the record: I think that linking the ETag behavior for PUT to the > > fact whether the resource was locked or not would be a really bad idea. > > Julian: I agree with you, but did you think Dan was suggesting otherwise, > or were you just agreeing with Dan's statement (or at least, with the > "yes, it's OK" part)? I am assuming that you were not disagreeing > with Dan, since I don't believe he suggests anything that would make ETag > behavior depend on whether the resource was locked or not. I agree that servers can rewrite the content upon PUT, even if the resource is locked. I do not agree that they need to break the lock to do that. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 22 03:21:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpLh3-0001jG-Td for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 03:21:00 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12399 for ; Thu, 22 Dec 2005 03:19:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpLfK-0002RL-G2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 08:19:10 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpLf6-0002OO-MK for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 08:18:56 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by aji.w3.org with esmtp (Exim 4.50) id 1EpLeQ-0008Ut-1w for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 08:18:55 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBM8I7Ck012662; Thu, 22 Dec 2005 09:18:07 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id jBM8I6i3012647; Thu, 22 Dec 2005 09:18:06 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.11/8.12.5) id jBM8I33J012083; Thu, 22 Dec 2005 09:18:03 +0100 (MET) Date: Thu, 22 Dec 2005 09:18:03 +0100 (MET) From: Yves Lafon X-X-Sender: ylafon@tarantula.inria.fr To: Julian Reschke cc: Geoffrey M Clemm , webdav In-Reply-To: <43AA4876.7060306@gmx.de> Message-ID: References: <43AA4876.7060306@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Thu, 22 Dec 2005 09:18:06 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (aji.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpLeQ-0008Ut-1w 6f1d556e43b1d3a032c65b911b139830 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.64.0512220917130.12058@gnenaghyn.vaevn.se Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11322 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 08:19:10 +0000 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 22 Dec 2005, Julian Reschke wrote: >> Julian: I agree with you, but did you think Dan was suggesting otherwise= , >> or were you just agreeing with Dan's statement (or at least, with the >> "yes, it's OK" part)? I am assuming that you were not disagreeing >> with Dan, since I don't believe he suggests anything that would make ETa= g >> behavior depend on whether the resource was locked or not. > > I agree that servers can rewrite the content upon PUT, even if the resour= ce=20 > is locked. I do not agree that they need to break the lock to do that. Agreed, lock is there to ensure other clients won't edit the resource. The= =20 server can do what it wants. --=20 Yves Lafon - W3C "Baroula que barouleras, au ti=E9u toujou t'entourneras." From w3c-dist-auth-request@frink.w3.org Thu Dec 22 03:22:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpLiX-0002EN-VN for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 03:22:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12439 for ; Thu, 22 Dec 2005 03:21:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpLhX-00032x-0N for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 08:21:27 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpLhS-000324-Nb for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 08:21:23 +0000 Received: from exprod6og5.obsmtp.com ([64.18.1.125]) by aji.w3.org with smtp (Exim 4.50) id 1EpLhN-0001UQ-Oe for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 08:21:21 +0000 Received: from source ([192.150.20.142]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 22 Dec 2005 00:21:07 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBM8L3FX020708; Thu, 22 Dec 2005 00:21:03 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBM8L0rs010796; Thu, 22 Dec 2005 00:21:05 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 00:22:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C606D0.D3762BAF" Date: Thu, 22 Dec 2005 00:20:58 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYGXRKda4tT7//pRICoV7Rc0Hy7HgAcx7KQ From: "Dan Brotsky" To: "Geoffrey M Clemm" , " webdav" X-OriginalArrivalTime: 22 Dec 2005 08:22:21.0133 (UTC) FILETIME=[D44BA7D0:01C606D0] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpLhN-0001UQ-Oe 5bd0a32ca5534eaea71eeac8eac4798d X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B94FA@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11323 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 08:21:27 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C606D0.D3762BAF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Geoff, Lisa, =20 Thanks for the clarification. =20 I think cacheing clients such as yours really care whether the server munges the received content or not. My perspective is that you need to actually do a get, then, after your put. I don't think you should rely on the received etag; you will need the MD5 to avoid the get. =20 dan ________________________________ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Wednesday, December 21, 2005 10:31 To: webdav Subject: RE: Summary of ETag related issues in RFC2518bis =09 =09 "Dan Brotsky" wrote on 12/21/2005 01:22:17 AM: =09 >> I think a WebDAV client cares about both optimistic locking=20 >> and caching. =20 > =20 > I strongly disagree.=20 =09 Like Lisa, our client writers care about both optimistic locking and caching. And I don't think we are the only ones that feel that way.=20 =09 >> Also note that they are rather intimately linked, since=20 >> optimistic locking is based on knowing that the client's edits are=20 >> based on the=20 >> text that is currently on the server, while caching is based on knowing=20 >> that what the client currently has is based on the text that is currently on=20 >> the server. =20 =20 > No. Optimistic locking is based on knowing that the client's edits=20 > are being applied to the content the client last sent to the server, > and are not overwriting other client's edits. Caching is based on=20 > knowing that the content you *last received* is the same as what you > *would receive* on your next get.=20 =09 Our client writers care about all three, i.e. optimistic locking (whose=20 definition we appear to agree on), GET caching (i.e., what you define as=20 caching), and re-use of the content submitted for a PUT (included in my=20 more general definition of caching).=20 =09 > HTTP clients, whether webdav or not, know they must have *received*=20 > the content associated with an etag in order to avoid fetching it=20 > again. That's caching.=20 =09 I am happy to use "caching" to only mean "GET caching"=20 if that's what you prefer, but our clients also care about the more general=20 form of caching that I described, whatever name we use for it.=20 One of the points of this discussion is to determine whether clients should=20 be able to use etags returned by PUT for this other kind of caching.=20 =09 > WebDAV clients only need to know that they *sent* the content=20 > associated with an etag in order to avoid overwriting someone else's > edits. That's optimistic locking.=20 =09 Our WebDAV clients also care about performance, so they also care about=20 caching, not just about optimistic locking.=20 =09 Cheers,=20 Geoff=20 =09 ------_=_NextPart_001_01C606D0.D3762BAF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Geoff, Lisa,
 
Thanks for the = clarification.
 
I think cacheing clients such as yours = really care=20 whether the server munges the received content or not.  My = perspective is=20 that you need to actually do a get, then, after your put.  I don't = think=20 you should rely on the received etag;  you will need the MD5 to = avoid the=20 get.
 
    dan

From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M=20 Clemm
Sent: Wednesday, December 21, 2005 10:31
To: = webdav
Subject: RE: Summary of ETag related issues in=20 RFC2518bis


"Dan Brotsky" = <dbrotsky@adobe.com> wrote=20 on 12/21/2005 01:22:17 AM:

>> I think a WebDAV client = cares about=20 both optimistic locking
>> and caching.   =
>  
> I = strongly=20 disagree.

Like Lisa, our client = writers=20 care about both optimistic locking
and=20 caching.  And I don't think we are the only ones that feel that=20 way.

>>  Also note = that they=20 are rather intimately linked, since
>> optimistic locking is = based=20 on knowing that the client's edits are
>> based on the =
>>=20 text that is currently on the server, while caching is based on = knowing=20
>> that what the client currently has is based on the text = that is=20 currently on
>> the server.  
 
> No. =  Optimistic=20 locking is based on knowing that the client's edits
> are being = applied=20 to the content the client last sent to the server,
> and are not = overwriting other client's edits.  Caching is based on
> = knowing=20 that the content you *last received* is the same as what you
> = *would=20 receive* on your next get.

Our = client=20 writers care about all three, i.e. optimistic locking = (whose=20
definition we appear to agree on), GET caching = (i.e.,=20 what you define as
caching), and = re-use of=20 the content submitted for a PUT (included in my
more general definition of caching). =

> HTTP clients, whether webdav or not, know they must = have=20 *received*
> the content associated with an etag in order to = avoid=20 fetching it
> again.  That's caching. =

I am happy to use "caching" to only mean "GET = caching"=20
if that's what you prefer, but our clients also = care=20 about the more general
form of = caching that I=20 described, whatever name we use for it.
One=20 of the points of this discussion is to determine whether clients=20 should
be able to use etags = returned by PUT=20 for this other kind of caching.

>=20 WebDAV clients only need to know that they *sent* the content
> = associated with an etag in order to avoid overwriting someone = else's
>=20 edits.  That's optimistic locking.

Our WebDAV clients also care about performance, so they = also care=20 about
caching, not just about = optimistic=20 locking.

Cheers, =
Geoff
------_=_NextPart_001_01C606D0.D3762BAF-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 08:26:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpQSN-0008FU-0t for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 08:26:07 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10716 for ; Thu, 22 Dec 2005 08:25:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpQQc-0007DY-L7 for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 13:24:18 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpQQO-0007C9-CY for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 13:24:04 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1EpQQI-0006KY-9A for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 13:24:02 +0000 Received: (qmail invoked by alias); 22 Dec 2005 13:23:53 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp039) with SMTP; 22 Dec 2005 14:23:53 +0100 X-Authenticated: #1915285 Message-ID: <43AAA87C.5040101@gmx.de> Date: Thu, 22 Dec 2005 14:22:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: WebDav WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpQQI-0006KY-9A 44dae5383174a2e70f04c9471c4d1c4c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Bindings and permissions X-Archived-At: http://www.w3.org/mid/43AAA87C.5040101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11324 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 13:24:18 +0000 Content-Transfer-Encoding: 7bit > I was thinking about the bindings and permissions stuff today. I've > discussed it before but this may be a new take on the subject. Recall > we don't really know what the behavior is with dynamically inherited > ACLs (when a parent's ACLs automatically apply to its child resources) > when some of those children are bindings to resources that also have > bindings. Some of the possible solutions to this: We don't know that because that's beyond the scope of RFC3744. As far as I can tell, the only inheritance mentioned over there is when ACEs or ACLs are explicitly inherited from another resource, identified by URL. *That* model is compatible with multiple bindings, because the inheritance chain still is well-defined. > ... > It seems to me clients have no way of knowing which solution the server > has chosen and behavior can be quite unpredictable. Is there some way > to advertise the server's model? Are some of these choices forbidden? > Of those that aren't forbidden, is one of them recommended? > > It would be extremely surprising if the 'bind' privilege grants > somebody the ability to make a new mapping of a resource into a new > directory, AND that a consequence of that 'bind' operation is to change > the permissions on the underlying resource -- without requiring > 'writeacl' privilege. Since that's a possible security hole, what > should that be -- a MUST NOT? A security consideration? > ... I'm really not sure what you're asking for. This seems to be about a server implementing an ACL model that's not compatible with RFC3744. In which case neither RFC3744 nor BIND can hep you predicting the server's behavior. I guess I'm missing something; but I dunno what. Please explain. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 22 08:55:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpQv0-0003QZ-BP for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 08:55:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14106 for ; Thu, 22 Dec 2005 08:54:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpQtt-0006Ig-FU for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 13:54:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EpQtg-0006Fw-Fg for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 13:54:20 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.50) id 1EpQtX-0004Be-AH for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 13:54:20 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBMDs8Fg019322 for ; Thu, 22 Dec 2005 08:54:08 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBMDs8mH120118 for ; Thu, 22 Dec 2005 08:54:08 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBMDs8jG003603 for ; Thu, 22 Dec 2005 08:54:08 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBMDs8QI003518 for ; Thu, 22 Dec 2005 08:54:08 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 22 Dec 2005 08:54:01 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/22/2005 08:54:07, Serialize complete at 12/22/2005 08:54:07 Content-Type: multipart/alternative; boundary="=_alternative 004C6832852570DF_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EpQtX-0004Be-AH cdd507ca752e79ca62a97c87ea46bcc7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF8098E6A0.1D626CC4-ON852570DF.004B721B-852570DF.004C68A8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11325 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 13:54:33 +0000 This is a multipart message in MIME format. --=_alternative 004C6832852570DF_= Content-Type: text/plain; charset="US-ASCII" I believe that you are basing your conclusion on the assumption that the authoring client can ignore the rewriting that is being done by the server. In that case, I (and I'm reasonably sure, Dan) would agree that there is no need for the server to cancel the LOCK. But the case being discussed here is where the server has rewritten the text and wants the client to base future edits on the rewritten text. You may say "my server would never do that" or even "I would never use a server that did that" (in which case you might not want to spend any more time on this thread :-), but in case the server did do that (and I have scenarios in which I can imagine a server wanting to do that), I believe that automatically breaking the lock is a good way of getting this point across to existing clients (who don't know about the 205 convention). Cheers, Geoff Yves wrote on 12/22/2005 03:18:03 AM: > On Thu, 22 Dec 2005, Julian Reschke wrote: > > >> Julian: I agree with you, but did you think Dan was suggesting otherwise, > >> or were you just agreeing with Dan's statement (or at least, with the > >> "yes, it's OK" part)? I am assuming that you were not disagreeing > >> with Dan, since I don't believe he suggests anything that would make ETag > >> behavior depend on whether the resource was locked or not. > > > > I agree that servers can rewrite the content upon PUT, even if theresource > > is locked. I do not agree that they need to break the lock to do that. > > Agreed, lock is there to ensure other clients won't edit the resource. The > server can do what it wants. --=_alternative 004C6832852570DF_= Content-Type: text/html; charset="US-ASCII"
I believe that you are basing your conclusion on the assumption
that the authoring client can ignore the rewriting that is being
done by the server.  In that case, I (and I'm reasonably sure, Dan)
would agree that there is no need for the server to cancel the LOCK.

But the case being discussed here is where the server has
rewritten the text and wants the client to base future edits on the  
rewritten text.  You may say "my server would never do that" or even
"I would never use a server that did that" (in which case you might
not want to spend any more time on this thread :-), but in case
the server did do that (and I have scenarios in which I can imagine
a server wanting to do that), I believe that automatically breaking
the lock is a good way of getting this point across to existing clients
(who don't know about the 205 convention).

Cheers,
Geoff

Yves wrote on 12/22/2005 03:18:03 AM:
> On Thu, 22 Dec 2005, Julian Reschke wrote:
>
> >> Julian: I agree with you, but did you think Dan was suggesting otherwise,
> >> or were you just agreeing with Dan's statement (or at least, with the
> >> "yes, it's OK" part)?   I am assuming that you were not disagreeing
> >> with Dan, since I don't believe he suggests anything that would make ETag
> >> behavior depend on whether the resource was locked or not.
> >
> > I agree that servers can rewrite the content upon PUT, even if theresource
> > is locked. I do not agree that they need to break the lock to do that.
>
> Agreed, lock is there to ensure other clients won't edit the resource. The
> server can do what it wants.
 --=_alternative 004C6832852570DF_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 09:02:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpR1E-0006K5-OC for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 09:02:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15004 for ; Thu, 22 Dec 2005 09:01:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpR08-0000fi-Tr for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 14:01:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EpR03-0000eb-JM for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 14:00:55 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by maggie.w3.org with esmtp (Exim 4.50) id 1EpQzz-0006JV-Bh for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 14:00:54 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBME0UNs007258 for ; Thu, 22 Dec 2005 09:00:30 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBME0Ujk055524 for ; Thu, 22 Dec 2005 09:00:30 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBME0UAT019568 for ; Thu, 22 Dec 2005 09:00:30 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBME0URJ019549 for ; Thu, 22 Dec 2005 09:00:30 -0500 In-Reply-To: <43AA4816.5090703@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 22 Dec 2005 09:00:24 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/22/2005 09:00:30, Serialize complete at 12/22/2005 09:00:30 Content-Type: multipart/alternative; boundary="=_alternative 004CFD96852570DF_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1EpQzz-0006JV-Bh 0d2ea1bdcc7561f7a2c8426b256f29a7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/OF50C153AA.FFFB6585-ON852570DF.004C9C52-852570DF.004CFE3F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11326 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 14:01:00 +0000 This is a multipart message in MIME format. --=_alternative 004CFD96852570DF_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian that this is not something we should try to resolve in 2518bis, and given the need to focus this group on 2518bis, I will restrain myself from using up any additional working group bandwidth on this (from my perspective, interesting) topic until 2518bis (and BIND) is finalized. Cheers, Geoff Julian wrote on 12/22/2005 01:30:46 AM: > > Let me ask the converse question: If the server has the file, why > > can't it send the etag? That's all the spec is saying it should do. > > 1) RFC2518 isn't saying it > 2) RFC2616 doesn't say what that means (or if it does it's doing that in > such a vague way that reasonable people disagreed about what it means) > 3) The most widely deployed servers do not return an ETag (IIS 5.1, does > anybody know about IIS 6), or return a weak ETag first > > So this would be a normative change introducing a less-than-well-defined > requirement, which doesn't even reflect what most servers do today. > > So my proposal is to resolve 2) first, and then discuss an extension of > RFC2518 that relies on it (conceivably containing other stuff like the > requirement to store arbitrary dead properties and such). I really don't > see how we can get this done in the time that has been allocated to us. --=_alternative 004CFD96852570DF_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian that this is not something we should try to resolve
in 2518bis, and given the need to focus this group on 2518bis,
I will restrain myself from using up any additional working group bandwidth
on this (from my perspective, interesting) topic until 2518bis (and BIND)
is finalized.

Cheers,
Geoff


Julian wrote on 12/22/2005 01:30:46 AM:
> > Let me ask the  converse question: If the server has the file, why
> > can't it send the etag?  That's all the spec is saying it should do.
>
> 1) RFC2518 isn't saying it
> 2) RFC2616 doesn't say what that means (or if it does it's doing that in
> such a vague way that reasonable people disagreed about what it means)
> 3) The most widely deployed servers do not return an ETag (IIS 5.1, does
> anybody know about IIS 6), or return a weak ETag first
>
> So this would be a normative change introducing a less-than-well-defined
> requirement, which doesn't even reflect what most servers do today.
>
> So my proposal is to resolve 2) first, and then discuss an extension of
> RFC2518 that relies on it (conceivably containing other stuff like the
> requirement to store arbitrary dead properties and such). I really don't
> see how we can get this done in the time that has been allocated to us.
 --=_alternative 004CFD96852570DF_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 09:04:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpR3S-0006yv-QM for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 09:04:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15215 for ; Thu, 22 Dec 2005 09:03:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpR2W-0000ti-Lu for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 14:03:28 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpR2R-0000t5-Aa for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 14:03:23 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EpR2N-00072K-B0 for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 14:03:22 +0000 Received: (qmail invoked by alias); 22 Dec 2005 14:03:15 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp039) with SMTP; 22 Dec 2005 15:03:15 +0100 X-Authenticated: #1915285 Message-ID: <43AAB1B1.3000000@gmx.de> Date: Thu, 22 Dec 2005 15:01:21 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Geoffrey M Clemm CC: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpR2N-00072K-B0 552eac6921fadff107221f8bc1075fb6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/43AAB1B1.3000000@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11327 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 14:03:28 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I believe that you are basing your conclusion on the assumption > that the authoring client can ignore the rewriting that is being > done by the server. In that case, I (and I'm reasonably sure, Dan) > would agree that there is no need for the server to cancel the LOCK. > > But the case being discussed here is where the server has > rewritten the text and wants the client to base future edits on the > rewritten text. You may say "my server would never do that" or even > "I would never use a server that did that" (in which case you might > not want to spend any more time on this thread :-), but in case > the server did do that (and I have scenarios in which I can imagine > a server wanting to do that), I believe that automatically breaking > the lock is a good way of getting this point across to existing clients > (who don't know about the 205 convention). > > Cheers, > Geoff Geoff, could you post an example scenario? I really have a hard time understanding why it would make a difference in practice... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 22 10:55:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpSn1-0000Sf-J9 for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:55:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28133 for ; Thu, 22 Dec 2005 10:54:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpSlC-000109-NM for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 15:53:42 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpSkz-0000y4-Lg for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 15:53:30 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1EpSkn-0006ko-88 for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 15:53:28 +0000 Received: (qmail invoked by alias); 22 Dec 2005 15:53:10 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp025) with SMTP; 22 Dec 2005 16:53:10 +0100 X-Authenticated: #1915285 Message-ID: <43AACB73.9000408@gmx.de> Date: Thu, 22 Dec 2005 16:51:15 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) 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 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpSkn-0006ko-88 0dfd335fd6b11880e691034ae5a7d7a5 X-Original-To: w3c-dist-auth@w3.org Subject: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/43AACB73.9000408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11328 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 15:53:42 +0000 Content-Transfer-Encoding: 7bit Hi, I'd like to understand where we stand regarding property value round tripping. Proposed text was posted in BugZilla (see ), and as far as I can tell, two questions were left and sent to the mailing list for discussion? 1) We're trying to encourage servers to preserve namespace prefixes, thus making it a SHOULD level requirement. 2) Is there any interest in comments being preserved? Re 1): there was little feedback on that, expcet for Wilfredo who's concerned that people may be reyling on XML serializers that throw out that information. Do people think that therefore SHOULD is too strong, or would we just have to live that some servers wouldn't be able to do it (it's not a MUST, after all). Re 2): I don't think we got any feedback on this. As XML parsers are not required to pass on information from comments, I'm inclined to say: not a SHOULD (thus leave it in the bag of optional things servers can always do). So please try to give feedback on these two questions, and on the suggested text in BugZilla. Hopefully then it can make it into the next draft. Best regards, Julian -- cut -- 4.4 Property Values The value of a property is always a (well-formed) XML fragment. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml: lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined), not multiple values in different languages or a single value in multiple languages. A property is always presented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: The value of the property appears inside the property name element. It may be any kind of well-formed XML content, including both text- only and mixed content. In the latter case, servers MUST preserve certain aspects of the content. Using the terminology from [REC-XML- INFOSET], the following rules apply: For the property name Element Information Item itself: [namespace name], [local name], [attributes] named "xml:lang" or any such attribute in scope, [children] of type element or character. On all Element Information Items that are descendants of the property name element: [namespace name], [local name], [attributes] and [children] of type element or character. On Attribute Information Items: [namespace name], [local name] and [normalized value]. On Character Information Items:: [character code]. Future revisions of this specification may also require to preserve namespace prefixes for child elements of the property elements, thus servers SHOULD preserve the [prefix] as well. [[preserve.more.xml: Feedback if we should ask implementors to preserve more in the future is appreciated (such as comments).]] XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. Also note that whitespace inside values is always significant, and that servers MUST NOT support overriding this using the xml:space attribute. 4.4.1 Example - Property with Mixed Content Consider a dead property 'author' created by the client as follows: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of ]]>. When retrieving the property, a server may return: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of <RFC2518>. Note: o The [prefix] for the property name itself was not preserved, being non-significant, o attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved, o the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope), o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and o the comment item was stripped (as would have been a processing instruction item). Implementation note: There are cases such as editing scenarios where clients may require that XML content is preserved character-by-character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing. From w3c-dist-auth-request@frink.w3.org Thu Dec 22 11:26:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpTH7-000460-Tt for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 11:26:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01804 for ; Thu, 22 Dec 2005 11:25:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpTFu-0000Sd-OA for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 16:25:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EpTFg-0000Qu-Ux for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 16:25:13 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by maggie.w3.org with esmtp (Exim 4.50) id 1EpTFa-0006NV-Cb for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 16:25:12 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBMGOdpl030450 for ; Thu, 22 Dec 2005 11:24:39 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBMGOdjk113638 for ; Thu, 22 Dec 2005 11:24:39 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBMGOdCS027220 for ; Thu, 22 Dec 2005 11:24:39 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBMGOYCJ026739 for ; Thu, 22 Dec 2005 11:24:34 -0500 In-Reply-To: <43AACB73.9000408@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 22 Dec 2005 11:24:28 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/22/2005 11:24:34, Serialize complete at 12/22/2005 11:24:34 Content-Type: multipart/alternative; boundary="=_alternative 005A2E99852570DF_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EpTFa-0006NV-Cb ff002f40c97328b94550e1de0beb4f22 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/OF10E2AB1F.244827B5-ON852570DF.0057F900-852570DF.005A2ED0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11329 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 16:25:26 +0000 This is a multipart message in MIME format. --=_alternative 005A2E99852570DF_= Content-Type: text/plain; charset="US-ASCII" (1) I support adding an explicit recommendation that servers preserve namespace prefixes in property values. I'm neutral on whether we use the term "SHOULD" in that recommendation. (2) I do not support adding a recommendation that comments be preserved, since I have seen no use cases proposed that require this. Cheers, Geoff Julian wrote on 12/22/2005 10:51:15 AM: > > Hi, > > I'd like to understand where we stand regarding property value round > tripping. Proposed text was posted in BugZilla (see > ), and as far > as I can tell, two questions were left and sent to the mailing list for > discussion? > > 1) We're trying to encourage servers to preserve namespace prefixes, > thus making it a SHOULD level requirement. > > 2) Is there any interest in comments being preserved? > > Re 1): there was little feedback on that, expcet for Wilfredo who's > concerned that people may be reyling on XML serializers that throw out > that information. Do people think that therefore SHOULD is too strong, > or would we just have to live that some servers wouldn't be able to do > it (it's not a MUST, after all). > > Re 2): I don't think we got any feedback on this. As XML parsers are not > required to pass on information from comments, I'm inclined to say: not > a SHOULD (thus leave it in the bag of optional things servers can always > do). > > So please try to give feedback on these two questions, and on the > suggested text in BugZilla. Hopefully then it can make it into the next > draft. > > Best regards, > > Julian > > -- cut -- > > 4.4 Property Values > > The value of a property is always a (well-formed) XML fragment. > > XML has been chosen because it is a flexible, self-describing, > structured data format that supports rich schema definitions, and > because of its support for multiple character sets. XML's self- > describing nature allows any property's value to be extended by > adding new elements. Older clients will not break when they > encounter extensions because they will still have the data specified > in the original schema and MUST ignore elements they do not > understand. > > XML's support for multiple character sets allows any human-readable > property to be encoded and read in a character set familiar to the > user. XML's support for multiple human languages, using the "xml: > lang" attribute, handles cases where the same character set is > employed by multiple human languages. Note that xml:lang scope is > recursive, so a xml:lang attribute on any element containing a > property name element applies to the property value unless it has > been overridden by a more locally scoped attribute. Note that a > property only has one value, in one language (or language MAY be left > undefined), not multiple values in different languages or a single > value in multiple languages. > > A property is always presented with an XML element consisting of the > property name, called the "property name element". > > The simplest example is an empty property, which is different from a > property that does not exist: > > > > The value of the property appears inside the property name element. > It may be any kind of well-formed XML content, including both text- > only and mixed content. In the latter case, servers MUST preserve > certain aspects of the content. Using the terminology from [REC-XML- > INFOSET], the following rules apply: > > For the property name Element Information Item itself: > > [namespace name], > > [local name], > > [attributes] named "xml:lang" or any such attribute in scope, > > [children] of type element or character. > > On all Element Information Items that are descendants of the property > name element: > > [namespace name], > > [local name], > > [attributes] and > > [children] of type element or character. > > On Attribute Information Items: > > [namespace name], > > [local name] and > > [normalized value]. > > On Character Information Items:: > > [character code]. > > Future revisions of this specification may also require to preserve > namespace prefixes for child elements of the property elements, thus > servers SHOULD preserve the [prefix] as well. [[preserve.more.xml: > Feedback if we should ask implementors to preserve more in the future > is appreciated (such as comments).]] > > XML Infoset attributes not listed above MAY be preserved by the > server, but clients MUST NOT rely on them being preserved. > > Also note that whitespace inside values is always significant, and > that servers MUST NOT support overriding this using the xml:space > attribute. > > 4.4.1 Example - Property with Mixed Content > > Consider a dead property 'author' created by the client as follows: > > > > Jane Doe > > >mailto:jane.doe@example.com > >http://www.example.com > > Jane has been working way too long on the > long-awaited revision of ]]>. > > > > > When retrieving the property, a server may return: > > > xmlns:x="http://example.com/ns" > xml:lang="en"> > Jane Doe > >mailto:jane.doe@example.com > >http://www.example.com > > Jane has been working way too long on the > long-awaited revision of <RFC2518>. > > > > > Note: > > o The [prefix] for the property name itself was not preserved, being > non-significant, > > o attribute values have been rewritten with double quotes instead of > single quotes (quoting style is not significant), and attribute > order has not been preserved, > > o the xml:lang attribute has been returned on the property name > element itself (it was in scope when the property was set, but the > exact position in the response is not considered significant as > long as it is in scope), > > o the [prefix] has been preserved on the child element "notes", > > o whitespace between tags has been preserved everywhere (but the > fact that CDATA escaping was used is irrelevant), and > > o the comment item was stripped (as would have been a processing > instruction item). > > Implementation note: > > There are cases such as editing scenarios where clients may > require that XML content is preserved character-by-character (such > as attribute ordering or quoting style). In this case, clients > should consider using a text-only property value by escaping all > characters that have a special meaning in XML parsing. > > --=_alternative 005A2E99852570DF_= Content-Type: text/html; charset="US-ASCII"
(1) I support adding an explicit recommendation that servers
preserve namespace prefixes in property values.  I'm neutral
on whether we use the term "SHOULD" in that recommendation.

(2) I do not support adding a recommendation that comments be
preserved, since I have seen no use cases proposed that require this.

Cheers,
Geoff

Julian wrote on 12/22/2005 10:51:15 AM:

>
> Hi,
>
> I'd like to understand where we stand regarding property value round
> tripping. Proposed text was posted in BugZilla (see
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10>), and as far
> as I can tell, two questions were left and sent to the mailing list for
> discussion?
>
> 1) We're trying to encourage servers to preserve namespace prefixes,
> thus making it a SHOULD level requirement.
>
> 2) Is there any interest in comments being preserved?
>
> Re 1): there was little feedback on that, expcet for Wilfredo who's
> concerned that people may be reyling on XML serializers that throw out
> that information. Do people think that therefore SHOULD is too strong,
> or would we just have to live that some servers wouldn't be able to do
> it (it's not a MUST, after all).
>
> Re 2): I don't think we got any feedback on this. As XML parsers are not
> required to pass on information from comments, I'm inclined to say: not
> a SHOULD (thus leave it in the bag of optional things servers can always
> do).
>
> So please try to give feedback on these two questions, and on the
> suggested text in BugZilla. Hopefully then it can make it into the next
> draft.
>
> Best regards,
>
> Julian
>
> -- cut --
>
> 4.4  Property Values
>
>     The value of a property is always a (well-formed) XML fragment.
>
>     XML has been chosen because it is a flexible, self-describing,
>     structured data format that supports rich schema definitions, and
>     because of its support for multiple character sets.  XML's self-
>     describing nature allows any property's value to be extended by
>     adding new elements.  Older clients will not break when they
>     encounter extensions because they will still have the data specified
>     in the original schema and MUST ignore elements they do not
>     understand.
>
>     XML's support for multiple character sets allows any human-readable
>     property to be encoded and read in a character set familiar to the
>     user.  XML's support for multiple human languages, using the "xml:
>     lang" attribute, handles cases where the same character set is
>     employed by multiple human languages.  Note that xml:lang scope is
>     recursive, so a xml:lang attribute on any element containing a
>     property name element applies to the property value unless it has
>     been overridden by a more locally scoped attribute.  Note that a
>     property only has one value, in one language (or language MAY be left
>     undefined), not multiple values in different languages or a single
>     value in multiple languages.
>
>     A property is always presented with an XML element consisting of the
>     property name, called the "property name element".
>
>     The simplest example is an empty property, which is different from a
>     property that does not exist:
>
>        <title xmlns="http://www.example.com/ns/"></title>
>
>     The value of the property appears inside the property name element.
>     It may be any kind of well-formed XML content, including both text-
>     only and mixed content.  In the latter case, servers MUST preserve
>     certain aspects of the content.  Using the terminology from [REC-XML-
>     INFOSET], the following rules apply:
>
>     For the property name Element Information Item itself:
>
>        [namespace name],
>
>        [local name],
>
>        [attributes] named "xml:lang" or any such attribute in scope,
>
>        [children] of type element or character.
>
>     On all Element Information Items that are descendants of the property
>     name element:
>
>        [namespace name],
>
>        [local name],
>
>        [attributes] and
>
>        [children] of type element or character.
>
>     On Attribute Information Items:
>
>        [namespace name],
>
>        [local name] and
>
>        [normalized value].
>
>     On Character Information Items::
>
>        [character code].
>
>     Future revisions of this specification may also require to preserve
>     namespace prefixes for child elements of the property elements, thus
>     servers SHOULD preserve the [prefix] as well. [[preserve.more.xml:
>     Feedback if we should ask implementors to preserve more in the future
>     is appreciated (such as comments).]]
>
>     XML Infoset attributes not listed above MAY be preserved by the
>     server, but clients MUST NOT rely on them being preserved.
>
>     Also note that whitespace inside values is always significant, and
>     that servers MUST NOT support overriding this using the xml:space
>     attribute.
>
> 4.4.1  Example - Property with Mixed Content
>
>     Consider a dead property 'author' created by the client as follows:
>
>         <D:prop xml:lang='en' xmlns:D='DAV:'>
>           <x:author xmlns:x='http://example.com/ns'>
>             <x:name>Jane Doe</x:name>
>             <!-- Jane's contact info -->
>             <x:uri type='email' added='2005-11-26'
>             >mailto:jane.doe@example.com</x:uri>
>             <x:uri type='web' added='2005-11-27'
>             >http://www.example.com</x:uri>
>             <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
>               Jane has been working way <h:em>too</h:em> long on the
>               long-awaited revision of <![CDATA[<RFC2518>]]>.
>             </x:notes>
>           </x:author>
>         </D:prop>
>
>     When retrieving the property, a server may return:
>
>         <D:prop xmlns:D='DAV:'>
>           <author xmlns="http://example.com/ns"
>                      xmlns:x="http://example.com/ns"
>                      xml:lang="en">
>             <x:name>Jane Doe</x:name>
>             <x:uri added="2005-11-26" type="email"
>             >mailto:jane.doe@example.com</x:uri>
>             <x:uri added="2005-11-27" type="web"
>             >http://www.example.com</x:uri>
>             <x:notes xmlns:h="http://www.w3.org/1999/xhtml">
>               Jane has been working way <h:em>too</h:em> long on the
>               long-awaited revision of &lt;RFC2518&gt;.
>             </x:notes>
>           </author>
>         </D:prop>
>
>     Note:
>
>     o  The [prefix] for the property name itself was not preserved, being
>        non-significant,
>
>     o  attribute values have been rewritten with double quotes instead of
>        single quotes (quoting style is not significant), and attribute
>        order has not been preserved,
>
>     o  the xml:lang attribute has been returned on the property name
>        element itself (it was in scope when the property was set, but the
>        exact position in the response is not considered significant as
>        long as it is in scope),
>
>     o  the [prefix] has been preserved on the child element "notes",
>
>     o  whitespace between tags has been preserved everywhere (but the
>        fact that CDATA escaping was used is irrelevant), and
>
>     o  the comment item was stripped (as would have been a processing
>        instruction item).
>
>     Implementation note:
>
>        There are cases such as editing scenarios where clients may
>        require that XML content is preserved character-by-character (such
>        as attribute ordering or quoting style).  In this case, clients
>        should consider using a text-only property value by escaping all
>        characters that have a special meaning in XML parsing.
>
>
--=_alternative 005A2E99852570DF_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 12:56:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpUgM-0006CK-HI for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 12:56:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12419 for ; Thu, 22 Dec 2005 12:55:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpUeM-00065x-2k for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 17:54:46 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EpUe5-00063Y-6f for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 17:54:29 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by maggie.w3.org with esmtp (Exim 4.50) id 1EpUdo-0001t5-7W for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 17:54:28 +0000 Received: from [128.114.56.106] (atari.cse.ucsc.edu [128.114.56.106]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBMHrtpw013856 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 Dec 2005 09:53:55 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/alternative; boundary=Apple-Mail-6-200528311 Message-Id: <014DD6E2-7167-40BF-BC1B-8084D3D55A27@cs.ucsc.edu> Cc: " webdav" From: Jim Whitehead Date: Thu, 22 Dec 2005 09:53:54 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.746.2) Received-SPF: none (maggie.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.2 X-W3C-Scan-Sig: maggie.w3.org 1EpUdo-0001t5-7W aca0314f7a4c94969a26258c5042c67e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/014DD6E2-7167-40BF-BC1B-8084D3D55A27@cs.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11330 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 17:54:46 +0000 --Apple-Mail-6-200528311 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I agree with Geoff, with the minor twist that I'm fine with (1) being a SHOULD. - Jim On Dec 22, 2005, at 8:24 AM, Geoffrey M Clemm wrote: > > (1) I support adding an explicit recommendation that servers > preserve namespace prefixes in property values. I'm neutral > on whether we use the term "SHOULD" in that recommendation. > > (2) I do not support adding a recommendation that comments be > preserved, since I have seen no use cases proposed that require this. > > Cheers, > Geoff > > Julian wrote on 12/22/2005 10:51:15 AM: > > > > > Hi, > > > > I'd like to understand where we stand regarding property value round > > tripping. Proposed text was posted in BugZilla (see > > ), and > as far > > as I can tell, two questions were left and sent to the mailing > list for > > discussion? > > > > 1) We're trying to encourage servers to preserve namespace prefixes, > > thus making it a SHOULD level requirement. > > > > 2) Is there any interest in comments being preserved? > > > > Re 1): there was little feedback on that, expcet for Wilfredo who's > > concerned that people may be reyling on XML serializers that > throw out > > that information. Do people think that therefore SHOULD is too > strong, > > or would we just have to live that some servers wouldn't be able > to do > > it (it's not a MUST, after all). > > > > Re 2): I don't think we got any feedback on this. As XML parsers > are not > > required to pass on information from comments, I'm inclined to > say: not > > a SHOULD (thus leave it in the bag of optional things servers can > always > > do). > > > > So please try to give feedback on these two questions, and on the > > suggested text in BugZilla. Hopefully then it can make it into > the next > > draft. > > > > Best regards, > > > > Julian > > > > -- cut -- > > > > 4.4 Property Values > > > > The value of a property is always a (well-formed) XML fragment. > > > > XML has been chosen because it is a flexible, self-describing, > > structured data format that supports rich schema definitions, > and > > because of its support for multiple character sets. XML's self- > > describing nature allows any property's value to be extended by > > adding new elements. Older clients will not break when they > > encounter extensions because they will still have the data > specified > > in the original schema and MUST ignore elements they do not > > understand. > > > > XML's support for multiple character sets allows any human- > readable > > property to be encoded and read in a character set familiar > to the > > user. XML's support for multiple human languages, using the > "xml: > > lang" attribute, handles cases where the same character set is > > employed by multiple human languages. Note that xml:lang > scope is > > recursive, so a xml:lang attribute on any element containing a > > property name element applies to the property value unless it > has > > been overridden by a more locally scoped attribute. Note that a > > property only has one value, in one language (or language MAY > be left > > undefined), not multiple values in different languages or a > single > > value in multiple languages. > > > > A property is always presented with an XML element consisting > of the > > property name, called the "property name element". > > > > The simplest example is an empty property, which is different > from a > > property that does not exist: > > > > > > > > The value of the property appears inside the property name > element. > > It may be any kind of well-formed XML content, including both > text- > > only and mixed content. In the latter case, servers MUST > preserve > > certain aspects of the content. Using the terminology from > [REC-XML- > > INFOSET], the following rules apply: > > > > For the property name Element Information Item itself: > > > > [namespace name], > > > > [local name], > > > > [attributes] named "xml:lang" or any such attribute in scope, > > > > [children] of type element or character. > > > > On all Element Information Items that are descendants of the > property > > name element: > > > > [namespace name], > > > > [local name], > > > > [attributes] and > > > > [children] of type element or character. > > > > On Attribute Information Items: > > > > [namespace name], > > > > [local name] and > > > > [normalized value]. > > > > On Character Information Items:: > > > > [character code]. > > > > Future revisions of this specification may also require to > preserve > > namespace prefixes for child elements of the property > elements, thus > > servers SHOULD preserve the [prefix] as well. > [[preserve.more.xml: > > Feedback if we should ask implementors to preserve more in > the future > > is appreciated (such as comments).]] > > > > XML Infoset attributes not listed above MAY be preserved by the > > server, but clients MUST NOT rely on them being preserved. > > > > Also note that whitespace inside values is always > significant, and > > that servers MUST NOT support overriding this using the > xml:space > > attribute. > > > > 4.4.1 Example - Property with Mixed Content > > > > Consider a dead property 'author' created by the client as > follows: > > > > > > > > Jane Doe > > > > > >mailto:jane.doe@example.com > > > >http://www.example.com > > > > Jane has been working way too long on the > > long-awaited revision of ]]>. > > > > > > > > > > When retrieving the property, a server may return: > > > > > > > xmlns:x="http://example.com/ns" > > xml:lang="en"> > > Jane Doe > > > >mailto:jane.doe@example.com > > > >http://www.example.com > > > > Jane has been working way too long on the > > long-awaited revision of <RFC2518>. > > > > > > > > > > Note: > > > > o The [prefix] for the property name itself was not > preserved, being > > non-significant, > > > > o attribute values have been rewritten with double quotes > instead of > > single quotes (quoting style is not significant), and > attribute > > order has not been preserved, > > > > o the xml:lang attribute has been returned on the property name > > element itself (it was in scope when the property was set, > but the > > exact position in the response is not considered > significant as > > long as it is in scope), > > > > o the [prefix] has been preserved on the child element "notes", > > > > o whitespace between tags has been preserved everywhere (but > the > > fact that CDATA escaping was used is irrelevant), and > > > > o the comment item was stripped (as would have been a > processing > > instruction item). > > > > Implementation note: > > > > There are cases such as editing scenarios where clients may > > require that XML content is preserved character-by- > character (such > > as attribute ordering or quoting style). In this case, > clients > > should consider using a text-only property value by > escaping all > > characters that have a special meaning in XML parsing. > > > > --Apple-Mail-6-200528311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Geoff, with = the minor twist that I'm fine with (1) being a SHOULD.

- Jim

On = Dec 22, 2005, at 8:24 AM, Geoffrey M Clemm wrote:


(1) I support adding an explicit recommendation that = servers
preserve namespace prefixes = in property values. =A0I'm neutral
on= whether we use the term "SHOULD" in that recommendation. =

(2) I do not support adding a = recommendation that comments be
preserved, since I have seen no use cases proposed that = require this.

Cheers,
Geoff

Julian = wrote on 12/22/2005 10:51:15 AM:

>
> Hi,
> =
> I'd like to understand where we stand regarding property value = round
> tripping. Proposed text was posted in BugZilla (see
= > <http:= //ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3D10>), and as = far
> as I can tell, two questions were left and sent to the = mailing list for
> discussion?
>
> 1) We're = trying to encourage servers to preserve namespace prefixes,
> = thus making it a SHOULD level requirement.
>
> 2) Is = there any interest in comments being preserved?
>
> Re = 1): there was little feedback on that, expcet for Wilfredo who's
= > concerned that people may be reyling on XML serializers that throw = out
> that information. Do people think that therefore SHOULD is = too strong,
> or would we just have to live that some servers = wouldn't be able to do
> it (it's not a MUST, after all).
= >
> Re 2): I don't think we got any feedback on this. As XML = parsers are not
> required to pass on information from comments, = I'm inclined to say: not
> a SHOULD (thus leave it in the bag of = optional things servers can always
> do).
>
> So = please try to give feedback on these two questions, and on the
> = suggested text in BugZilla. Hopefully then it can make it into the next =
> draft.
>
> Best regards,
>
> = Julian
>
> -- cut --
>
> 4.4 =A0Property = Values
>
> =A0 =A0 The value of a property is always a = (well-formed) XML fragment.
>
> =A0 =A0 XML has been = chosen because it is a flexible, self-describing,
> =A0 =A0 = structured data format that supports rich schema definitions, and
= > =A0 =A0 because of its support for multiple character sets. =A0XML's = self-
> =A0 =A0 describing nature allows any property's value to = be extended by
> =A0 =A0 adding new elements. =A0Older clients = will not break when they
> =A0 =A0 encounter extensions because = they will still have the data specified
> =A0 =A0 in the original = schema and MUST ignore elements they do not
> =A0 =A0 = understand.
>
> =A0 =A0 XML's support for multiple = character sets allows any human-readable
> =A0 =A0 property to be = encoded and read in a character set familiar to the
> =A0 =A0 = user. =A0XML's support for multiple human languages, using the "xml:
= > =A0 =A0 lang" attribute, handles cases where the same character set = is
> =A0 =A0 employed by multiple human languages. =A0Note that = xml:lang scope is
> =A0 =A0 recursive, so a xml:lang attribute on = any element containing a
> =A0 =A0 property name element applies = to the property value unless it has
> =A0 =A0 been overridden by = a more locally scoped attribute. =A0Note that a
> =A0 =A0 = property only has one value, in one language (or language MAY be = left
> =A0 =A0 undefined), not multiple values in different = languages or a single
> =A0 =A0 value in multiple languages.
= >
> =A0 =A0 A property is always presented with an XML = element consisting of the
> =A0 =A0 property name, called the = "property name element".
>
> =A0 =A0 The simplest example = is an empty property, which is different from a
> =A0 =A0 = property that does not exist:
>
> =A0 =A0 =A0 =A0<title = xmlns=3D"http://www.example.com/ns/"><= ;/title>
>
> =A0 =A0 The value of the property appears = inside the property name element.
> =A0 =A0 It may be any kind of = well-formed XML content, including both text-
> =A0 =A0 only and = mixed content. =A0In the latter case, servers MUST preserve
> =A0 = =A0 certain aspects of the content. =A0Using the terminology from = [REC-XML-
> =A0 =A0 INFOSET], the following rules apply:
> =
> =A0 =A0 For the property name Element Information Item = itself:
>
> =A0 =A0 =A0 =A0[namespace name],
> =
> =A0 =A0 =A0 =A0[local name],
>
> =A0 =A0 =A0 = =A0[attributes] named "xml:lang" or any such attribute in scope,
= >
> =A0 =A0 =A0 =A0[children] of type element or = character.
>
> =A0 =A0 On all Element Information Items = that are descendants of the property
> =A0 =A0 name element:
= >
> =A0 =A0 =A0 =A0[namespace name],
>
> =A0 =A0= =A0 =A0[local name],
>
> =A0 =A0 =A0 =A0[attributes] = and
>
> =A0 =A0 =A0 =A0[children] of type element or = character.
>
> =A0 =A0 On Attribute Information = Items:
>
> =A0 =A0 =A0 =A0[namespace name],
>
= > =A0 =A0 =A0 =A0[local name] and
>
> =A0 =A0 =A0 = =A0[normalized value].
>
> =A0 =A0 On Character = Information Items::
>
> =A0 =A0 =A0 =A0[character = code].
>
> =A0 =A0 Future revisions of this specification = may also require to preserve
> =A0 =A0 namespace prefixes for = child elements of the property elements, thus
> =A0 =A0 servers = SHOULD preserve the [prefix] as well. [[preserve.more.xml:
> =A0 = =A0 Feedback if we should ask implementors to preserve more in the = future
> =A0 =A0 is appreciated (such as comments).]]
> =
> =A0 =A0 XML Infoset attributes not listed above MAY be = preserved by the
> =A0 =A0 server, but clients MUST NOT rely on = them being preserved.
>
> =A0 =A0 Also note that = whitespace inside values is always significant, and
> =A0 =A0 = that servers MUST NOT support overriding this using the xml:space
= > =A0 =A0 attribute.
>
> 4.4.1 =A0Example - Property = with Mixed Content
>
> =A0 =A0 Consider a dead property = 'author' created by the client as follows:
>
> =A0 =A0 =A0 = =A0 <D:prop xml:lang=3D'en' xmlns:D=3D'DAV:'>
> =A0 =A0 =A0 = =A0 =A0 <x:author xmlns:x=3D'http://example.com/ns'>
> = =A0 =A0 =A0 =A0 =A0 =A0 <x:name>Jane Doe</x:name>
> =A0= =A0 =A0 =A0 =A0 =A0 <!-- Jane's contact info -->
> =A0 =A0 = =A0 =A0 =A0 =A0 <x:uri type=3D'email' added=3D'2005-11-26'
> =A0= =A0 =A0 =A0 =A0 =A0 >mailto:jane.doe@example.com</x= :uri>
> =A0 =A0 =A0 =A0 =A0 =A0 <x:uri type=3D'web' = added=3D'2005-11-27'
> =A0 =A0 =A0 =A0 =A0 =A0 >http://www.example.com</x:uri> > =A0 =A0 =A0 =A0 =A0 =A0 <x:notes xmlns:h=3D'http://www.w3.org/1999/xhtml'&g= t;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jane has been working way = <h:em>too</h:em> long on the
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 long-awaited revision of <![CDATA[<RFC2518>]]>.
> = =A0 =A0 =A0 =A0 =A0 =A0 </x:notes>
> =A0 =A0 =A0 =A0 =A0 = </x:author>
> =A0 =A0 =A0 =A0 </D:prop>
>
= > =A0 =A0 When retrieving the property, a server may return:
> =
> =A0 =A0 =A0 =A0 <D:prop xmlns:D=3D'DAV:'>
> =A0 =A0= =A0 =A0 =A0 <author xmlns=3D"http://example.com/ns"
> =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns:x=3D"http://example.com/ns"
> =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xml:lang=3D"en">
> =A0 =A0 = =A0 =A0 =A0 =A0 <x:name>Jane Doe</x:name>
> =A0 =A0 =A0= =A0 =A0 =A0 <x:uri added=3D"2005-11-26" type=3D"email"
> =A0 = =A0 =A0 =A0 =A0 =A0 >mailto:jane.doe@example.com</x= :uri>
> =A0 =A0 =A0 =A0 =A0 =A0 <x:uri added=3D"2005-11-27" = type=3D"web"
> =A0 =A0 =A0 =A0 =A0 =A0 >http://www.example.com</x:uri> > =A0 =A0 =A0 =A0 =A0 =A0 <x:notes xmlns:h=3D"http://www.w3.org/1999/xhtml">= ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jane has been working way = <h:em>too</h:em> long on the
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 long-awaited revision of &lt;RFC2518&gt;.
> =A0 =A0 =A0= =A0 =A0 =A0 </x:notes>
> =A0 =A0 =A0 =A0 =A0 = </author>
> =A0 =A0 =A0 =A0 </D:prop>
>
= > =A0 =A0 Note:
>
> =A0 =A0 o =A0The [prefix] for the = property name itself was not preserved, being
> =A0 =A0 =A0 = =A0non-significant,
>
> =A0 =A0 o =A0attribute values = have been rewritten with double quotes instead of
> =A0 =A0 =A0 = =A0single quotes (quoting style is not significant), and attribute
= > =A0 =A0 =A0 =A0order has not been preserved,
>
> =A0 = =A0 o =A0the xml:lang attribute has been returned on the property = name
> =A0 =A0 =A0 =A0element itself (it was in scope when the = property was set, but the
> =A0 =A0 =A0 =A0exact position in the = response is not considered significant as
> =A0 =A0 =A0 =A0long = as it is in scope),
>
> =A0 =A0 o =A0the [prefix] has = been preserved on the child element "notes",
>
> =A0 =A0 = o =A0whitespace between tags has been preserved everywhere (but the
= > =A0 =A0 =A0 =A0fact that CDATA escaping was used is irrelevant), = and
>
> =A0 =A0 o =A0the comment item was stripped (as = would have been a processing
> =A0 =A0 =A0 =A0instruction = item).
>
> =A0 =A0 Implementation note:
>
= > =A0 =A0 =A0 =A0There are cases such as editing scenarios where = clients may
> =A0 =A0 =A0 =A0require that XML content is = preserved character-by-character (such
> =A0 =A0 =A0 =A0as = attribute ordering or quoting style). =A0In this case, clients
> = =A0 =A0 =A0 =A0should consider using a text-only property value by = escaping all
> =A0 =A0 =A0 =A0characters that have a special = meaning in XML parsing.
>
>
=

= --Apple-Mail-6-200528311-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 13:27:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpV9n-0000rt-Rm for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 13:27:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15878 for ; Thu, 22 Dec 2005 13:26:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpV8b-0008MI-KN for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 18:26:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EpV8N-0008Lc-Vm for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 18:25:47 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.50) id 1EpV8F-00076I-Qn for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 18:25:47 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBMIPaE2018369 for ; Thu, 22 Dec 2005 13:25:36 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBMIPbjk096106 for ; Thu, 22 Dec 2005 13:25:37 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBMIPaPx020885 for ; Thu, 22 Dec 2005 13:25:36 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBMIPaEl020882 for ; Thu, 22 Dec 2005 13:25:36 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 22 Dec 2005 13:25:30 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/22/2005 13:25:36, Serialize complete at 12/22/2005 13:25:36 Content-Type: multipart/alternative; boundary="=_alternative 00654309852570DF_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EpV8F-00076I-Qn 594169250a909f35d1cc14a2a06ee55d X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/OFB673ADA2.6F0914A4-ON852570DF.00647D6B-852570DF.00654386@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11331 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 18:26:01 +0000 This is a multipart message in MIME format. --=_alternative 00654309852570DF_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable There were several postings (most recently, one a couple of weeks ago) that explained why escaping the XML as #PCDATA has a variety of problems. For example: So until a non-problematic solution is proposed, I stick by my preference for a recommendation that servers preserve namespaces (namespace preserving parsers are not that hard to come by, so I don't see this as an unreasonable recommendation). Cheers, Geoff Wilfredo S=E1nchez Vega wrote on 12/22/2005 01:12:23=20 PM: > For what it's worth, I talked to Greg Stein about this at=20 > ApacheCon, and his position is that namespaces will not be preserved=20 > by mod=5Fdav, insofar as they are not semantically meaningful to a=20 > namespace-aware XML parser. The presence of other specifications=20 > which add semantic meaning to then doesn't change that. >=20 > This is basically the position I was taking. >=20 > I (and I believe Greg) don't think this belongs in the spec, even=20 > as a SHOULD. An explicit recommendation that clients sent properties=20 > as #PCDATA still makes a lot more sense to me. >=20 > I have yet to hear a reason why serializing the property as=20 > #PCDATA isn't an acceptable solution for whose who wish to avoid=20 > forcing the server parse (and therefore interpret) the property value. >=20 > -wsv >=20 >=20 > On Dec 22, 2005, at 8:24 AM, Geoffrey M Clemm wrote: >=20 > > (1) I support adding an explicit recommendation that servers > > preserve namespace prefixes in property values. I'm neutral > > on whether we use the term "SHOULD" in that recommendation. >=20 --=_alternative 00654309852570DF_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
There were several postings (most recently, one a couple of weeks ago)
that explained why escaping the XML as #PCDATA has a variety of problems.
For example:
<http://lists.w3.org/Archives/Public/w3c-dist-aut= h/2005OctDec/1056.html>
So until a non-problematic solution is proposed, I stick by my
preference for a recommendation that servers preserve namespaces
(namespace preserving parsers are not that hard to come by, so I
don't see this as an unreasonable recommendation).

Cheers,
Geoff

Wilfredo S=E1nchez Vega <wsanchez@apple.com> w= rote on 12/22/2005 01:12:23 PM:

>    For what it's worth, I talked to Greg Stein about this at  
> ApacheCon, and his position is that namespaces will not be preserved  
> by mod=5Fdav, insofar as they are not semantically meaningful to a &nb= sp;
> namespace-aware XML parser.  The presence of other specifications  
> which add semantic meaning to then doesn't change that.
>
>    This is basically the position I was taking.
>
>    I (and I believe Greg) don't think this belongs in the spec, even  
> as a SHOULD.  An explicit recommendation that clients sent proper= ties  
> as #PCDATA still makes a lot more sense to me.
>
>    I have yet to hear a reason why serializing the property as  
> #PCDATA isn't an acceptable solution for whose who wish to avoid  = ;
> forcing the server parse (and therefore interpret) the property value.=
>
>    -wsv
>
>
> On Dec 22, 2005, at 8:24 AM, Geoffrey M Clemm wrote:
>
> > (1) I support adding an explicit recommendation that servers
> > preserve namespace prefixes in property values.  I'm neutral=
> > on whether we use the term "SHOULD" in that recommendat= ion.
>
--=_alternative 00654309852570DF_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 13:48:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpVUA-000175-Rk for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 13:48:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18342 for ; Thu, 22 Dec 2005 13:47:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpVSV-0004fF-Vg for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 18:46:35 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpVSQ-0004ea-RR for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 18:46:31 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EpVSJ-0003iq-PI for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 18:46:29 +0000 Received: (qmail invoked by alias); 22 Dec 2005 18:46:19 -0000 Received: from p508FADF9.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.249] by mail.gmx.net (mp032) with SMTP; 22 Dec 2005 19:46:19 +0100 X-Authenticated: #1915285 Message-ID: <43AAF401.3080507@gmx.de> Date: Thu, 22 Dec 2005 19:44:17 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpVSJ-0003iq-PI 5e00d427ffb499541fb9824aa771c26b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/43AAF401.3080507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11332 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 18:46:35 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA18342 Hm, Wilfredo's mail didn't arrive here (yet). Geoffrey M Clemm wrote: >=20 > There were several postings (most recently, one a couple of weeks ago) > that explained why escaping the XML as #PCDATA has a variety of problem= s. > For example: > > So until a non-problematic solution is proposed, I stick by my > preference for a recommendation that servers preserve namespaces > (namespace preserving parsers are not that hard to come by, so I > don't see this as an unreasonable recommendation). >=20 > Cheers, > Geoff >=20 > Wilfredo S=E1nchez Vega wrote on 12/22/2005 01:12:= 23 PM: >=20 > > For what it's worth, I talked to Greg Stein about this at =20 > > ApacheCon, and his position is that namespaces will not be preserved= =20 > > by mod_dav, insofar as they are not semantically meaningful to a =20 > > namespace-aware XML parser. The presence of other specifications =20 Yes, they are. This has been explained numerous time. But anyway: - there's no W3C spec that would license an XML processor to throw away=20 prefixes - there are multiple W3C specs that use prefixes in attribute values (or=20 even text content), including XSLT and XML Schema So please everybody try to understand the issue before claiming prefixes=20 aren't relevant. In *most* cases they aren't. In *some* cases they are. > > which add semantic meaning to then doesn't change that. > > > > This is basically the position I was taking. > > > > I (and I believe Greg) don't think this belongs in the spec, even= =20 > > as a SHOULD. An explicit recommendation that clients sent propertie= s =20 > > as #PCDATA still makes a lot more sense to me. > > > > I have yet to hear a reason why serializing the property as =20 > > #PCDATA isn't an acceptable solution for whose who wish to avoid =20 > > forcing the server parse (and therefore interpret) the property valu= e. A property value serialized as #PCDATA (thus as escaped XML) is=20 something else than a property value serialized as XML. If you control=20 the format, such as when you define the property in a spec, you sure=20 have the freedom to say it's text, instead of XML. But this requires=20 that senders and recipients agree on that. But in general, a client=20 doesn't have that choice. Furthermore, putting escaped XML into property values *will* have=20 negative effects on generic clients (which will display angle brackets=20 to the user) and some protocol extensions (such as DASL). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Dec 22 18:03:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpZT4-0005CH-Hf for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 18:03:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15725 for ; Thu, 22 Dec 2005 18:02:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpZRN-0004Hy-Gy for w3c-dist-auth-dist@listhub.w3.org; Thu, 22 Dec 2005 23:01:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EpZR9-0004HA-5L for w3c-dist-auth@listhub.w3.org; Thu, 22 Dec 2005 23:01:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EpZQy-0003fL-Gi for w3c-dist-auth@w3.org; Thu, 22 Dec 2005 23:01:26 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBMN1Fnm018012; Thu, 22 Dec 2005 15:01:15 -0800 Date: Thu, 22 Dec 2005 15:01:15 -0800 Message-Id: <200512222301.jBMN1Fnm018012@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EpZQy-0003fL-Gi 1837143fbb4c2e687677ba4bbe6d84d4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512222301.jBMN1Fnm018012@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11333 X-Loop: w3c-dist-auth@w3.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, 22 Dec 2005 23:01:41 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-22 15:01 ------- OK, the proposed change affects many individual parts, so I can't include the whole set of changes here (see for the complete picture). Summary: Fix description in Section 13.5. Update descriptions in Section 15. Merge stuff from Section 15 into Section 8.1.5 (removing overlaps and conflicting text). Minor changes where conditions are mentioned, mainly adding forward references to section Section 15. See issue 181 [13]. In particular: 8.1.5 Including error response bodies HTTP and WebDAV did not use the bodies of most error responses for machine-parsable information until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253]). The mechanism is appropriate to use with any error response that may take a body but does not already have a body defined. The mechanism is particularly appropriate when a status code can mean many things (for example, 400 Bad Request can mean required headers are missing, headers are incorrectly formatted, or much more). This mechanism does not take the place of using a correct numeric error code as defined here or in HTTP, because the client MUST always be able to take a reasonable course of action based only on the numeric error. However, it does remove the need to define new numeric error codes. The machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed. If a method precondition or postcondition for a request is not satisfied and unless specified explicitly otherwise, the response status of the request MUST be either 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. When a specific condition code is defined, and that condition is not satisfied, servers SHOULD return the XML element associated with the condition as the child of a top-level DAV:error element (Section 13.5) in the response body, unless otherwise negotiated by the request. Servers MAY include multiple XML elements if more than one condition could not be satisfied. In a 207 Multi-Status response, the DAV:error element would appear in the appropriate DAV:responsedescription element. In this specification, both the HTTP status code and the condition name are defined for some failure situations, in which case the XML condition element is in the "DAV:" namespace, appears in the "error" root element, and SHOULD be returned in a body with the specified numeric HTTP status code. 8.1.5.1 Example - Response with precondition code >>Response HTTP/1.1 403 Forbidden Content-Type: application/xml; charset="utf-8" Content-Length: xxxx 13.5 error XML Element Name: error Purpose: Error responses, particularly 403 Forbidden and 409 Conflict, sometimes need more information to indicate what went wrong. When an error response contains a body in WebDAV, the body is in XML with the root element 'error'. The 'error' element SHOULD include a an XML element with the name of the failed pre- or postcondition. Description: Contains any XML element 15. Precondition/postcondition XML elements Some other useful preconditions and postconditions have been defined in other specifications extending WebDAV, such as [RFC3253], [RFC3648] and [RFC3744] (see particularly Section 7.1.1). If not specified otherwise, the content for each condition's XML element is defined to be empty. 15.1 DAV:no-external-entities (precondition) If the request body is XML, and the server does not support external entities, this condition code can be used to signal the problem (see also Section 19.6). 15.2 DAV:lock-token-matches-request-uri (precondition) A request may include a Lock-Token header to identify a lock for the purposes of an operation such as refresh LOCK or UNLOCK. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use this condition code. 15.3 DAV:preserved-live-properties (postcondition) Servers may reject MOVE requests, if they cannot maintain live properties with the same behaviour at the destination URL. In this case, this postcondition name may be used to signal the failure condition. [[q-copy-live-prop: Does this really apply to COPY as well???]] 15.4 DAV:cannot-modify-protected-property (precondition) An attempt to modify a property that is defined by this document, as being protected for that kind of resource, MUST fail (see [RFC3253], Section 3.12). 15.5 DAV:propfind-finite-depth (precondition) Used to signal that a request was rejected because the server did not allow a value of "infinity" for the "Depth" request header. 15.6 DAV:lock-token-present (precondition) If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. Servers SHOULD insert DAV:href elements for the URLs of each root of a lock for which a lock token was needed, unless that URL identifies the same resource to that the request was sent. 15.6.1 Example In the example below, a client unaware of a "Depth: infinity" lock on the parent collection "/workspace/webdav/" attempts to modify the collection member "/workspace/webdav/proposal.doc". >>Request PUT /workspace/webdav/proposal.doc HTTP/1.1 Host: example.com >>Response HTTP/1.1 423 Locked Content-Type: application/xml; charset="utf-8" Content-Length: xxxx /workspace/webdav/ ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Thu Dec 22 20:27:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epbi4-0001gB-IK for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 20:27:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07281 for ; Thu, 22 Dec 2005 20:25:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpbgN-0005Yz-DK for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 01:25:19 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpbgA-0005YD-FH for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 01:25:06 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by aji.w3.org with esmtp (Exim 4.50) id 1Epbg6-0008TN-W1 for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 01:25:05 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBN1Oqma014223; Thu, 22 Dec 2005 17:24:54 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id D102F324013; Thu, 22 Dec 2005 17:24:51 -0800 (PST) In-Reply-To: <43A97355.9020808@gmx.de> References: <43A97355.9020808@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Dan Brotsky , Jim Whitehead , WebDav WG Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 22 Dec 2005 17:24:51 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (aji.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Epbg6-0008TN-W1 9a7ecf906d2fb6fecec497fddb7bd1cd X-Original-To: w3c-dist-auth@w3.org Subject: Re: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/BFF72785-C930-4444-89EE-BF3E6EBCD708@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11334 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 01:25:19 +0000 Content-Transfer-Encoding: 7bit Well, if it's fixable it's fixable down to one millisecond instead of second. I'm not sure why the window is one second. I agree that would be better, but you still have a (shorter) window. I can ask on the httpd list to see if anyone knows why our window is one second when apr_time_t is in milliseconds... but I'll wait to do that after the holiday break. I'm betting there's some filesystem with a one second resolution out there... If it's an OS limitation (as opposed to a filesystem one) we can probably contain the damage to that OS. -wsv On Dec 21, 2005, at 7:23 AM, Julian Reschke wrote: > I'm not sure why that would be, but the code in http_etag.c > certainly uses a hardwired constant for this. Maybe this is > fixable, in which case the problem would go away. Wilfredo? From w3c-dist-auth-request@frink.w3.org Thu Dec 22 21:49:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpczU-0008VR-HV for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 21:49:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13127 for ; Thu, 22 Dec 2005 21:48:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epcxs-0004J3-Ft for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 02:47:28 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Epcxd-0004Hg-AB for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 02:47:13 +0000 Received: from exprod6og1.obsmtp.com ([64.18.1.121]) by aji.w3.org with smtp (Exim 4.50) id 1EpcxU-0002Nl-Of for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 02:47:12 +0000 Received: from source ([192.150.20.142]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 22 Dec 2005 18:47:00 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBN2ksFX023080; Thu, 22 Dec 2005 18:46:54 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBN2ksrs019053; Thu, 22 Dec 2005 18:46:55 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 18:48:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6076B.527DB65C" Date: Thu, 22 Dec 2005 18:46:53 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYG/4WSJpp8lsomREGxiHYOLKInvQAa5NIw From: "Dan Brotsky" To: "Geoffrey M Clemm" , " webdav" X-OriginalArrivalTime: 23 Dec 2005 02:48:15.0696 (UTC) FILETIME=[52B27500:01C6076B] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpcxU-0002Nl-Of e181d778694bb39e65f818267fa31675 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9613@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11335 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 02:47:28 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6076B.527DB65C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Couldn't agree more with Geoff. =20 dan ________________________________ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Thursday, December 22, 2005 05:54 To: webdav Subject: Re: Summary of ETag related issues in RFC2518bis =09 =09 I believe that you are basing your conclusion on the assumption=20 that the authoring client can ignore the rewriting that is being done by the server. In that case, I (and I'm reasonably sure, Dan)=20 would agree that there is no need for the server to cancel the LOCK.=20 =09 But the case being discussed here is where the server has=20 rewritten the text and wants the client to base future edits on the =20 rewritten text. You may say "my server would never do that" or even=20 "I would never use a server that did that" (in which case you might=20 not want to spend any more time on this thread :-), but in case=20 the server did do that (and I have scenarios in which I can imagine=20 a server wanting to do that), I believe that automatically breaking=20 the lock is a good way of getting this point across to existing clients=20 (who don't know about the 205 convention).=20 =09 Cheers,=20 Geoff=20 =09 Yves wrote on 12/22/2005 03:18:03 AM: > On Thu, 22 Dec 2005, Julian Reschke wrote: >=20 > >> Julian: I agree with you, but did you think Dan was suggesting otherwise, > >> or were you just agreeing with Dan's statement (or at least, with the > >> "yes, it's OK" part)? I am assuming that you were not disagreeing > >> with Dan, since I don't believe he suggests anything that would make ETag > >> behavior depend on whether the resource was locked or not. > > > > I agree that servers can rewrite the content upon PUT, even if theresource=20 > > is locked. I do not agree that they need to break the lock to do that. >=20 > Agreed, lock is there to ensure other clients won't edit the resource. The=20 > server can do what it wants. =09 ------_=_NextPart_001_01C6076B.527DB65C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Couldn't agree more with = Geoff.
 
    dan

From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M=20 Clemm
Sent: Thursday, December 22, 2005 05:54
To:=20 webdav
Subject: Re: Summary of ETag related issues in=20 RFC2518bis


I believe that you are basing your = conclusion=20 on the assumption
that the = authoring client=20 can ignore the rewriting that is being
done=20 by the server.  In that case, I (and I'm reasonably sure,=20 Dan)
would agree that there is no = need for=20 the server to cancel the LOCK.

But the=20 case being discussed here is where the server has =
rewritten the text and wants the client to base future = edits on the=20  
rewritten text.  You = may say "my=20 server would never do that" or even
"I would=20 never use a server that did that" (in which case you might =
not want to spend any more time on this thread = :-), but=20 in case
the server did do that (and = I have=20 scenarios in which I can imagine
a = server=20 wanting to do that), I believe that automatically breaking =
the lock is a good way of getting this point = across to=20 existing clients
(who don't know = about the=20 205 convention).

Cheers,=20
Geoff

Yves wrote on=20 12/22/2005 03:18:03 AM:
> On Thu, 22 Dec 2005, Julian Reschke=20 wrote:
>
> >> Julian: I agree with you, but did you = think=20 Dan was suggesting otherwise,
> >> or were you just = agreeing with=20 Dan's statement (or at least, with the
> >> "yes, it's OK" = part)?=20   I am assuming that you were not disagreeing
> >> = with Dan,=20 since I don't believe he suggests anything that would make = ETag
>=20 >> behavior depend on whether the resource was locked or = not.
>=20 >
> > I agree that servers can rewrite the content upon = PUT, even=20 if theresource
> > is locked. I do not agree that they need = to break=20 the lock to do that.
>
> Agreed, lock is there to ensure = other=20 clients won't edit the resource. The
> server can do what it=20 wants.
 ------_=_NextPart_001_01C6076B.527DB65C-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 21:50:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epd0a-0000Qq-HW for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 21:50:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13345 for ; Thu, 22 Dec 2005 21:49:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epczk-0004bg-BN for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 02:49:24 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Epczh-0004b8-CZ for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 02:49:21 +0000 Received: from exprod6og6.obsmtp.com ([64.18.1.126]) by aji.w3.org with smtp (Exim 4.50) id 1EpczW-0003Av-NZ for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 02:49:20 +0000 Received: from source ([192.150.20.142]) by exprod6ob6.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 22 Dec 2005 18:49:06 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id jBN2n3FX023175; Thu, 22 Dec 2005 18:49:03 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id jBN2n4rs019161; Thu, 22 Dec 2005 18:49:04 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 18:50:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6076B.9F9FEB0E" Date: Thu, 22 Dec 2005 18:49:02 -0800 Message-ID: In-Reply-To: Thread-Topic: Summary of ETag related issues in RFC2518bis Thread-Index: AcYHAG1+EYn2QpyHRxuDEvP1TDWGogAatpSQ From: "Dan Brotsky" To: "Geoffrey M Clemm" , " webdav" X-OriginalArrivalTime: 23 Dec 2005 02:50:25.0230 (UTC) FILETIME=[9FE7C6E0:01C6076B] Received-SPF: none (aji.w3.org: domain of dbrotsky@adobe.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpczW-0003Av-NZ bdcf96d4a9eb905933bc159afb6209bf X-Original-To: w3c-dist-auth@w3.org Subject: RE: Summary of ETag related issues in RFC2518bis X-Archived-At: http://www.w3.org/mid/E1F796B37FB8544FA09F6258E7CED3BB4B9614@namail3.corp.adobe.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11336 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 02:49:24 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6076B.9F9FEB0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree we won't get this done for 2518bis. Too bad. Clients will just have to keep sending head after put, and hoping nothing changed in between. =20 dan ________________________________ From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Thursday, December 22, 2005 06:00 To: webdav Subject: Re: Summary of ETag related issues in RFC2518bis =09 =09 I agree with Julian that this is not something we should try to resolve=20 in 2518bis, and given the need to focus this group on 2518bis,=20 I will restrain myself from using up any additional working group bandwidth=20 on this (from my perspective, interesting) topic until 2518bis (and BIND)=20 is finalized.=20 =09 Cheers,=20 Geoff=20 =09 =09 Julian wrote on 12/22/2005 01:30:46 AM: > > Let me ask the converse question: If the server has the file, why > > can't it send the etag? That's all the spec is saying it should do. >=20 > 1) RFC2518 isn't saying it > 2) RFC2616 doesn't say what that means (or if it does it's doing that in=20 > such a vague way that reasonable people disagreed about what it means) > 3) The most widely deployed servers do not return an ETag (IIS 5.1, does=20 > anybody know about IIS 6), or return a weak ETag first >=20 > So this would be a normative change introducing a less-than-well-defined=20 > requirement, which doesn't even reflect what most servers do today. >=20 > So my proposal is to resolve 2) first, and then discuss an extension of=20 > RFC2518 that relies on it (conceivably containing other stuff like the=20 > requirement to store arbitrary dead properties and such). I really don't=20 > see how we can get this done in the time that has been allocated to us. =09 ------_=_NextPart_001_01C6076B.9F9FEB0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree we won't get this done for = 2518bis.  Too=20 bad.  Clients will just have to keep sending head after put, and = hoping=20 nothing changed in between.
 
    dan

From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M=20 Clemm
Sent: Thursday, December 22, 2005 06:00
To:=20 webdav
Subject: Re: Summary of ETag related issues in=20 RFC2518bis


I agree with Julian that this is not = something=20 we should try to resolve
in = 2518bis, and=20 given the need to focus this group on 2518bis,
I will restrain myself from using up any additional = working group=20 bandwidth
on this (from my = perspective,=20 interesting) topic until 2518bis (and BIND)
is finalized.

Cheers,
Geoff=20


Julian wrote on 12/22/2005 01:30:46 = AM:
>=20 > Let me ask the  converse question: If the server has the = file,=20 why
> > can't it send the etag?  That's all the spec is = saying=20 it should do.
>
> 1) RFC2518 isn't saying it
> 2) = RFC2616=20 doesn't say what that means (or if it does it's doing that in
> = such a=20 vague way that reasonable people disagreed about what it = means)
> 3) The=20 most widely deployed servers do not return an ETag (IIS 5.1, does =
>=20 anybody know about IIS 6), or return a weak ETag first
> =
> So=20 this would be a normative change introducing a less-than-well-defined =
>=20 requirement, which doesn't even reflect what most servers do = today.
>=20
> So my proposal is to resolve 2) first, and then discuss an = extension=20 of
> RFC2518 that relies on it (conceivably containing other = stuff like=20 the
> requirement to store arbitrary dead properties and such). = I=20 really don't
> see how we can get this done in the time that = has been=20 allocated to us.
 ------_=_NextPart_001_01C6076B.9F9FEB0E-- From w3c-dist-auth-request@frink.w3.org Thu Dec 22 21:51:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epd2C-0001Sp-6p for webdav-archive@megatron.ietf.org; Thu, 22 Dec 2005 21:51:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13468 for ; Thu, 22 Dec 2005 21:50:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epd1G-00058k-A2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 02:50:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Epd1C-00058C-S2 for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 02:50:55 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1Epd19-0004Xd-8k for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 02:50:54 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBN2omHH020020; Thu, 22 Dec 2005 18:50:48 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 0165F324002; Thu, 22 Dec 2005 18:50:48 -0800 (PST) In-Reply-To: <43AAF401.3080507@gmx.de> References: <43AAF401.3080507@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: webdav Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Thu, 22 Dec 2005 18:50:47 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Epd19-0004Xd-8k 05b22b72df0c7c4ae103b5ec1d6432b3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/D8B14212-CF7B-45AD-A422-9C0E7C57DD53@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11337 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 02:50:58 +0000 Content-Transfer-Encoding: 7bit On Dec 22, 2005, at 10:44 AM, Julian Reschke wrote: > Wilfredo's mail didn't arrive here (yet). Sorry, I sent it from my apple.com account, and I haven't figured out how to subscribe to a W3C list without delivery (so it can post without moderation). > - there's no W3C spec that would license an XML processor to throw > away prefixes I showed you an example of python code that parses XML and spits it right back out and the namespace prefixes were edits. You said that wasn't a bug in PyXML. If PyXML is not a compliant XML library because it rewrites the prefixes, then I agree completely. PyXML is broken and should be fixed, and we should move on. But if that's not true, I don't think a server write should have switch to another library or do some haquery in order to preserve them. Geoff asserts that namespace preserving parsers are easy to come by. That may be true for Geoff, and maybe he has a lot of flexibility in parser choices because he has no other such constraints. I don't think that's true for everyone. Furthermore, in the case where a namespace is defined outside of the property container, some rewriting is required in order to maintain the association with the target URI. So now we have language in 4.4 saying that changing the property container's prefix, unlike it's contents, are not significant, and suggest in 4.4.1 suggesting that we should rewrite that tag to put all of the namespaces in there (seems like that should be explicitly stated in 4.4 as a SHOULD as well, for consistency, unless we think tossing the namespace declarations out is OK, which is the opposite of what I'd expect). Aside from the mild weirdness of "it's significant, except for over here"... now it's not just good enough to use a parser that can preserves prefixes, but also I need it to let me specify that I can't edit them, "except for this in one element, where I need you to do the rewriting that you may otherwise have elsewhere." What DOM methods exist for that sort of thing? > - there are multiple W3C specs that use prefixes in attribute > values (or even text content), including XSLT and XML Schema And I'm all for servers that care about enabling the use of these specs bending over to accommodate them, but I don't think that other servers need to care. Additionally: http://www.w3.org/TR/REC-xml-names/ Section 3: "Note that the prefix functions only as a placeholder for a namespace name." (Note "only" is emphasized in the text...) It's not unreasonable to think that having parsed that data, when rendering it back out, the placeholder might be relabeled without negative consequences. Regardless of that assumption, that sentence makes it pretty clear than using the prefix for any other purposes is inconsistent with REC-xml-names. > A property value serialized as #PCDATA (thus as escaped XML) is > something else than a property value serialized as XML. If you > control the format, such as when you define the property in a spec, > you sure have the freedom to say it's text, instead of XML. But > this requires that senders and recipients agree on that. But in > general, a client doesn't have that choice. If you define the property, senders and receivers always have to agree to honor your definition. That's not unique here. To me that's an argument for saying that such definitions SHOULD use #PCDATA. Geoff, I'm not following your argument that some clients might not de-serialize the data. If you have XML there, you have structured data. Either the client understands the property and does handles it properly or it doesn't. > Furthermore, putting escaped XML into property values *will* have > negative effects on generic clients (which will display angle > brackets to the user) and some protocol extensions (such as DASL). What's a generic client going to show the user for structured XML data that it doesn't understand? Generic client tends to refer to a tool for l33t haxx0rz. Perhaps I shouldn't get all bent out of shape over a SHOULD. -wsv From w3c-dist-auth-request@frink.w3.org Fri Dec 23 01:12:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epg9x-00080k-KB for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 01:12:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00795 for ; Fri, 23 Dec 2005 01:11:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epg8I-0005sg-DX for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 06:10:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Epg87-0005oh-8H for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 06:10:15 +0000 Received: from web53610.mail.yahoo.com ([206.190.37.43]) by lisa.w3.org with smtp (Exim 4.50) id 1Epg84-0007Te-T5 for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 06:10:14 +0000 Received: (qmail 5559 invoked by uid 60001); 23 Dec 2005 06:10:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nypeTfcgqBdL/gwFknXxSDw0YHIs7Z2l96ZrLTQI0O0q6A7G26dbNmoHSzptu989ta+DAC4EAQXFtxcJmAp/fzuITvjvumYefMlAZ8Q2dgAKje+C4vAJYwH8DYAXm2E6+IDA3XoaNzhiKsmwCD8+q0zfESUCuuVtK/AiXuLSFSk= ; Message-ID: <20051223061011.5557.qmail@web53610.mail.yahoo.com> Received: from [61.95.167.91] by web53610.mail.yahoo.com via HTTP; Thu, 22 Dec 2005 22:10:11 PST Date: Thu, 22 Dec 2005 22:10:11 -0800 (PST) From: vinod appajanna To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Received-SPF: none (lisa.w3.org: domain of vin_app@yahoo.com does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Epg84-0007Te-T5 a982d24be3afec5c8e1ed9632a55eb2f X-Original-To: w3c-dist-auth@w3.org Subject: Forms-Based Authentication in DAV - Explore X-Archived-At: http://www.w3.org/mid/20051223061011.5557.qmail@web53610.mail.yahoo.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11338 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 06:10:26 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA00795 Hi All!, Does any know if DAV-Explorer supports Forms-Based Authentication (Eg:- for connecting to Exchange Server). If it is not supported, are you planning to support this feature. Regards, Vinod =09 __________________________________________=20 Yahoo! DSL =96 Something to write home about.=20 Just $16.99/mo. or less.=20 dsl.yahoo.com=20 From w3c-dist-auth-request@frink.w3.org Fri Dec 23 02:28:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EphLd-00050q-17 for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 02:28:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07178 for ; Fri, 23 Dec 2005 02:27:10 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EphJW-0006kz-7q for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 07:26:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EphJG-0006jh-RG for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 07:25:50 +0000 Received: from relay2.es.uci.edu ([128.200.80.28]) by maggie.w3.org with esmtp (Exim 4.50) id 1EphJ5-0005f8-Bk for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 07:25:48 +0000 Received: from [128.195.105.234] (pv105234.reshsg.uci.edu [128.195.105.234]) (authenticated bits=0) by relay2.es.uci.edu (8.13.1/8.13.1) with ESMTP id jBN7PDHE026334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Dec 2005 23:25:14 -0800 X-UCInetID: jfeise Message-ID: <43ABA659.5010601@ics.uci.edu> Date: Thu, 22 Dec 2005 23:25:13 -0800 From: Joachim Feise Reply-To: jfeise@ics.uci.edu Organization: University of California, Irvine User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: vinod appajanna CC: w3c-dist-auth@w3.org, dav-exp@ics.uci.edu References: <20051223061011.5557.qmail@web53610.mail.yahoo.com> In-Reply-To: <20051223061011.5557.qmail@web53610.mail.yahoo.com> X-Enigmail-Version: 0.93.2.0 X-Message: MS Outlook is evil. X-Face: ".VkfaZ'q>9U9_]JOTykMM^88emlx:rG{m-5JHhsQ~\Cj43sZOq"rZTWsJG+%+R8#r_/o 6-TIJFfgXwgkDmCFG-v/3Gkt%k3%HwA#d&j6.R,7gb?UXNP0B;\npi/_a>x"(RyBjiOw*I.;8=.l {N[OuH;-p8LW0>]4$OW!z`-!Iy%2^?v9r.hn6$R+,dpC_zU+}91L{x_!4PK,P7\mv)`w{h(QTE)Z ?(p>OgR}}e!`'4jJ`b|$?lppz@wmLaLi[ Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEUNEwyOlI2nraUABQD N08x9g3xRV1Ds8usABAAAAgBs7OnJAAACQ0lEQVR4nF2TMW/cMAyFBRgQkFFGlF2EjawCBBTJmIN ar/U10uxLYu4NXGgtkMXZOvb+bZ9k52KX8HDmd3yUyGdxXmJ+c0JUzt2t72fxAZDP4f4Ha15Ud3v wZlcg7CeYEb+RYoQU1f0OWCF5DCHyIHbgDfmglNJxEGsTkdPOCeRrMiqwqLbAirGvicjkkgtwzlk eFeUwgeX9BkhGQeMPRJrl1R6Qz0EmcvW+BcemgMMK5jkPDmCsV0CRn5cKAOv4E9zwsEo59yRkuAC dwZ+rs4DQ47PsN0Cg4r2AFwActksTmi/gXIB1slwj+YNSIVbz/L4AZ2XfqxpKRukdEFEdm3LzxoQ 43P+dM7Co0ErdnMiTYkgNsMQMcMLydN1i6lST0n0cZFHBljMwRAdSeCgO1uHWIjOp86EMqcYTZSl RnlKB+xWAYX3P/3XlHnYDzAY4F/I6TNOWuf+wdgWVGwvwGWh+ttXSw1WVzIB822RQXQBGosu1QwZ DPs3afGx6HNSYQM0hAMCoVRn75AMsFeoQ6gwEjIoaJ6+T1zXmSjooEwZ4exBSfMFWU2ph3KBCBqe mBWBx7BJ29zUcMS1CXXzxU8xS3qfUpZ/jkbJ54epb71uGlJ9SmtIrhzx1WHdMnX/QkUUHgIhjbRQ h8YgXmIJFzoJ9g62Visy3eM/b/wC/8CFgrczdAnwBiFfmHp35tAfwWuSADuMxFTBdKlLLWShcF+k teIAO+nSlotuAV3QYVVEC+GyeklK9Uo/l57QDMLRalEr7f0PUUat8ZcMkAAAAAElFTkSuQmCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: none (maggie.w3.org: domain of jfeise@ics.uci.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EphJ5-0005f8-Bk dbd546c917f90579b8f6d673eefa3044 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Forms-Based Authentication in DAV - Explore X-Archived-At: http://www.w3.org/mid/43ABA659.5010601@ics.uci.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11339 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 07:26:06 +0000 Content-Transfer-Encoding: 7bit vinod appajanna wrote on 12/22/05 22:10: > Hi All!, > > Does any know if DAV-Explorer supports Forms-Based > Authentication (Eg:- for connecting to Exchange > Server). > > If it is not supported, are you planning to support > this feature. > > Regards, > Vinod Hello Vinod, please direct DAV Explorer-specific questions to the email address listed in the DAV Explorer readme file and on the DAV Explorer website: dav-exp at ics dot uci dot edu. To the question: DAV Explorer does not support Forms-based authentication and there are no plans to do so. Having said that, DAV Explorer is Open Source, so you are always welcome and encouraged to implement additional features that your application requires. We of course always welcome patches. Regards, -Joachim From w3c-dist-auth-request@frink.w3.org Fri Dec 23 04:35:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpjKY-000760-Vz for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 04:35:19 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18125 for ; Fri, 23 Dec 2005 04:34:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpjJC-0003CD-1L for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 09:33:54 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EpjIz-0003AJ-MD for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 09:33:42 +0000 Received: from mail.gmx.net ([213.165.64.21]) by aji.w3.org with smtp (Exim 4.50) id 1EpjIg-0004ZS-TG for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 09:33:40 +0000 Received: (qmail invoked by alias); 23 Dec 2005 09:33:17 -0000 Received: from p508FAFBA.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.175.186] by mail.gmx.net (mp001) with SMTP; 23 Dec 2005 10:33:17 +0100 X-Authenticated: #1915285 Message-ID: <43ABC404.3030409@gmx.de> Date: Fri, 23 Dec 2005 10:31:48 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: webdav References: <43AAF401.3080507@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EpjIg-0004ZS-TG 7e2bfcdfd0f8f9121cc9fd9bb3129c2c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/43ABC404.3030409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11340 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 09:33:54 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA18125 Wilfredo S=E1nchez Vega wrote: > ... >> - there's no W3C spec that would license an XML processor to throw=20 >> away prefixes >=20 > I showed you an example of python code that parses XML and spits it=20 > right back out and the namespace prefixes were edits. You said that=20 > wasn't a bug in PyXML. *Parsers* are not allowed to throw away prefixes. *Serializers* are=20 separate specs, and have been neglected by the W3C for quite some time.=20 I think DOM Level 3 talks about serialization. > If PyXML is not a compliant XML library because it rewrites the=20 > prefixes, then I agree completely. PyXML is broken and should be fixed= ,=20 > and we should move on. But if that's not true, I don't think a server=20 > write should have switch to another library or do some haquery in order= =20 > to preserve them. That's hard to tell unless PyXML claims to conform to some particular=20 specification that actually defines serialization. > Geoff asserts that namespace preserving parsers are easy to come by. = =20 > That may be true for Geoff, and maybe he has a lot of flexibility in=20 > parser choices because he has no other such constraints. I don't think= =20 > that's true for everyone. Didn't we find out last time that it's not the parser (input), but the=20 serializer (output)? > Furthermore, in the case where a namespace is defined outside of the=20 > property container, some rewriting is required in order to maintain the= =20 > association with the target URI. So now we have language in 4.4 saying= =20 > that changing the property container's prefix, unlike it's contents, ar= e=20 > not significant, and suggest in 4.4.1 suggesting that we should rewrite= =20 > that tag to put all of the namespaces in there (seems like that should=20 > be explicitly stated in 4.4 as a SHOULD as well, for consistency, unles= s=20 > we think tossing the namespace declarations out is OK, which is the=20 > opposite of what I'd expect). The spec doesn't say where the namespace declarations need to sit, as=20 long as they're there. And no, I wouldn't want to mandate this, because=20 that reallys seems to be irrelevant. > Aside from the mild weirdness of "it's significant, except for over=20 > here"... now it's not just good enough to use a parser that can=20 > preserves prefixes, but also I need it to let me specify that I can't=20 > edit them, "except for this in one element, where I need you to do the=20 > rewriting that you may otherwise have elsewhere." What DOM methods=20 > exist for that sort of thing? What does this have to do with editing? >> - there are multiple W3C specs that use prefixes in attribute values=20 >> (or even text content), including XSLT and XML Schema >=20 > And I'm all for servers that care about enabling the use of these=20 > specs bending over to accommodate them, but I don't think that other=20 > servers need to care. So you'd be happy would be "SHOULD" be a "MAY"? > Additionally: >=20 > http://www.w3.org/TR/REC-xml-names/ >=20 > Section 3: "Note that the prefix functions only as a placeholder for = a=20 > namespace name." (Note "only" is emphasized in the text...) Too bad that other W3C specs have started to use the prefix anyway, and=20 thus XML Infoset also considers it significant. > It's not unreasonable to think that having parsed that data, when=20 > rendering it back out, the placeholder might be relabeled without=20 > negative consequences. Regardless of that assumption, that sentence=20 > makes it pretty clear than using the prefix for any other purposes is=20 > inconsistent with REC-xml-names. And that means that the world of W3C XML specs internally is=20 inconsistent. Yes. I know. Everybody knows. There's nothing I can do=20 about it. The whole discussion started because the draft made the incorrect=20 statement that prefixes do not need to be preserved because they are=20 insignificant. Well, they aren't for certain applications, so this=20 needed to be fixed. >> A property value serialized as #PCDATA (thus as escaped XML) is=20 >> something else than a property value serialized as XML. If you control= =20 >> the format, such as when you define the property in a spec, you sure=20 >> have the freedom to say it's text, instead of XML. But this requires=20 >> that senders and recipients agree on that. But in general, a client=20 >> doesn't have that choice. >=20 > If you define the property, senders and receivers always have to agre= e=20 > to honor your definition. That's not unique here. To me that's an=20 > argument for saying that such definitions SHOULD use #PCDATA. >=20 > Geoff, I'm not following your argument that some clients might not=20 > de-serialize the data. If you have XML there, you have structured=20 > data. Either the client understands the property and does handles it=20 > properly or it doesn't. There are generic clients out there that display *every* property. How=20 are they supposed to know that some text indeed consists of escaped XML? >> Furthermore, putting escaped XML into property values *will* have=20 >> negative effects on generic clients (which will display angle brackets= =20 >> to the user) and some protocol extensions (such as DASL). >=20 > What's a generic client going to show the user for structured XML dat= a=20 > that it doesn't understand? Generic client tends to refer to a tool fo= r=20 > l33t haxx0rz. In general, I'd expect them to only display the text content. >=20 > Perhaps I shouldn't get all bent out of shape over a SHOULD. :-) Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Dec 23 09:33:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epnyg-0000KT-RS for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:33:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18755 for ; Fri, 23 Dec 2005 09:31:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EpnxD-0005rX-3W for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 14:31:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Epnx2-0005pw-3P for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 14:31:20 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by maggie.w3.org with esmtp (Exim 4.50) id 1Epnwx-0006yv-JS for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 14:31:19 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBNEV86n019087 for ; Fri, 23 Dec 2005 09:31:08 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBNEV8cA122302 for ; Fri, 23 Dec 2005 09:31:08 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBNEV8BB023637 for ; Fri, 23 Dec 2005 09:31:08 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBNEV8ZH023629 for ; Fri, 23 Dec 2005 09:31:08 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Fri, 23 Dec 2005 09:31:06 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/23/2005 09:31:07, Serialize complete at 12/23/2005 09:31:07 Content-Type: multipart/alternative; boundary="=_alternative 004FC065852570E0_=" Received-SPF: pass (maggie.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Epnwx-0006yv-JS 7075111728974bf3b5c6175784ac8846 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/OFB8A0E25E.58C1EA20-ON852570E0.004DCAC7-852570E0.004FC10D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11341 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 14:31:31 +0000 This is a multipart message in MIME format. --=_alternative 004FC065852570E0_= Content-Type: text/plain; charset="US-ASCII" Wilfredo wrote on 12/22/2005 09:50:47 PM: > > A property value serialized as #PCDATA (thus as escaped XML) is > > something else than a property value serialized as XML. If you > > control the format, such as when you define the property in a spec, > > you sure have the freedom to say it's text, instead of XML. But > > this requires that senders and recipients agree on that. But in > > general, a client doesn't have that choice. > > If you define the property, senders and receivers always have to > agree to honor your definition. That's not unique here. To me > that's an argument for saying that such definitions SHOULD use #PCDATA. I agree that if the property definer defines the property value as being escaped XML text, then all clients that read that property will know that they have to explicitly apply their XML parser to the property value (after the PROPFIND body has been parsed once by their WebDAV client library), and that all clients that write that property will know that they have to explicitly serialize their XML and wrap it with a #PCDATA wrapper). My point was just that this decision has to be made by the property definer, not by individual clients, so that all property readers and writers know that they have to explicitly do the parsing and unparsing, i.e. you can't have one client deciding it is going to escape the XML to preserve namespaces, and other clients not doing so. But also note that all you've really done is pushed the problem to the client, because now each client has to be sure to use a prefix-preserving parser when they parse the string, and use a prefix-preserving serializer when they serialize the XML for insertion in the #PCDATA. Cheers, Geoff --=_alternative 004FC065852570E0_= Content-Type: text/html; charset="US-ASCII"
Wilfredo wrote on 12/22/2005 09:50:47 PM:
> > A property value serialized as #PCDATA (thus as escaped XML) is  
> > something else than a property value serialized as XML. If you  
> > control the format, such as when you define the property in a spec,  
> > you sure have the freedom to say it's text, instead of XML. But  
> > this requires that senders and recipients agree on that. But in  
> > general, a client doesn't have that choice.
>
>    If you define the property, senders and receivers always have to  
> agree to honor your definition.  That's not unique here.  To me  
> that's an argument for saying that such definitions SHOULD use #PCDATA.
I agree that if the property definer defines the property value as being
escaped XML text, then all clients that read that property will know that
they have to explicitly apply their XML parser to the property value
(after the PROPFIND body has been parsed once by their WebDAV client library),
and that all clients that write that property will know that they have to
explicitly serialize their XML and wrap it with a #PCDATA wrapper).

My point was just that this decision has to be made by the property
definer, not by individual clients, so that all property readers
and writers know that they have to explicitly do the parsing and
unparsing, i.e. you can't have one client deciding it is going to
escape the XML to preserve namespaces, and other clients not doing so.

But also note that all you've really done is pushed the problem to the client,
because now each client has to be sure to use a prefix-preserving parser
when they parse the string, and use a prefix-preserving serializer
when they serialize the XML for insertion in the #PCDATA.  

Cheers,
Geoff



--=_alternative 004FC065852570E0_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 23 09:43:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epo8Y-0002z8-Ni for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:43:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19843 for ; Fri, 23 Dec 2005 09:42:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epo7s-0007qU-46 for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 14:42:32 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Epo7m-0007pJ-NA for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 14:42:27 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Epo7e-0001O4-0b for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 14:42:25 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2DD74142304; Fri, 23 Dec 2005 07:44:43 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-17-275415100 Message-Id: Cc: " webdav" From: Lisa Dusseault Date: Fri, 23 Dec 2005 06:42:01 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Epo7e-0001O4-0b ad142369120295600246364ce4d0faac X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/dbadda157e08386cc71b96d0d97b744e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11342 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 14:42:32 +0000 --Apple-Mail-17-275415100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Wilfredo points out something I hadn't considered before, which I think=20= addresses your concern, Geoff -- the idea that the only agents that=20 need to preserve prefixes are those that want to. - Currently we have no known servers or clients that have a need to=20 preserve prefixes. - If we had a server that decided to implement XPath-based search or=20= something similar, that server could unilaterally begin to preserve=20 prefixes as long as the standard doesn't prevent it. - If we had a client that decided to do something similar on its local=20= cache/copy of data, the client would have to get a prefix-preserving=20 parser and do a bunch of other work too -- but I don't see how the=20 server behavior would entirely prevent this from working. So although I'm OK with saying SHOULD preserve, I see good arguments=20 for saying MAY preserve and I'm fine with that resolution too. Lisa On Dec 23, 2005, at 6:31 AM, Geoffrey M Clemm wrote: > > Wilfredo wrote on 12/22/2005 09:50:47 PM: > > > A property value serialized as #PCDATA (thus as escaped XML) is =A0= > > > something else than a property value serialized as XML. If you =A0 > > > control the format, such as when you define the property in a=20 > spec, =A0 > > > you sure have the freedom to say it's text, instead of XML. But =A0= > > > this requires that senders and recipients agree on that. But in =A0= > > > general, a client doesn't have that choice. > > > > =A0 =A0If you define the property, senders and receivers always = have to=20 > =A0 > > agree to honor your definition. =A0That's not unique here. =A0To me = =A0 > > that's an argument for saying that such definitions SHOULD use=20 > #PCDATA. > > I agree that if the property definer defines the property value as=20 > being > escaped XML text, then all clients that read that property will know=20= > that > they have to explicitly apply their XML parser to the property value > (after the PROPFIND body has been parsed once by their WebDAV client=20= > library), > and that all clients that write that property will know that they have=20= > to > explicitly serialize their XML and wrap it with a #PCDATA wrapper). > > My point was just that this decision has to be made by the property > definer, not by individual clients, so that all property readers > and writers know that they have to explicitly do the parsing and > unparsing, i.e. you can't have one client deciding it is going to > escape the XML to preserve namespaces, and other clients not doing so. > > But also note that all you've really done is pushed the problem to the=20= > client, > because now each client has to be sure to use a prefix-preserving=20 > parser > when they parse the string, and use a prefix-preserving serializer > when they serialize the XML for insertion in the #PCDATA. =A0 > > Cheers, > Geoff > > > --Apple-Mail-17-275415100 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wilfredo points out something I hadn't considered before, which I think addresses your concern, Geoff -- the idea that the only agents that need to preserve prefixes are those that want to. - Currently we have no known servers or clients that have a need to preserve prefixes. - If we had a server that decided to implement XPath-based search or something similar, that server could unilaterally begin to preserve prefixes as long as the standard doesn't prevent it. - If we had a client that decided to do something similar on its local cache/copy of data, the client would have to get a prefix-preserving parser and do a bunch of other work too -- but I don't see how the server behavior would entirely prevent this from working. So although I'm OK with saying SHOULD preserve, I see good arguments for saying MAY preserve and I'm fine with that resolution too. Lisa On Dec 23, 2005, at 6:31 AM, Geoffrey M Clemm wrote: Wilfredo wrote on 12/22/2005 09:50:47 = PM: > > A property value serialized as #PCDATA (thus as escaped XML) is =A0 > > something else than a property value serialized as XML. If you =A0 > > control the format, such as when you define the property in a spec, =A0 > > you sure have the freedom to say it's text, instead of XML. But =A0 > > this requires that senders and recipients agree on that. But in =A0 > > general, a client doesn't have that = choice. > > =A0 =A0If you define the property, senders and receivers always have to =A0 > agree to honor your definition. =A0That's not unique here. =A0To me =A0 > that's an argument for saying that such definitions SHOULD use #PCDATA. I agree that if the property definer defines the property value as being=20 escaped XML text, then all clients that read that property will know that=20 they have to explicitly apply their XML parser to the property value=20 (after the PROPFIND body has been parsed once by their WebDAV client library),=20 and that all clients that write that property will know that they have to=20 explicitly serialize their XML and wrap it with a #PCDATA wrapper).=20 My point was just that this decision has to be made by the property definer, not by individual clients, so that all property readers=20 and writers know that they have to explicitly do the parsing and=20 unparsing, i.e. you can't have one client deciding it is going to=20 escape the XML to preserve namespaces, and other clients not doing so.=20 But also note that all you've really done is pushed the problem to the client,=20 because now each client has to be sure to use a prefix-preserving parser=20 when they parse the string, and use a prefix-preserving serializer=20 when they serialize the XML for insertion in the #PCDATA. =A0=20 Cheers,=20 Geoff=20 = --Apple-Mail-17-275415100-- From w3c-dist-auth-request@frink.w3.org Fri Dec 23 10:35:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epowr-0001zc-Gv for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:35:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25304 for ; Fri, 23 Dec 2005 10:34:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epovm-0003hJ-7g for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 15:34:06 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Epovb-0003gG-9I for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 15:33:55 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by lisa.w3.org with esmtp (Exim 4.50) id 1EpovW-0002Yj-Uk for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 15:33:55 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBNFXnax015736 for ; Fri, 23 Dec 2005 10:33:49 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBNFXnPu116774 for ; Fri, 23 Dec 2005 10:33:49 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBNFXmVY017158 for ; Fri, 23 Dec 2005 10:33:48 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBNFXm6S017152 for ; Fri, 23 Dec 2005 10:33:48 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Fri, 23 Dec 2005 10:33:46 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/23/2005 10:33:48, Serialize complete at 12/23/2005 10:33:48 Content-Type: multipart/alternative; boundary="=_alternative 00557D69852570E0_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EpovW-0002Yj-Uk 5c1f3e79f7963b4b107569041ece2a68 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/OF22561396.8311FF0A-ON852570E0.0051983D-852570E0.00557DAD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11343 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 15:34:06 +0000 This is a multipart message in MIME format. --=_alternative 00557D69852570E0_= Content-Type: text/plain; charset="US-ASCII" Lisa wrote on 12/23/2005 09:42:01 AM: > Wilfredo points out something I hadn't considered before, which I think > addresses your concern, Geoff -- the idea that the only agents that > need to preserve prefixes are those that want to. My point below was that this is precisely what an agent cannot do (if by "agent", you mean an individual client). One agent cannot decide to preserve prefixes by escaping the XML for a given property value, unless *all* agents have agreed to do so (i.e., unless that property by definition always holds escaped XML text). So at a minimum, you can never use this approach for an existing property, because none of the existing clients will be escaping the property value on write or unescaping the property value on read. > - Currently we have no known servers or clients that have a need to > preserve prefixes. I'm not sure who "we" refers to here, but minimally it doesn't include us (:-), because we will store XML schema and XSLT data in property values, which do require that namespace tags be preserved. I doubt we're the only ones that will do so. > - If we had a server that decided to implement XPath-based search or > something similar, that server could unilaterally begin to preserve > prefixes as long as the standard doesn't prevent it. Alternatively, a server could unilaterally decide to not preserve prefixes, since the standard doesn't require it (i.e., it is not a MUST). > - If we had a client that decided to do something similar on its local > cache/copy of data, the client would have to get a prefix-preserving > parser and do a bunch of other work too -- but I don't see how the > server behavior would entirely prevent this from working. What prevents this from working (well) is that it could do so only if all other clients that read or wrote this property did so as well. This approach is likely to be a source of subtle interoperability problems. > So although I'm OK with saying SHOULD preserve, I see good arguments > for saying MAY preserve and I'm fine with that resolution too. I very rarely care about the distinction between SHOULD vs. MAY, and this is not one of those rare times (:-). Cheers, Geoff --=_alternative 00557D69852570E0_= Content-Type: text/html; charset="US-ASCII"
Lisa wrote on 12/23/2005 09:42:01 AM:

> Wilfredo points out something I hadn't considered before, which I think
> addresses your concern, Geoff -- the idea that the only agents that
> need to preserve prefixes are those that want to.

My point below was that this is precisely what an agent cannot do
(if by "agent", you mean an individual client).  One agent cannot
decide to preserve prefixes by escaping the XML for a given
property value, unless *all* agents have agreed to do so (i.e.,
unless that property by definition always holds escaped XML text).

So at a minimum, you can never use this approach for an existing
property, because none of the existing clients will be escaping the
property value on write or unescaping the property value on read.

>   - Currently we have no known servers or clients that have a need to
> preserve prefixes.

I'm not sure who "we" refers to here, but minimally it doesn't include
us (:-), because we will store XML schema and XSLT data in property values,
which do require that namespace tags be preserved.  I doubt we're the
only ones that will do so.

>   - If we had a server that decided to implement XPath-based search or
> something similar, that server could unilaterally begin to preserve
> prefixes as long as the standard doesn't prevent it.

Alternatively, a server could unilaterally decide to not
preserve prefixes, since the standard doesn't require it (i.e., it is
not a MUST).

>   - If we had a client that decided to do something similar on its local
> cache/copy of data, the client would have to get a prefix-preserving
> parser and do a bunch of other work too -- but I don't see how the
> server behavior would entirely prevent this from working.
What prevents this from working (well) is that it could do so only if all
other clients that read or wrote this property did so as well.
This approach is likely to be a source of subtle interoperability problems.

> So although I'm OK with saying SHOULD preserve, I see good arguments
> for saying MAY preserve and I'm fine with that resolution too.

I very rarely care about the distinction between SHOULD vs. MAY,
and this is not one of those rare times (:-).

Cheers,
Geoff
--=_alternative 00557D69852570E0_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 23 10:49:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EppAX-0006Tj-53 for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:49:23 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27315 for ; Fri, 23 Dec 2005 10:48:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epp9m-0006VR-GY for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 15:48:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Epp9g-0006Uh-Or for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 15:48:28 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Epp9a-0001c5-B0 for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 15:48:28 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1C13314230A; Fri, 23 Dec 2005 08:50:53 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-18-279388743 Message-Id: <0430bf741dbe181bfe28743232a13d4e@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Fri, 23 Dec 2005 07:48:14 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1Epp9a-0001c5-B0 9d236b3836efa14b607fdf756a9ec57e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/0430bf741dbe181bfe28743232a13d4e@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11344 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 15:48:34 +0000 --Apple-Mail-18-279388743 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Dec 23, 2005, at 7:33 AM, Geoffrey M Clemm wrote: > > Lisa wrote on 12/23/2005 09:42:01 AM: > > > Wilfredo points out something I hadn't considered before, which I=20= > think > > addresses your concern, Geoff -- the idea that the only agents that > > need to preserve prefixes are those that want to. > > My point below was that this is precisely what an agent cannot do > (if by "agent", you mean an individual client). =A0One agent cannot > decide to preserve prefixes by escaping the XML for a given > property value, unless *all* agents have agreed to do so (i.e., > unless that property by definition always holds escaped XML text). That's true, but it's not quite what I was saying. > > =A0 - Currently we have no known servers or clients that have a need = to > > preserve prefixes. > > I'm not sure who "we" refers to here, but minimally it doesn't include > us (:-), because we will store XML schema and XSLT data in property=20 > values, > which do require that namespace tags be preserved. =A0I doubt we're = the > only ones that will do so. I didn't know about this or missed it. :) Good info. > > =A0 - If we had a client that decided to do something similar on = its=20 > local > > cache/copy of data, the client would have to get a = prefix-preserving > > parser and do a bunch of other work too -- but I don't see how the > > server behavior would entirely prevent this from working. > > What prevents this from working (well) is that it could do so only if=20= > all > other clients that read or wrote this property did so as well. > This approach is likely to be a source of subtle interoperability=20 > problems. Let's say that 1. client X wants to use prefixes and store XML schema and XSLT data=20= in property values. 2. client Y expects that value to be in ordinary XML, not=20 encapsulated. 3. server S does not preserve prefixes. I'm trying to understand here, how does the behavior of Y and S prevent=20= X from doing what it wants to do? Can't client X still store that=20 information or at least reconstruct it, if it wants to use prefixes in=20= local computations? It might be messy, but it ought to be possible to=20= preserve the original mappings somewhere the server won't mess with it=20= (e.g. add an attribute 'originalmapping:x=3D"http://example.com/ns"'). =20= Knowing how existing servers tend not to preserve prefixes anyway, I'd=20= imagine this is what client X would have to do regardless, in order to=20= work. But there could well be something I'm missing here so I'm happy to be=20 educated. Thanks, Lisa --Apple-Mail-18-279388743 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Dec 23, 2005, at 7:33 AM, Geoffrey M Clemm wrote: Lisa wrote on 12/23/2005 09:42:01 = AM: > Wilfredo points out something I hadn't considered before, which I think > addresses your concern, Geoff -- the idea that the only agents that > need to preserve prefixes are those that want to.=20 My point below was that this is precisely what an agent cannot do=20 (if by "agent", you mean an individual client). =A0One agent cannot=20 decide to preserve prefixes by escaping the XML for a given=20 property value, unless *all* agents have agreed to do so (i.e.,=20 unless that property by definition always holds escaped XML text).=20 That's true, but it's not quite what I was saying. > =A0 - Currently we have no known servers or clients that have a need to > preserve prefixes.=20 I'm not sure who "we" refers to here, but minimally it doesn't include=20 us (:-), because we will store XML schema and XSLT data in property values,=20 which do require that namespace tags be preserved. =A0I doubt we're the=20 only ones that will do so.=20 I didn't know about this or missed it. :) Good info. > =A0 - If we had a client that decided to do something similar on its local > cache/copy of data, the client would have to get a prefix-preserving > parser and do a bunch of other work too -- but I don't see how the > server behavior would entirely prevent this from working. What prevents this from working (well) is that it could do so only if all=20 other clients that read or wrote this property did so as well. This approach is likely to be a source of subtle interoperability problems.=20 Let's say that 1. client X wants to use prefixes and store XML schema and XSLT data in property values.=20 2. client Y expects that value to be in ordinary XML, not encapsulated. =20 3. server S does not preserve prefixes. =20 I'm trying to understand here, how does the behavior of Y and S prevent X from doing what it wants to do? Can't client X still store that information or at least reconstruct it, if it wants to use prefixes in local computations? It might be messy, but it ought to be possible to preserve the original mappings somewhere the server won't mess with it (e.g. add an attribute 'originalmapping:x=3D"http://example.com/ns"'). Knowing how existing servers tend not to preserve prefixes anyway, I'd imagine this is what client X would have to do regardless, in order to work. =20 But there could well be something I'm missing here so I'm happy to be educated. Thanks, Lisa --Apple-Mail-18-279388743-- From w3c-dist-auth-request@frink.w3.org Fri Dec 23 11:17:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EppbH-0005Aj-0D for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 11:17:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01479 for ; Fri, 23 Dec 2005 11:15:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eppaa-0003xr-Fp for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 16:16:16 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EppaO-0003x5-Sl for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 16:16:05 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by aji.w3.org with esmtp (Exim 4.50) id 1EppaI-0008AW-S1 for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 16:16:03 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBNGFo3e003312 for ; Fri, 23 Dec 2005 11:15:50 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBNGFocA123206 for ; Fri, 23 Dec 2005 11:15:50 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBNGFeot025140 for ; Fri, 23 Dec 2005 11:15:40 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBNGFexQ024575 for ; Fri, 23 Dec 2005 11:15:40 -0500 In-Reply-To: <0430bf741dbe181bfe28743232a13d4e@osafoundation.org> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Fri, 23 Dec 2005 11:15:28 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/23/2005 11:15:39, Serialize complete at 12/23/2005 11:15:39 Content-Type: multipart/alternative; boundary="=_alternative 00594E7F852570E0_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1EppaI-0008AW-S1 5d57b6557329db755e6009554088d857 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/OFE2AE4746.47A3D4C1-ON852570E0.00572792-852570E0.00594EE1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11345 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 16:16:16 +0000 This is a multipart message in MIME format. --=_alternative 00594E7F852570E0_= Content-Type: text/plain; charset="US-ASCII" Lisa wrote on 12/23/2005 10:48:14 AM: > Let's say that > 1. client X wants to use prefixes and store XML schema and XSLT data > in property values. > 2. client Y expects that value to be in ordinary XML, not > encapsulated. > 3. server S does not preserve prefixes. > > I'm trying to understand here, how does the behavior of Y and S prevent > X from doing what it wants to do? Can't client X still store that > information or at least reconstruct it, if it wants to use prefixes in > local computations? It might be messy, but it ought to be possible to > preserve the original mappings somewhere the server won't mess with it > (e.g. add an attribute 'originalmapping:x="http://example.com/ns"'). > Knowing how existing servers tend not to preserve prefixes anyway, I'd > imagine this is what client X would have to do regardless, in order to > work. There might be something that client X could do, but the proposal we were discussing was simply escaping the XML as a string via #PCDATA. That proposal would cause client Y to break. We could discuss an alternative proposal such as the one you describe above, but a user of client Y would still get back broken XSLT or broken XML-schema data, because client Y doesn't know how to use the originalmapping information to fix it up. Also, this approach is likely to be a lot of work for the client, so it isn't a "simple" approach(which was what the #PCDATA approach was trying to achieve). So I have not yet heard a "good" alternative to solving this problem other than recommending that servers preserve namespace mappings. Cheers, Geoff --=_alternative 00594E7F852570E0_= Content-Type: text/html; charset="US-ASCII"
Lisa wrote on 12/23/2005 10:48:14 AM:

> Let's say that
>    1.  client X wants to use prefixes and store XML schema and XSLT data
> in property values.
>    2.  client Y expects that value to be in ordinary XML, not
> encapsulated.
>    3.  server S does not preserve prefixes.
>
> I'm trying to understand here, how does the behavior of Y and S prevent
> X from doing what it wants to do?  Can't client X still store that
> information or at least reconstruct it, if it wants to use prefixes in
> local computations?  It might be messy, but it ought to be possible to
> preserve the original mappings somewhere the server won't mess with it
> (e.g. add an attribute 'originalmapping:x="http://example.com/ns"').  
> Knowing how existing servers tend not to preserve prefixes anyway, I'd
> imagine this is what client X would have to do regardless, in order to
> work.
There might be something that client X could do, but the proposal we
were discussing was simply escaping the XML as a string via #PCDATA.
That proposal would cause client Y to break.

We could discuss an alternative proposal such as the one you describe
above, but a user of client Y would still get back broken XSLT or
broken XML-schema data, because client Y doesn't know how to use the
originalmapping information to fix it up.  Also, this approach is
likely to be a lot of work for the client, so it isn't a "simple"
approach(which was what the #PCDATA approach was trying to achieve).

So I have not yet heard a "good" alternative to solving this problem
other than recommending that servers preserve namespace mappings.

Cheers,
Geoff




--=_alternative 00594E7F852570E0_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 23 13:44:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpruB-00075I-Nx for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 13:44:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20460 for ; Fri, 23 Dec 2005 13:43:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EprsN-0003Wp-9i for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 18:42:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EprsA-0003Vz-IC for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 18:42:34 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eprs7-0000wq-5o for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 18:42:34 +0000 Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jBNIgR91008760; Fri, 23 Dec 2005 10:42:27 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 919EA3B2; Fri, 23 Dec 2005 10:42:27 -0800 (PST) In-Reply-To: <43ABC404.3030409@gmx.de> References: <43AAF401.3080507@gmx.de> <43ABC404.3030409@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <049DB755-83ED-4DE5-A724-653AB235B018@wsanchez.net> Cc: webdav WG Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Fri, 23 Dec 2005 10:42:26 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: none (lisa.w3.org: domain of wsanchez@wsanchez.net does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Eprs7-0000wq-5o b6084104fed4dbe6099406a2861a79a3 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/049DB755-83ED-4DE5-A724-653AB235B018@wsanchez.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11346 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 18:42:47 +0000 Content-Transfer-Encoding: 7bit On Dec 23, 2005, at 1:31 AM, Julian Reschke wrote: > So you'd be happy would be "SHOULD" be a "MAY"? Yes, absolutely. (The rest of this is banter...) >> Additionally: >> http://www.w3.org/TR/REC-xml-names/ >> Section 3: "Note that the prefix functions only as a placeholder >> for a namespace name." (Note "only" is emphasized in the text...) > > Too bad that other W3C specs have started to use the prefix anyway, > and thus XML Infoset also considers it significant. Yeah, now that I've been forced to learn something about it, I hate XML. Can you tell? I should have challenged Tim Bray to a fist fight last week when I had the chance, but he's bigger than I am. The whole point of XML is that I shouldn't have to think about it, which is why I'm advocating against requirements that make me think really hard about it. The serializer in PyXML decides where to park namespace definitions and what prefixes to use or not use. I don't want to tweak the serializer, write my own, or find another library. If those are necessary, there's a spec problem, and in this case the spec problem would be in WebDAV. Sounds like there needs to be a serialization spec for XML as you suggest, then PyXML would want to conform to that, and ideally, that spec would address this namespace mess. Like the ETag on PUT issue, I think it needs to be addressed upstream, instead of in DAV. >> If you define the property, senders and receivers always have to >> agree to honor your definition. That's not unique here. To me >> that's an argument for saying that such definitions SHOULD use >> #PCDATA. >> Geoff, I'm not following your argument that some clients might >> not de-serialize the data. If you have XML there, you have >> structured data. Either the client understands the property and >> does handles it properly or it doesn't. > > There are generic clients out there that display *every* property. > How are they supposed to know that some text indeed consists of > escaped XML? Or XML? Or binhex goo? I dunno, which is why generic clients are of limited usefulness. They are developer tools, not user tools. >>> Furthermore, putting escaped XML into property values *will* have >>> negative effects on generic clients (which will display angle >>> brackets to the user) and some protocol extensions (such as DASL). >> What's a generic client going to show the user for structured >> XML data that it doesn't understand? Generic client tends to >> refer to a tool for l33t haxx0rz. > > In general, I'd expect them to only display the text content. The XML, you mean? If not, what's the text content of ""? Only an engineer would think that a generic client is an acceptable UI for browsing structured data, even if it is XML "text". Lisa and some others in CalDAV think it's useful to have meaningful resource names in CalDAV because then you can browse it with Firefox or mount it in Finder, as if my Mom wants to crack open an iCalendar resource and read it for fun. That's OK for developers, but it's _really_ bad UI. Never mind localization issues and the like. If you are engineering for usability, generic clients aren't of any value. My point being that for the audience which can actually use generic clients, showing angle brackets is fine. Making compromises in the same of such "usability" is a mistake, I think. You are trading off knowing for sure, no doubt, your data won't be manipulated by the server for not having angle brackets in generic clients. Not a great trade-off in my book. -wsv From w3c-dist-auth-request@frink.w3.org Fri Dec 23 14:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epsyf-0000JU-Od for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 14:53:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28205 for ; Fri, 23 Dec 2005 14:52:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Epswk-0008N4-Nk for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 19:51:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EpswX-0008Le-59 for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 19:51:09 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by lisa.w3.org with esmtp (Exim 4.50) id 1EpswS-00059C-DU for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 19:51:09 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jBNJouEU010995; Fri, 23 Dec 2005 11:50:56 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id 8C47D21; Fri, 23 Dec 2005 11:50:56 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FAFD269-5B6E-464D-BE0B-10C2343394AE@apple.com> Cc: " webdav" Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Fri, 23 Dec 2005 11:50:55 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== Received-SPF: pass (lisa.w3.org: domain of wsanchez@apple.com designates 17.254.13.22 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1EpswS-00059C-DU def1ec2a1b68b742191b3f1237ace7ea X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/3FAFD269-5B6E-464D-BE0B-10C2343394AE@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11347 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 19:51:22 +0000 Content-Transfer-Encoding: 7bit On Dec 23, 2005, at 7:33 AM, Geoffrey M Clemm wrote: > Lisa wrote on 12/23/2005 09:42:01 AM: > > > Wilfredo points out something I hadn't considered before, which I > think > > addresses your concern, Geoff -- the idea that the only agents that > > need to preserve prefixes are those that want to. > > My point below was that this is precisely what an agent cannot do > (if by "agent", you mean an individual client). One agent cannot > decide to preserve prefixes by escaping the XML for a given > property value, unless *all* agents have agreed to do so (i.e., > unless that property by definition always holds escaped XML text). > > So at a minimum, you can never use this approach for an existing > property, because none of the existing clients will be escaping the > property value on write or unescaping the property value on read. Correct, but the existing spec (which is what applies to existing properties) doesn't require prefixes to be preserved. You can't fix that with a spec change after the fact. > > - Currently we have no known servers or clients that have a > need to > > preserve prefixes. > > I'm not sure who "we" refers to here, but minimally it doesn't include > us (:-), because we will store XML schema and XSLT data in property > values, > which do require that namespace tags be preserved. I doubt we're the > only ones that will do so. Right. So your options are: 1- define properties that escape the XML. 2- use a server that preserves the prefixes. I assume that you do #2 today, and that the lack of a requirement in the spec didn't prevent that. Yes, that means you won't like my DAV server because I'm not catering to your (what, to me, are eccentric) needs. I do not wish to be required to do so, and I'm willing to lose you as a possible client as a result of my lack of that feature. I agree that if you want this to work reliably across more DAV servers, something has to change. I don't think that the server spec is what should change; I think the property specs should change, which has the advantage of working in the current WebDAV framework. I recognize that this isn't trivial for existing services, and in those cases, you can keep doing #2 and use a server that fits the bill. > > - If we had a server that decided to implement XPath-based > search or > > something similar, that server could unilaterally begin to preserve > > prefixes as long as the standard doesn't prevent it. > > Alternatively, a server could unilaterally decide to not > preserve prefixes, since the standard doesn't require it (i.e., it is > not a MUST). Correct. And twisted.web2, at present, doesn't guarantee this, nor does mod_dav. > > - If we had a client that decided to do something similar on > its local > > cache/copy of data, the client would have to get a prefix-preserving > > parser and do a bunch of other work too -- but I don't see how the > > server behavior would entirely prevent this from working. > > What prevents this from working (well) is that it could do so only > if all > other clients that read or wrote this property did so as well. > This approach is likely to be a source of subtle interoperability > problems. You just told me that prefix-preserving parsers are easy to find, as if it was a non-issue. If you are storing data that required prefixes to be preserved in a property, of course clients that edit that data has to play nice. I'm not sure how even a server that guarantees the behavior you want can save you there. It's going to have to preserve what the client sent, and if the client edits your prefixes, you're still SOL. On the other hand, if the data is escaped, and the client doesn't know that the property is escaped XML, it seems _less_ likely that if it did decide to write that data back out to the server that it will munge it before doing so. > > So although I'm OK with saying SHOULD preserve, I see good arguments > > for saying MAY preserve and I'm fine with that resolution too. > > I very rarely care about the distinction between SHOULD vs. MAY, > and this is not one of those rare times (:-). Ditto. :-) -wsv From w3c-dist-auth-request@frink.w3.org Fri Dec 23 15:51:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eptt1-0006pT-7M for webdav-archive@megatron.ietf.org; Fri, 23 Dec 2005 15:51:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05381 for ; Fri, 23 Dec 2005 15:50:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eptrn-0003Mh-Ez for w3c-dist-auth-dist@listhub.w3.org; Fri, 23 Dec 2005 20:50:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eptrb-0003Li-La for w3c-dist-auth@listhub.w3.org; Fri, 23 Dec 2005 20:50:07 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.50) id 1EptrZ-0004Xp-3W for w3c-dist-auth@w3.org; Fri, 23 Dec 2005 20:50:07 +0000 Received: from [192.168.2.101] (dsl081-070-219.sfo1.dsl.speakeasy.net [64.81.70.219]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id jBNKo2DV004202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Dec 2005 12:50:03 -0800 (PST) Message-ID: <43AC6306.70106@cse.ucsc.edu> Date: Fri, 23 Dec 2005 12:50:14 -0800 From: Elias Sinderson Reply-To: webdav User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (lisa.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1EptrZ-0004Xp-3W 59ebce560c97b98dfd667366fe1aa8bb X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/43AC6306.70106@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11348 X-Loop: w3c-dist-auth@w3.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, 23 Dec 2005 20:50:19 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > [...] I have not yet heard a "good" alternative to solving this > problem other than recommending that servers preserve namespace mappings. The above captures my take on the issue as well, and there seems to be rough consensus around this recommendation. AFAICT, the only thing remaining to be decided is whether the spec says SHOULD or MAY -- My vote is for SHOULD, because it will be more beneficial to clients if more servers tend to implement this feature in the long run. It is my opinion that a MAY level requirement in this situation will lead to more special casing for client writers (i.e. 'am I talking to a server of type A or a server of type B?') and, hence, interoperability issues. Geoff supports the requirement but is indifferent wrt SHOULD vs. MAY. Lisa is OK with SHOULD, but would be fine with MAY. Jim is fine with SHOULD. Wilfredo also seems to be okay with SHOULD, as it still leaves some wiggle room for server implementers. Given the above I'll move to declare rough consensus on this issue and for the inclusion of the latest proposed text in the next draft. Cheers, Elias From earl@greekcity.com Sat Dec 24 01:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eq3G1-00050P-Rd for webdav-archive@megatron.ietf.org; Sat, 24 Dec 2005 01:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09912 for ; Sat, 24 Dec 2005 01:50:50 -0500 (EST) Received: from [83.143.149.5] (helo=-1271245664) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eq3JA-00034P-Qh for webdav-archive@ietf.org; Sat, 24 Dec 2005 01:55:14 -0500 Received: from greekcity.com (-1271709712 [-1271303792]) by goldxproducts.com (Qmailv1) with ESMTP id C70B375AF8 for ; Sat, 24 Dec 2005 14:26:34 -0500 Date: Sat, 24 Dec 2005 14:26:34 -0500 From: Doctor X-Mailer: The Bat! (v2.00.8) Personal X-Priority: 3 Message-ID: <7121137848.20051224142634@greekcity.com> To: Webdav Subject: The Ultimate Online Pharmaceutical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1C2727F7D6833A7" X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6 X-Spam-Score: 3.1 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------------1C2727F7D6833A7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Vlvagra $3.3 Leevitra $3.3 Citalis $3.7 Imittrex $16.4 Flolmax $2.2 Ultqram $0.78 Vitoxx $4.75 Amqbien $2.2 Valiium $0.97 Xaynax $1.09 Somua $3 Mermidia $2.2 visit our website http://neforemer.com/?YLRYEXRldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ___ Best regards, Online Pharmaceuticals etuuimfdsgj RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------1C2727F7D6833A7 Content-Type: text/html Content-Transfer-Encoding: 7bit Vltagra - $3.3
Lenvitra - $3.3
Cidalis - $3.7
Imiotrex - $16.4
Floymax - $2.2
Ultgram - $0.78
Viuoxx - $4.75
Amwbien - $2.2
Valiaum - $0.97
Xaunax - $1.09
Somta - $3
Mernidia - $2.2


visit our website


Best regards,
Online Pharmaceuticals

etuuimfdsgj RldRUFRHH1JGVllbRVF1WFdHUhteQFQ= ------------1C2727F7D6833A7-- From w3c-dist-auth-request@frink.w3.org Sat Dec 24 12:12:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqCwc-0003zp-Ae for webdav-archive@megatron.ietf.org; Sat, 24 Dec 2005 12:12:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07409 for ; Sat, 24 Dec 2005 12:11:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EqCuU-00011R-H6 for w3c-dist-auth-dist@listhub.w3.org; Sat, 24 Dec 2005 17:10:22 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EqCuG-00010W-DD for w3c-dist-auth@listhub.w3.org; Sat, 24 Dec 2005 17:10:08 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EqCu5-0004xf-F4 for w3c-dist-auth@w3.org; Sat, 24 Dec 2005 17:10:07 +0000 Received: (qmail invoked by alias); 24 Dec 2005 17:09:55 -0000 Received: from brmn-d9b8fc1b.pool.mediaWays.net (EHLO [217.184.252.27]) [217.184.252.27] by mail.gmx.net (mp001) with SMTP; 24 Dec 2005 18:09:55 +0100 X-Authenticated: #1915285 Message-ID: <43AD8074.40507@gmx.de> Date: Sat, 24 Dec 2005 18:08:04 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: webdav WG References: <43AAF401.3080507@gmx.de> <43ABC404.3030409@gmx.de> <049DB755-83ED-4DE5-A724-653AB235B018@wsanchez.net> In-Reply-To: <049DB755-83ED-4DE5-A724-653AB235B018@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EqCu5-0004xf-F4 34b44113e0da51c649234c0441790bf9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Status of Bugzilla Bug 10, Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/43AD8074.40507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11349 X-Loop: w3c-dist-auth@w3.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, 24 Dec 2005 17:10:22 +0000 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA07409 Wilfredo S=E1nchez Vega wrote: > --- >> In general, I'd expect them to only display the text content. >=20 > The XML, you mean? If not, what's the text content of=20 > ""? The empty string. > Only an engineer would think that a generic client is an acceptable U= I=20 > for browsing structured data, even if it is XML "text". >=20 > Lisa and some others in CalDAV think it's useful to have meaningful=20 > resource names in CalDAV because then you can browse it with Firefox or= =20 > mount it in Finder, as if my Mom wants to crack open an iCalendar=20 > resource and read it for fun. That's OK for developers, but it's=20 > _really_ bad UI. Never mind localization issues and the like. It may be bad UI, but that doesn't change the fact that meaningful=20 (stable) URLs are a good thing... > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:06:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErL5I-00089L-O5 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:06:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08423 for ; Tue, 27 Dec 2005 15:05:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErL4C-00008O-EY for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:05:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErL4A-0008RA-9F for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:05:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErL48-0002Yt-2j for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:05:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRK4woP010572; Tue, 27 Dec 2005 12:04:58 -0800 Date: Tue, 27 Dec 2005 12:04:58 -0800 Message-Id: <200512272004.jBRK4woP010572@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErL48-0002Yt-2j b14871e97a7ec95b75578c69557646be X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512272004.jBRK4woP010572@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11351 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:05:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |elias@cse.ucsc.edu ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:04 ------- I sent my mail to the list -- reassigning bug to Elias for call discussion and hopefully a decision. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:06:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErL5J-00089X-1Q for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:06:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08424 for ; Tue, 27 Dec 2005 15:05:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErL3N-000849-Vw for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:04:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErL39-00082M-KK for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:03:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErL36-0002EH-Ob for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:03:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRK3reU010552; Tue, 27 Dec 2005 12:03:53 -0800 Date: Tue, 27 Dec 2005 12:03:53 -0800 Message-Id: <200512272003.jBRK3reU010552@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErL36-0002EH-Ob 0ed9582758f545c60090cedcea21a4c8 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 52] "mandatory" properties X-Archived-At: http://www.w3.org/mid/200512272003.jBRK3reU010552@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11350 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:04:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=52 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:03 ------- As Jim comments, this was fixed (or an attempt was made) in the draft. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:07:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErL6g-0008MX-9j for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:07:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08655 for ; Tue, 27 Dec 2005 15:06:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErL67-0000RP-Nu for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:07:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErL64-0000Q6-7s for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:07:00 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErL5w-00039L-2i for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:06:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRK6pvF010590; Tue, 27 Dec 2005 12:06:51 -0800 Date: Tue, 27 Dec 2005 12:06:51 -0800 Message-Id: <200512272006.jBRK6pvF010590@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErL5w-00039L-2i 8c14f4a94e545dfdb44d9a7af5cf21bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 62] href format X-Archived-At: http://www.w3.org/mid/200512272006.jBRK6pvF010590@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11352 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:07:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=62 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:06 ------- Fixed. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:36:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErLYI-0004GM-0q for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:36:10 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12219 for ; Tue, 27 Dec 2005 15:35:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErLXY-00079c-Ak for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:35:24 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErLXQ-00078S-U6 for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:35:17 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErLXC-0000Od-1G for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:35:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRKYwfm010618; Tue, 27 Dec 2005 12:34:58 -0800 Date: Tue, 27 Dec 2005 12:34:58 -0800 Message-Id: <200512272034.jBRKYwfm010618@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErLXC-0000Od-1G 35656bc84fccd2036dae0a254a8b52ba X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512272034.jBRKYwfm010618@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11353 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:35:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:34 ------- If I recall correctly, this paragraph was removed as a result of this thread on the discussion list: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0089.html Jason Crawford, Geoff, Elias, Stefan Eissing and myself were all in favour of the change (proposed by Jason) and there was no dissent at the time. I considered this consensus and thus changed the document. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:37:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErLZH-0004Pb-R2 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:37:11 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12307 for ; Tue, 27 Dec 2005 15:36:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErLYh-0007N5-GG for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:36:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErLYc-0007Lh-Nf for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:36:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErLYa-0003t9-3U for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:36:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRKaQhm010634; Tue, 27 Dec 2005 12:36:26 -0800 Date: Tue, 27 Dec 2005 12:36:26 -0800 Message-Id: <200512272036.jBRKaQhm010634@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErLYa-0003t9-3U 4b4ba7e187a3ba788a2f20a73cb84f01 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 113] IMPLIED_LWS X-Archived-At: http://www.w3.org/mid/200512272036.jBRKaQhm010634@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11354 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:36:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=113 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:36 ------- Fixed - no LWS allowed in State-Token. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 15:58:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErLtW-0007XC-7Q for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 15:58:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15311 for ; Tue, 27 Dec 2005 15:56:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErLsn-000372-Ha for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 20:57:21 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErLsi-00036R-M1 for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 20:57:16 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErLse-0007q8-5g for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 20:57:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRKvBE3010671; Tue, 27 Dec 2005 12:57:11 -0800 Date: Tue, 27 Dec 2005 12:57:11 -0800 Message-Id: <200512272057.jBRKvBE3010671@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErLse-0007q8-5g 5e202c0d3a8420cd5608210137163322 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512272057.jBRKvBE3010671@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11355 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 20:57:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 12:57 ------- Proposed language: "In the presence of multiple bindings, this property SHOULD have a consistent value independent of binding. This implies that a calculated value for this property, consisting of the last segment of the resource path, is NOT RECOMMENDED." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErM1e-0000Yx-88 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:06:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16363 for ; Tue, 27 Dec 2005 16:05:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErM0b-0005fZ-49 for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:05:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErM0Y-0005e7-6S for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:05:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErM0Q-0004Vm-Fq for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:05:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRL5Dj4010720; Tue, 27 Dec 2005 13:05:13 -0800 Date: Tue, 27 Dec 2005 13:05:13 -0800 Message-Id: <200512272105.jBRL5Dj4010720@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErM0Q-0004Vm-Fq 8173a949dd567c962f4cf81148564a7d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 143] LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER X-Archived-At: http://www.w3.org/mid/200512272105.jBRL5Dj4010720@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11356 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:05:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:05 ------- Ok, added ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:15:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMA9-00021n-9D for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:15:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17433 for ; Tue, 27 Dec 2005 16:14:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErM9c-0006wt-1k for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:14:44 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErM9Q-0006qh-TM for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:14:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErM9N-0004tt-9v for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:14:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLESmZ010789; Tue, 27 Dec 2005 13:14:28 -0800 Date: Tue, 27 Dec 2005 13:14:28 -0800 Message-Id: <200512272114.jBRLESmZ010789@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErM9N-0004tt-9v d9609afe85a88eef65aed8235d98ff19 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512272114.jBRLESmZ010789@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11359 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:14:44 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 Bug 18 depends on bug 144, which changed state. Bug 144 Summary: IF_HEADER_CHECKS_AFTER_OTHER_CHECKS http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:15:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMA2-00020l-2f for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:15:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17421 for ; Tue, 27 Dec 2005 16:14:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErM9U-0006rw-3o for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:14:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErM9Q-0006qg-L0 for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:14:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErM9M-0004tA-F3 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:14:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLERbH010775; Tue, 27 Dec 2005 13:14:27 -0800 Date: Tue, 27 Dec 2005 13:14:27 -0800 Message-Id: <200512272114.jBRLERbH010775@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErM9M-0004tA-F3 b7ebe71c8a9c83491676d063a3b9f554 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS X-Archived-At: http://www.w3.org/mid/200512272114.jBRLERbH010775@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11358 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:14:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:14 ------- Fixed with similar text in HTTP header usage section, as well as "if" and "overwrite" sections. "The server MUST do authorization checks before checking this or any conditional header. " ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:14:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErM9i-0001u0-H3 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:14:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17335 for ; Tue, 27 Dec 2005 16:13:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErM91-0006kz-WA for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:14:08 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErM8z-0006kJ-II for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:14:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErM8q-0004hq-M2 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:14:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLDpL9010753; Tue, 27 Dec 2005 13:13:51 -0800 Date: Tue, 27 Dec 2005 13:13:51 -0800 Message-Id: <200512272113.jBRLDpL9010753@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErM8q-0004hq-M2 15757b84440fa62bbde2ce66ff6b33b4 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512272113.jBRLDpL9010753@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11357 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:14:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-27 13:13 ------- I think the proposed wording is problematic: - it makes the case where a resource has multiple bindings special (the first SHOULD only applies to this case, and I wonder why) - the second statement is redundant, if the property SHOULD have the same value independant of Request-URI, then the rest follows anyway (so if people feel this needs special mention, then just make it non-normative comment) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMC4-0002RK-8r for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:17:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17655 for ; Tue, 27 Dec 2005 16:16:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMBW-000095-1G for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:16:42 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMBR-00008I-Hm for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:16:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErMBJ-0005XE-U9 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:16:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLGTev010806; Tue, 27 Dec 2005 13:16:29 -0800 Date: Tue, 27 Dec 2005 13:16:29 -0800 Message-Id: <200512272116.jBRLGTev010806@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErMBJ-0005XE-U9 9aa4dbfa76ce404e57636a1f48c44dfc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512272116.jBRLGTev010806@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11360 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:16:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-27 13:16 ------- I agree with both the original consensus, and the text change. As this is a change to normative text and affects what's on-the-wire, this really needs to be mentioned explicitly in the Changes section, though. Reopening as a reminder to do that. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:34:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMT7-0005Pw-LT for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:34:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20269 for ; Tue, 27 Dec 2005 16:33:44 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMSM-0003uK-3a for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:34:06 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMSH-0003t7-5V for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:34:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMSE-0001Ka-1b for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:34:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLXtKA010832; Tue, 27 Dec 2005 13:33:55 -0800 Date: Tue, 27 Dec 2005 13:33:55 -0800 Message-Id: <200512272133.jBRLXtKA010832@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMSE-0001Ka-1b 2d4a17d625d6559ea55e93dc4fa87c8c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200512272133.jBRLXtKA010832@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11361 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:34:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:33 ------- Reverted If definition. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:34:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMTA-0005RS-NS for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:34:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20281 for ; Tue, 27 Dec 2005 16:33:47 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMSU-0003wG-KB for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:34:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMSJ-0003ti-FS for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:34:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMSF-0001Ks-Be for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:34:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLXtMd010846; Tue, 27 Dec 2005 13:33:55 -0800 Date: Tue, 27 Dec 2005 13:33:55 -0800 Message-Id: <200512272133.jBRLXtMd010846@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMSF-0001Ks-Be 9fd2d08a488d9dde8a470e8f7244e704 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512272133.jBRLXtMd010846@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11362 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:34:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:37:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMVR-0005g5-T6 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:37:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20618 for ; Tue, 27 Dec 2005 16:36:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMUo-0004fZ-1k for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:36:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMUj-0004em-2A for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:36:33 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1ErMUX-0002vl-RB for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:36:32 +0000 Received: from [192.168.1.101] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0763A142284; Tue, 27 Dec 2005 13:36:18 -0800 (PST) In-Reply-To: <200512272113.jBRLDoBD010745@ietf.cse.ucsc.edu> References: <200512272113.jBRLDoBD010745@ietf.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42fb473afff9c33ab5ea5cb258916a57@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Tue, 27 Dec 2005 13:36:14 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErMUX-0002vl-RB ec96f69e9391ba8aa3f2991a64ef587b X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/42fb473afff9c33ab5ea5cb258916a57@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11363 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:36:38 +0000 Content-Transfer-Encoding: 7bit Please propose better wording, then. I was following the guidance of the discussion when I added the second requirement on how some existing implementations aren't compliant if they calculate the value to be the last path segment. That's documented earlier in the bug comments. Thanks, lisa On Dec 27, 2005, at 1:13 PM, bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 > > julian.reschke@greenbytes.de changed: > > What |Removed |Added > ----------------------------------------------------------------------- > ----- > Status|RESOLVED |REOPENED > Resolution|FIXED | > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-12-27 13:13 ------- > I think the proposed wording is problematic: > > - it makes the case where a resource has multiple bindings special > (the first > SHOULD only applies to this case, and I wonder why) > > - the second statement is redundant, if the property SHOULD have the > same value > independant of Request-URI, then the rest follows anyway (so if people > feel this > needs special mention, then just make it non-normative comment) > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:40:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMYm-0006Iy-Sv for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:40:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21055 for ; Tue, 27 Dec 2005 16:39:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMY9-0006Th-Kk for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:40:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMY3-00064A-7J for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:39:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMXz-00038t-L6 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:39:58 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLdsev010867; Tue, 27 Dec 2005 13:39:54 -0800 Date: Tue, 27 Dec 2005 13:39:54 -0800 Message-Id: <200512272139.jBRLdsev010867@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMXz-00038t-L6 12c3724591c3fc100133ca75300243fc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/200512272139.jBRLdsev010867@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11364 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:40:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:39 ------- Ok, I've made this explicit in the changes section, although I think "Changes to If header" had covered it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:42:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMaG-0006Ww-Vm for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:42:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21306 for ; Tue, 27 Dec 2005 16:41:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMZj-0006eY-4W for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:41:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMZd-0006ds-GE for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:41:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMZZ-0003W9-O0 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:41:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLfQCO010889; Tue, 27 Dec 2005 13:41:26 -0800 Date: Tue, 27 Dec 2005 13:41:26 -0800 Message-Id: <200512272141.jBRLfQCO010889@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMZZ-0003W9-O0 f1a4a60ee74e24863aad648df8d704e1 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 193] LOCK_ISSUES_WRITE_LOCK X-Archived-At: http://www.w3.org/mid/200512272141.jBRLfQCO010889@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11365 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:41:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=193 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:41 ------- Fixed as suggested. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:43:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMb6-0006jd-0v for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:43:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21398 for ; Tue, 27 Dec 2005 16:41:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMaY-0006oJ-An for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:42:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMaT-0006nj-Lv for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:42:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMaQ-0003pU-BM for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:42:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLgO8v010909; Tue, 27 Dec 2005 13:42:24 -0800 Date: Tue, 27 Dec 2005 13:42:24 -0800 Message-Id: <200512272142.jBRLgO8v010909@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMaQ-0003pU-BM 2f02f050f86631fb7a0dc114b24c5e89 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512272142.jBRLgO8v010909@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11366 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:42:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:42 ------- Assigning to Elias so it gets covered in conf call discussions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:43:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMbW-0006ox-Om for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:43:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21491 for ; Tue, 27 Dec 2005 16:42:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMay-0006u6-IP for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:43:00 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMau-0006tL-6F for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:42:56 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1ErMap-0003xc-T3 for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:42:55 +0000 Received: (qmail invoked by alias); 27 Dec 2005 21:42:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 27 Dec 2005 22:42:49 +0100 X-Authenticated: #1915285 Message-ID: <43B1B4E4.5020708@gmx.de> Date: Tue, 27 Dec 2005 22:40:52 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512272139.jBRLdsev010867@ietf.cse.ucsc.edu> In-Reply-To: <200512272139.jBRLdsev010867@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1ErMap-0003xc-T3 982ec9df3f3053c8b065a480dff03d77 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 96] combining tagged list and untagged list X-Archived-At: http://www.w3.org/mid/43B1B4E4.5020708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11367 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:43:00 +0000 Content-Transfer-Encoding: 7bit bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=96 > > lisa@osafoundation.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:39 ------- > Ok, I've made this explicit in the changes section, although I think "Changes to > If header" had covered it. Lisa, the purpose of the "Changes" section is that implementors can get an overview about normative changes, without having to diff RFC2518 and the new spec. So every time something normative changes, it really needs to be mentioned there explicitly. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:48:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMgj-0007Te-TH for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:48:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22236 for ; Tue, 27 Dec 2005 16:47:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMg3-0000bc-FT for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:48:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMfw-0000am-K3 for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:48:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMft-0005bG-Ku for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:48:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLm4m8010937; Tue, 27 Dec 2005 13:48:04 -0800 Date: Tue, 27 Dec 2005 13:48:04 -0800 Message-Id: <200512272148.jBRLm4m8010937@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMft-0005bG-Ku aa43ceeccb322f3ea4fdd2452f5aade3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512272148.jBRLm4m8010937@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11368 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:48:15 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-27 13:48 ------- OK, proposal: "This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus treating this property as being computed with the value based on the Request-URI is deprecated)." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 16:56:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMnZ-0000Oo-9B for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 16:56:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23395 for ; Tue, 27 Dec 2005 16:54:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMmx-0002QT-Pi for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 21:55:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMmn-0002Oo-6e for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 21:55:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMmj-0007pr-0j for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 21:55:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRLt7ls010959; Tue, 27 Dec 2005 13:55:07 -0800 Date: Tue, 27 Dec 2005 13:55:07 -0800 Message-Id: <200512272155.jBRLt7ls010959@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMmj-0007pr-0j 2085922ef850a0ddb34d350ef7a9df81 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 131] DISPLAYNAME X-Archived-At: http://www.w3.org/mid/200512272155.jBRLt7ls010959@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11369 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 21:55:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=131 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-27 13:55 ------- Sure, that's good, and I think we can make the paren clause even simpler: "(thus computing this property based on the Request-URI is deprecated)" ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:07:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMyh-0002Vv-Os for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:07:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24947 for ; Tue, 27 Dec 2005 17:06:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMxZ-0005oS-4d for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:06:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMxL-0005m6-SF for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:06:07 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErMxI-0002tN-QY for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:06:07 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRM5sGx011003; Tue, 27 Dec 2005 14:05:54 -0800 Date: Tue, 27 Dec 2005 14:05:54 -0800 Message-Id: <200512272205.jBRM5sGx011003@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErMxI-0002tN-QY a956f79604a05e2b2c97b559b66b7b83 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200512272205.jBRM5sGx011003@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11370 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:06:21 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |julian.reschke@greenbytes.de Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:07:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErMyi-0002W9-59 for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:07:32 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24948 for ; Tue, 27 Dec 2005 17:06:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErMxj-0005pp-9i for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:06:31 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErMxg-0005pC-CO for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:06:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErMxX-0003Zw-6m for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:06:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRM6E4S011019; Tue, 27 Dec 2005 14:06:14 -0800 Date: Tue, 27 Dec 2005 14:06:14 -0800 Message-Id: <200512272206.jBRM6E4S011019@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErMxX-0003Zw-6m 3a8d1ee92eb40be295d52222c58759c7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200512272206.jBRM6E4S011019@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11371 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:06:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:17:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErN8a-0004aE-UX for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:17:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26228 for ; Tue, 27 Dec 2005 17:16:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErN7S-0000Ab-QL for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:16:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErN7O-00009y-KI for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:16:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErN7L-0005yA-9C for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:16:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRMGQGS011061; Tue, 27 Dec 2005 14:16:26 -0800 Date: Tue, 27 Dec 2005 14:16:26 -0800 Message-Id: <200512272216.jBRMGQGS011061@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErN7L-0005yA-9C 5608f0e2c84cc2281a1076e281ed5784 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512272216.jBRMGQGS011061@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11372 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:16:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Priority|P2 |P1 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 14:16 ------- Motion to declare consensus on this issue following discussion on the mailing list, . ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:18:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErN9N-0004nR-3E for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:18:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26284 for ; Tue, 27 Dec 2005 17:17:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErN8L-0000Hv-LH for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:17:29 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErN8I-0000HA-GH for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:17:26 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErN8F-0006VA-Ct for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:17:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRMHL75011083; Tue, 27 Dec 2005 14:17:21 -0800 Date: Tue, 27 Dec 2005 14:17:21 -0800 Message-Id: <200512272217.jBRMHL75011083@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErN8F-0006VA-Ct f6586ed82419ac66ed8607bd1d3ed357 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200512272217.jBRMHL75011083@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11373 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:17:29 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P1 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:23:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNEO-0005hA-OJ for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:23:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26839 for ; Tue, 27 Dec 2005 17:22:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErNDM-0001DC-G9 for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:22:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErNDJ-0001CU-BJ for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:22:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErNBn-00075a-Vl for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:22:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRML2vU011106; Tue, 27 Dec 2005 14:21:02 -0800 Date: Tue, 27 Dec 2005 14:21:02 -0800 Message-Id: <200512272221.jBRML2vU011106@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErNBn-00075a-Vl 80ae5e990ecdc7601e4dca7c98a8ddfc X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512272221.jBRML2vU011106@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11374 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:22:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:54:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNiW-0002aq-Dt for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:54:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00246 for ; Tue, 27 Dec 2005 17:53:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErNhO-0008Ed-3W for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:53:42 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErNhA-0008D7-UV for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:53:29 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErNh5-00088Y-Sv for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:53:28 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRMrMIH011202; Tue, 27 Dec 2005 14:53:22 -0800 Date: Tue, 27 Dec 2005 14:53:22 -0800 Message-Id: <200512272253.jBRMrMIH011202@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErNh5-00088Y-Sv 180f59aebadf3525f3da57ced4fce5fe X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 138] UNLOCK_WHAT_URL X-Archived-At: http://www.w3.org/mid/200512272253.jBRMrMIH011202@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11375 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:53:42 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=138 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 14:53 ------- *** Bug 141 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:54:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNiY-0002bS-7z for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:54:54 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00252 for ; Tue, 27 Dec 2005 17:53:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErNha-0008GB-Ad for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:53:54 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErNhE-0008DY-EG for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:53:32 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErNh5-00088V-PS for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:53:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRMrL6B011192; Tue, 27 Dec 2005 14:53:21 -0800 Date: Tue, 27 Dec 2005 14:53:21 -0800 Message-Id: <200512272253.jBRMrL6B011192@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErNh5-00088V-PS 43e42be3131bd976b2a85dade89f16c3 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 141] UNLOCK_WITHOUT_GOOD_TOKEN X-Archived-At: http://www.w3.org/mid/200512272253.jBRMrL6B011192@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11376 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:53:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=141 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 14:53 ------- Duplicate of issue #138, which asks, "What do you return if the unlock request specifies a URL on which the lock does not reside?" *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Tue Dec 27 17:55:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNj9-0002kX-Kv for webdav-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:55:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00298 for ; Tue, 27 Dec 2005 17:54:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErNiB-0008Rc-K4 for w3c-dist-auth-dist@listhub.w3.org; Tue, 27 Dec 2005 22:54:31 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErNi6-0008Qg-VO for w3c-dist-auth@listhub.w3.org; Tue, 27 Dec 2005 22:54:27 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErNi2-0008Jz-TG for w3c-dist-auth@w3.org; Tue, 27 Dec 2005 22:54:25 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBRMsK4C011221; Tue, 27 Dec 2005 14:54:20 -0800 Date: Tue, 27 Dec 2005 14:54:20 -0800 Message-Id: <200512272254.jBRMsK4C011221@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErNi2-0008Jz-TG ab9a221cb8f6e7aa7a57a41c41d9bce6 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 142] URL_ENCODING_ISSUES X-Archived-At: http://www.w3.org/mid/200512272254.jBRMsK4C011221@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11377 X-Loop: w3c-dist-auth@w3.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, 27 Dec 2005 22:54:31 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=142 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 01:22:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErUhS-0000fZ-Nj for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 01:22:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22359 for ; Wed, 28 Dec 2005 01:21:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErUfw-00050v-3k for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 06:20:40 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErUfb-0004y6-7a for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 06:20:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErUfO-0001pv-0Z for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 06:20:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBS6K2gN011499; Tue, 27 Dec 2005 22:20:02 -0800 Date: Tue, 27 Dec 2005 22:20:02 -0800 Message-Id: <200512280620.jBS6K2gN011499@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErUfO-0001pv-0Z 143b4fc2c07449fff0005ef7fd78322a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512280620.jBS6K2gN011499@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11378 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 06:20:40 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 22:20 ------- fixing status to assigned. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 01:22:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErUho-0000hL-I5 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 01:22:36 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22449 for ; Wed, 28 Dec 2005 01:21:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErUhC-0005CF-SC for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 06:21:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErUgw-00056d-Or for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 06:21:42 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErUgi-0003jC-1I for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 06:21:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBS6LRNq011518; Tue, 27 Dec 2005 22:21:27 -0800 Date: Tue, 27 Dec 2005 22:21:27 -0800 Message-Id: <200512280621.jBS6LRNq011518@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErUgi-0003jC-1I c83cca40cb22b697f4154d2235f0575c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512280621.jBS6LRNq011518@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11379 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 06:21:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 22:21 ------- updating status... ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 01:51:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErV9O-0006r1-T4 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 01:51:06 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25977 for ; Wed, 28 Dec 2005 01:49:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErV8j-0002Jq-0l for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 06:50:25 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErV8X-0002Ib-Jw for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 06:50:13 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErV8U-0002Zf-Th for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 06:50:13 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBS6o8hj011555; Tue, 27 Dec 2005 22:50:08 -0800 Date: Tue, 27 Dec 2005 22:50:08 -0800 Message-Id: <200512280650.jBS6o8hj011555@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErV8U-0002Zf-Th 5b8b64ff666bef74aa0da2c09676e1ae X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 206] broken RFC2616 references for some DAV:get* properties X-Archived-At: http://www.w3.org/mid/200512280650.jBS6o8hj011555@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11380 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 06:50:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=206 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 22:50 ------- Specifically: rfc2518bis section --> rfc2616 section ----------------------------------------------------- 14.3 getcontentlanguage Property --> 14.12 Content-Language 14.4 getcontentlength Property --> 14.13 Content-Length 14.5 getcontenttype Property --> 3.7 is fine, but maybe add 14.17? (note that these sections reference each other in 2616, so the astute / diligent reader will read both, one way or the other...) 14.6 getetag Property --> 3.11 is good, maybe add 14.19 as well (although 3.11 references 14.19 14.7 getlastmiodified Property --> 3.3.1 defines the value, but perhaps a reference to 14.29 would also be good? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 01:54:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErVCa-0007Nk-VX for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 01:54:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26270 for ; Wed, 28 Dec 2005 01:53:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErVBv-0002cB-5K for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 06:53:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErVBr-0002bK-Ko for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 06:53:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErVBn-0003TF-CJ for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 06:53:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBS6rXIu011580; Tue, 27 Dec 2005 22:53:33 -0800 Date: Tue, 27 Dec 2005 22:53:33 -0800 Message-Id: <200512280653.jBS6rXIu011580@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErVBn-0003TF-CJ 0b4a2c1377487fc74eed879d1420f3ec X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 208] spec contradictory in ETag requirements X-Archived-At: http://www.w3.org/mid/200512280653.jBS6rXIu011580@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11381 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 06:53:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=208 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |13 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-27 22:53 ------- related to issue #13 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 01:54:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErVCc-0007Nz-47 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 01:54:26 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26272 for ; Wed, 28 Dec 2005 01:53:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErVC5-0002gE-Aq for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 06:53:53 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErVBs-0002bf-FC for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 06:53:40 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErVBm-0002He-TX for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 06:53:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBS6rYMM011594; Tue, 27 Dec 2005 22:53:34 -0800 Date: Tue, 27 Dec 2005 22:53:34 -0800 Message-Id: <200512280653.jBS6rYMM011594@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErVBm-0002He-TX 5316286e112aa6652b1787c28d28503a X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 13] new ETag requirements X-Archived-At: http://www.w3.org/mid/200512280653.jBS6rYMM011594@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11382 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 06:53:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |208 nThis| | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 08:10:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erb4N-00050Y-QG for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 08:10:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05087 for ; Wed, 28 Dec 2005 08:09:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erb2e-0002EQ-4o for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 13:08:32 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Erb2a-0002Dj-1K for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 13:08:28 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Erb27-0000FC-KV for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 13:08:27 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSD7vWn012081; Wed, 28 Dec 2005 05:07:57 -0800 Date: Wed, 28 Dec 2005 05:07:57 -0800 Message-Id: <200512281307.jBSD7vWn012081@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Erb27-0000FC-KV 1b6a595b534eb33404f6c50b34ccac54 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200512281307.jBSD7vWn012081@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11384 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 13:08:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-28 05:07 ------- (as far as I can tell, only one of the three agreed upon changes was made) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 08:10:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erb4N-00050b-S8 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 08:10:20 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05088 for ; Wed, 28 Dec 2005 08:09:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erb2Q-0002Ct-Ep for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 13:08:18 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Erb2D-0002Ae-Po for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 13:08:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Erb29-00065h-9s for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 13:08:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSD7wje012091; Wed, 28 Dec 2005 05:07:58 -0800 Date: Wed, 28 Dec 2005 05:07:58 -0800 Message-Id: <200512281307.jBSD7wje012091@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Erb29-00065h-9s 6e35cfea16e3d0ac3ff789f4eba847bd X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512281307.jBSD7wje012091@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11383 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 13:08:18 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 08:50:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erbhc-0004sN-UO for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 08:50:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08871 for ; Wed, 28 Dec 2005 08:49:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erbgs-0004Kk-Es for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 13:50:06 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Erbgf-0003pn-LO for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 13:49:54 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1ErbgZ-0004RW-1x for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 13:49:52 +0000 Received: (qmail invoked by alias); 28 Dec 2005 13:49:39 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 28 Dec 2005 14:49:39 +0100 X-Authenticated: #1915285 Message-ID: <43B29790.80005@gmx.de> Date: Wed, 28 Dec 2005 14:48:00 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErbgZ-0004RW-1x edefa5b4fcdda69fb3a8700592dd0ed4 X-Original-To: w3c-dist-auth@w3.org Subject: Feedback on Bug 18 X-Archived-At: http://www.w3.org/mid/43B29790.80005@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11385 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 13:50:06 +0000 Content-Transfer-Encoding: 7bit See . The current text on ietf.webdav.org has the following new appendix: -- cut -- Appendix D. Guidance for Clients Desiring to Authenticate Many WebDAV clients already implemented have account settings (similar to the way email clients store IMAP account settings). Thus, the WebDAV client would be able to authenticate with its first couple requests to the server, provided it had a way to get the authentication challenge from the server with realm name, nonce and other challenge information. Note that the results of some requests might vary according to whether the client is authenticated or not -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous. There are a number of ways the client might be able to trigger the server do provide an authentication challenge. This appendix describes a couple approaches that seem particularly likely to work. The first approach is to perform a request that ought to require authentication. However, it's possible that a server might handle any request even without authentication, so to be entirely safe the client could add a conditional header to ensure that even if the request passes permissions checks it's not actually handled by the server. An example of following this approach would be to use a PUT request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.1.3), or if the server does not need to test authorization. Example - forcing auth challenge with write request >>Request PUT /forceauth.txt HTTP/1.1 Host: www.example.com If-Match: "xxx" Content-Type: text/plain Content-Length: 0 The second approach is to use an Authorization header (defined in [RFC2617]) which is likely to be rejected by the server but which will then prompt a proper authentication challenge. For example, the client could start with a PROPFIND request containing an Authorization header containing a made-up Basic userid:password string or with actual plausible credentials. This approach relies on the server responding with a "401 Unauthorized" along with a challenge if it receives an Authorization header with an unrecognized username, invalid password, or if it doesn't even handle Basic authentication. This seems likely to work because of the requirements of RFC2617: "If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource." Example - forcing auth challenge with Authorization header >>Request PROPFIND /docs/ HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Content-type: application/xml; charset="utf-8" Content-Length: xxxx [body omitted] -- cut -- Observations: 1) request with an "If-Match" header with a made-up ETag value. This approach might fail to result in an authentication challenge if the server does not test authorization before testing conditionals as is required (see Section 8.1.3), or if the server does not need to test authorization. -> Why are we considering servers that do not implement this spec here? 2) other challenge information. Note that the results of some requests might vary according to whether the client is authenticated or not -- a PROPFIND might return more visible resources if the client is authenticated, yet not fail if the client is anonymous. -> I checked with Apache/mod_dav, and for a resource that allows anonymous read access (such as ), sending an Authorization header does *not* trigger Authentication; it's simply ignored. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 10:12:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ercyu-0004Dn-Dx for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 10:12:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16738 for ; Wed, 28 Dec 2005 10:11:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ercxi-0003BJ-3e for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 15:11:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErcxU-00038L-1m for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 15:11:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErcxQ-0006Dh-Tj for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 15:11:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSFBFw8012196; Wed, 28 Dec 2005 07:11:15 -0800 Date: Wed, 28 Dec 2005 07:11:15 -0800 Message-Id: <200512281511.jBSFBFw8012196@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErcxQ-0006Dh-Tj a25a6fa5e20bd2a7d6a06f916ad65322 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200512281511.jBSFBFw8012196@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11386 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 15:11:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-28 07:11 ------- I believe the right thing to do is just to remove the sentence (in the section about copy and collections, there's already a warning about potential recursion problems). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 10:41:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdQK-00016A-1m for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 10:41:08 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19510 for ; Wed, 28 Dec 2005 10:39:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErdPd-0002Cg-RB for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 15:40:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErdPM-000295-V9 for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 15:40:08 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1ErdPK-0007vX-1K for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 15:40:08 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSFdxrD012223; Wed, 28 Dec 2005 07:39:59 -0800 Date: Wed, 28 Dec 2005 07:39:59 -0800 Message-Id: <200512281539.jBSFdxrD012223@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1ErdPK-0007vX-1K 7e4232ab345260c456ab180be1a406ad X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 118] WHEN_TO_MULTISTATUS_FOR_DELETE_2 X-Archived-At: http://www.w3.org/mid/200512281539.jBSFdxrD012223@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11387 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 15:40:25 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=118 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-28 07:39 ------- So far I've been unable to come up with a portable test scenario. Anyway, I think the clarifications made for bug 115 already cover this. Proposing to close the issue. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 12:42:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErfJg-0006ML-Q8 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 12:42:24 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16282 for ; Wed, 28 Dec 2005 12:41:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfIJ-0005V0-F9 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 17:40:59 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErfI6-0005TZ-TS for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 17:40:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErfI0-000769-8k for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 17:40:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSHebPV012326; Wed, 28 Dec 2005 09:40:37 -0800 Date: Wed, 28 Dec 2005 09:40:37 -0800 Message-Id: <200512281740.jBSHebPV012326@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErfI0-000769-8k 3a94a982f7b5762ace7e6f1264cf41eb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512281740.jBSHebPV012326@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11388 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 17:40:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 09:40 ------- 12/28 telecon: Julian to review example in -09 draft, Lisa to ask list re: comments, and whether to say anything about them or not. Current draft says servers SHOULD preserve namespaces, which seems to reflect people's feelings on the list. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:09:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfk3-0005QA-2W for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:09:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19864 for ; Wed, 28 Dec 2005 13:08:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfjI-0004MO-6M for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:08:52 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Erfj7-0004KS-Fk for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:08:41 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Erfiz-0007yx-BM for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:08:40 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSI8V02012405; Wed, 28 Dec 2005 10:08:31 -0800 Date: Wed, 28 Dec 2005 10:08:31 -0800 Message-Id: <200512281808.jBSI8V02012405@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Erfiz-0007yx-BM 7b7effaf9c17cf96d4da3c77bd220c19 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512281808.jBSI8V02012405@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11389 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:08:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 18, which changed state. Bug 18 Summary: no record of consensus for force-authenticate http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:09:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfk8-0005QY-0t for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:09:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19871 for ; Wed, 28 Dec 2005 13:08:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfjY-0004Th-Hj for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:09:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErfjF-0004L5-8h for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:08:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErfjA-0002HP-UA for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:08:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSI8Ulj012395; Wed, 28 Dec 2005 10:08:30 -0800 Date: Wed, 28 Dec 2005 10:08:30 -0800 Message-Id: <200512281808.jBSI8Ulj012395@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErfjA-0002HP-UA 9f05135f0da90d85260abd8dc5971c68 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 18] no record of consensus for force-authenticate X-Archived-At: http://www.w3.org/mid/200512281808.jBSI8Ulj012395@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11391 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:09:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 10:08 ------- Text in latest draft (pre-10) seems agreeable. In the course of testing this, Julian came across a bug in the Apache authentication implementation and will file a bug on it... No testing on IIS to date, however Xythos responds as expected. Barring any new issues being raised on the list in the future, the consensus of the 12/28 telecon is to regard this issue as closed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:09:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfk3-0005QB-7Q for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:09:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19863 for ; Wed, 28 Dec 2005 13:08:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfjR-0004OT-RL for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:09:01 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErfjF-0004L3-1l for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:08:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Erfj3-00080r-Lv for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:08:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSI8aKE012423; Wed, 28 Dec 2005 10:08:36 -0800 Date: Wed, 28 Dec 2005 10:08:36 -0800 Message-Id: <200512281808.jBSI8aKE012423@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Erfj3-00080r-Lv 6f089b0b0bd3d1f8af808ad95ebc4c42 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 86] DAV header definitions should use RFC3864 templates X-Archived-At: http://www.w3.org/mid/200512281808.jBSI8aKE012423@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11390 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:09:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=86 Bug 86 depends on bug 18, which changed state. Bug 18 Summary: no record of consensus for force-authenticate http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:14:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfos-0006ZI-PR for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:14:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20420 for ; Wed, 28 Dec 2005 13:13:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfoC-0005bv-Cd for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:13:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErfoA-0005aU-BB for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:13:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Erfo5-000419-Te for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:13:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSIDk0U012452; Wed, 28 Dec 2005 10:13:46 -0800 Date: Wed, 28 Dec 2005 10:13:46 -0800 Message-Id: <200512281813.jBSIDk0U012452@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Erfo5-000419-Te 593a7e9bf3f5d93a0e2e27eaa82a1f75 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 28] MOVE vs live properties X-Archived-At: http://www.w3.org/mid/200512281813.jBSIDk0U012452@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11392 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:13:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 10:13 ------- Reviewed text during 12/28 telecon and no further issues were identified; marking as resolved. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:14:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfoy-0006as-Mn for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:14:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20422 for ; Wed, 28 Dec 2005 13:13:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErfoR-0005gp-50 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:14:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1ErfoN-0005eG-NB for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:14:07 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Erfo5-0004bm-Q9 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:14:07 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F7AC142276 for ; Wed, 28 Dec 2005 10:13:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <5cd6cb95354036ea59c277750774a89b@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: webdav WG From: Lisa Dusseault Date: Wed, 28 Dec 2005 10:13:37 -0800 X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Erfo5-0004bm-Q9 9dbf16e3ec655b956cf23c999e24d6fa X-Original-To: w3c-dist-auth@w3.org Subject: Comments in XML-valued dead properties X-Archived-At: http://www.w3.org/mid/5cd6cb95354036ea59c277750774a89b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11393 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:14:11 +0000 Content-Transfer-Encoding: 7bit We've had some discussion of the preservation of comments in XML-valued properties. I believe we came to consensus on what Geoff pointed out, that when the XML-valued property is a live property, the server has very good reasons not to preserve comments -- the live property that is writable can be considered a configuration setting, the value of which the server uses to affect its own behavior. There may be other ways the server wishes to normalize live XML properties (e.g. replacing prefixes!) But at any rate, I had wondered if we consider dead properties to be different. A dead property is used for a client to set information that it can use later, or for a client to set information that other clients can use. Some dead properties are even for human consumption (perhaps with some processing). Thus, it's quite possible for clients to have a use case where the comment is important. Following this line of reasoning I added to the -09 draft some "test balloon" text: "In dead properties (considered as content, like document bodies) servers are encouraged to (MAY) preserve, for any Comment Information Item in the value: "[content]" Julian's the only one who has commented on this and proposed removing that text which I admit is rather weak as it tries to land somewhere between MAY and SHOULD. Saying nothing about comment preservation would have clients unable to rely on that: "XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved." What do y'all prefer? - Servers SHOULD preserve comments - Servers are encouraged to preserve comments - Say nothing about comments thus clients MUST NOT rely on them - Other... ? Lisa From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:41:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgF9-0004Iv-1L for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:41:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23453 for ; Wed, 28 Dec 2005 13:40:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErgEV-00043c-Ca for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:41:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErgER-0003zn-24 for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:41:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErgEL-0003r9-U1 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:41:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSIeuES012525; Wed, 28 Dec 2005 10:40:56 -0800 Date: Wed, 28 Dec 2005 10:40:56 -0800 Message-Id: <200512281840.jBSIeuES012525@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErgEL-0003r9-U1 3b6e4abe2b79d976dfd53d2edb6a94d0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512281840.jBSIeuES012525@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11395 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:41:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:41:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgF9-0004J8-FA for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:41:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23454 for ; Wed, 28 Dec 2005 13:40:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErgEP-0003zT-04 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:41:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErgED-0003yD-ED for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:40:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErgE9-0003nY-Np for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:40:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSIeh90012507; Wed, 28 Dec 2005 10:40:43 -0800 Date: Wed, 28 Dec 2005 10:40:43 -0800 Message-Id: <200512281840.jBSIeh90012507@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErgE9-0003nY-Np dc80ac7a1e5038118811b707a4a57a5d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512281840.jBSIeh90012507@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11394 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:41:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org Status|ASSIGNED |NEW ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 10:40 ------- Assigned to Lisa for inclusion in next draft, modulo some reworking of the intro sentence of sec. 14, para. 2 as discussed during 12/28 telecon. Noted that per-property exceptions mentioned for backward compatability are best raised in the section on that property. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:52:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgPa-00070m-3G for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:52:34 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24423 for ; Wed, 28 Dec 2005 13:51:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErgOa-00077J-Dx for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:51:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErgOY-00075Q-Cr for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:51:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErgOV-0006wy-A6 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:51:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSIpPtJ012558; Wed, 28 Dec 2005 10:51:25 -0800 Date: Wed, 28 Dec 2005 10:51:25 -0800 Message-Id: <200512281851.jBSIpPtJ012558@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErgOV-0006wy-A6 7d7c5f1766c56cd84d676c71fd9ab482 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 53] DAV:responsedescription content model X-Archived-At: http://www.w3.org/mid/200512281851.jBSIpPtJ012558@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11396 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:51:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=53 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 10:51 ------- Agreement during 12/28 telecon to allow both PCDATA and errors within the responsedescription. Julian to propose changes based on -09 draft. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 13:52:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgPo-00071w-0A for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:52:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24484 for ; Wed, 28 Dec 2005 13:51:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErgPF-0007IE-Ra for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 18:52:13 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErgPC-0007HO-Ph for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 18:52:10 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErgP8-000763-QO for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 18:52:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSIq5Jg012578; Wed, 28 Dec 2005 10:52:05 -0800 Date: Wed, 28 Dec 2005 10:52:05 -0800 Message-Id: <200512281852.jBSIq5Jg012578@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErgP8-000763-QO ef0252fbccd577611d1ed71568bd2b28 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 50] Property teminology inconsistent with RFC3253 X-Archived-At: http://www.w3.org/mid/200512281852.jBSIq5Jg012578@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11397 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 18:52:13 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-28 10:52 ------- As we discussed in the call, I made some changes based on the proposed new text. I couldn't tell what the proposed change for Section 14., para. 24 was. If it's just a matter of spacing between para's, I can't see why the XML2RFC formatting would treat that differently than any other paragraph spacing. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:09:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErggK-0003Vw-7o for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:09:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26902 for ; Wed, 28 Dec 2005 14:08:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ergfe-0002ho-E3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:09:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErgfV-0002gt-MQ for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:09:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1ErgfS-0003dv-2Q for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:09:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJ8um6012621; Wed, 28 Dec 2005 11:08:56 -0800 Date: Wed, 28 Dec 2005 11:08:56 -0800 Message-Id: <200512281908.jBSJ8um6012621@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1ErgfS-0003dv-2Q 2b858b7086b9387290e4a9dd6f159a8b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512281908.jBSJ8um6012621@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11398 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:09:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From lisa@osafoundation.org 2005-12-28 11:08 ------- New para for Locks and Multiple Bindings, discussed in call: A resource may be made available through more than one URI. A lock MUST cover the resource as well as the URI to which the LOCK request was addressed. The lock MAY cover other URIs mapped to the same resource as well. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:19:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgpL-0005Xc-VX for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:19:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28002 for ; Wed, 28 Dec 2005 14:18:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ergok-0005LT-K9 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:18:34 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ergoh-0005Ke-5E for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:18:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ergoc-0005Gp-KJ for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:18:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJINgm012647; Wed, 28 Dec 2005 11:18:23 -0800 Date: Wed, 28 Dec 2005 11:18:23 -0800 Message-Id: <200512281918.jBSJINgm012647@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ergoc-0005Gp-KJ 4ad28055aa273a78caa280fbd57ec95f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 54] Locks vs multiple bindings X-Archived-At: http://www.w3.org/mid/200512281918.jBSJINgm012647@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11399 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:18:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:18 ------- Resolution / wordsmithing of section 6.6 during 12/28 telecon, with Lisa making changes to pre-10 draft. Marking as resolved, pending review of -10 draft. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:29:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgzU-0008Bf-Nw for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:29:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29215 for ; Wed, 28 Dec 2005 14:28:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ergyi-0007Dn-7i for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:28:52 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ergyf-0007Cw-MI for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:28:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErgyZ-00009y-B5 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:28:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJSgSj012724; Wed, 28 Dec 2005 11:28:42 -0800 Date: Wed, 28 Dec 2005 11:28:42 -0800 Message-Id: <200512281928.jBSJSgSj012724@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErgyZ-00009y-B5 46bf3f1abe8bf66e76303663cf20ec56 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512281928.jBSJSgSj012724@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11401 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:28:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:28 ------- *** Bug 94 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:29:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErgzV-0008Br-23 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:29:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29216 for ; Wed, 28 Dec 2005 14:28:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ergyf-0007Cu-5x for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:28:49 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ergyb-0007CG-SP for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:28:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErgyY-00009M-KO for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:28:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJSgEp012710; Wed, 28 Dec 2005 11:28:42 -0800 Date: Wed, 28 Dec 2005 11:28:42 -0800 Message-Id: <200512281928.jBSJSgEp012710@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErgyY-00009M-KO 806af7d14f383927d0b51962ef9f21d7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 94] COPY and the Overwrite Header vs X-Archived-At: http://www.w3.org/mid/200512281928.jBSJSgEp012710@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11400 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:28:49 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=94 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:28 ------- original text against which this issue was raised has been removed. Also appears to be duplicated by issue 106... marking as resolved, with further discussion ocurring in the thread of issue 106. *** This bug has been marked as a duplicate of 106 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:34:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh4F-0000g4-8Q for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:34:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29656 for ; Wed, 28 Dec 2005 14:33:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erh3c-0000oi-6X for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:33:56 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Erh3a-0000nt-38 for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:33:54 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Erh3O-0001kc-CN for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:33:53 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJXgUi012756; Wed, 28 Dec 2005 11:33:42 -0800 Date: Wed, 28 Dec 2005 11:33:42 -0800 Message-Id: <200512281933.jBSJXgUi012756@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Erh3O-0001kc-CN d83c5f482a42ab942b116d627cfb9478 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512281933.jBSJXgUi012756@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11402 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:33:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ejw@cs.ucsc.edu |lisa@osafoundation.org ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:33 ------- Consensus to disallow merge behavior, with an obvious workaround to do a manual merge if that is desired. Lisa to make changes in next draft. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:34:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh4I-0000gM-HL for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:34:38 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29658 for ; Wed, 28 Dec 2005 14:33:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erh3k-0000tK-TE for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:34:04 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Erh3h-0000po-IB for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:34:01 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Erh3d-0002H1-AJ for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:34:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJXrGB012774; Wed, 28 Dec 2005 11:33:53 -0800 Date: Wed, 28 Dec 2005 11:33:53 -0800 Message-Id: <200512281933.jBSJXrGB012774@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Erh3d-0002H1-AJ ba03b79772ea0d503d6cf9ab2e6a424f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512281933.jBSJXrGB012774@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11403 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:34:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:36:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh5o-0001B9-Q8 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:36:13 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29807 for ; Wed, 28 Dec 2005 14:35:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erh5G-0001Zj-RG for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:35:38 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Erh5D-0001Z1-6o for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:35:35 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Erh54-0002DX-T9 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:35:33 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJZPOE012798; Wed, 28 Dec 2005 11:35:25 -0800 Date: Wed, 28 Dec 2005 11:35:25 -0800 Message-Id: <200512281935.jBSJZPOE012798@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Erh54-0002DX-T9 4003a603bc145ba9c895d15e59e54181 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 106] COPY and the Overwrite Header vs merge behaviour desc added X-Archived-At: http://www.w3.org/mid/200512281935.jBSJZPOE012798@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11404 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:35:38 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-28 11:35 ------- We'd misremembered what DeltaV does -- we were intending the text to allow DeltaV to be compliant. But DeltaV doesn't do a membership merge, so we can go back to saying that a membership merge is not compliant (any server that does a membership merge is quite probably not compliant with 2518 as well). The next revision of the draft will have proposed text. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:38:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erh8G-0001SK-V6 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:38:45 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29959 for ; Wed, 28 Dec 2005 14:37:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Erh7g-0001xz-9b for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:38:08 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Erh7a-0001x8-ID for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:38:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Erh7X-0003Jw-0m for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:38:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJbjt2012822; Wed, 28 Dec 2005 11:37:45 -0800 Date: Wed, 28 Dec 2005 11:37:45 -0800 Message-Id: <200512281937.jBSJbjt2012822@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Erh7X-0003Jw-0m 2e3d759409374e665532f5b4b09f3fb9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 104] Confusing new sentence in intro of COPY X-Archived-At: http://www.w3.org/mid/200512281937.jBSJbjt2012822@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11405 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:38:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=104 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:37 ------- fixed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:41:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhAk-0001vj-QQ for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:41:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00277 for ; Wed, 28 Dec 2005 14:40:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErhA7-0002Zj-V3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:40:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1ErhA1-0002Ye-8N for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:40:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Erh9y-000415-FT for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:40:32 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJeTFl012855; Wed, 28 Dec 2005 11:40:29 -0800 Date: Wed, 28 Dec 2005 11:40:29 -0800 Message-Id: <200512281940.jBSJeTFl012855@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Erh9y-000415-FT a2d29bed4778c7bbc049dc72ad7bab02 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 107] Status 102 present; but status-uri response header removed X-Archived-At: http://www.w3.org/mid/200512281940.jBSJeTFl012855@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11406 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:40:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=107 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhFz-0003Sy-PJ for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:46:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01103 for ; Wed, 28 Dec 2005 14:45:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErhFJ-0004TF-9x for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:46:01 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErhFE-0004Rg-US for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:45:57 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErhF3-0005TG-Cq for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:45:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJjiKb012879; Wed, 28 Dec 2005 11:45:44 -0800 Date: Wed, 28 Dec 2005 11:45:44 -0800 Message-Id: <200512281945.jBSJjiKb012879@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErhF3-0005TG-Cq 20af22f8a189746640ce38f0b49d04bb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 118] WHEN_TO_MULTISTATUS_FOR_DELETE_2 X-Archived-At: http://www.w3.org/mid/200512281945.jBSJjiKb012879@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11407 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:46:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=118 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:45 ------- existing text is acceptable to all concerned. marking as resolved. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:59:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhSg-0006Fw-OA for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:59:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02747 for ; Wed, 28 Dec 2005 14:58:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErhRq-0006dp-LP for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:58:58 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErhRf-0006cG-CX for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:58:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErhRX-0000pb-A9 for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:58:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJwbJT012939; Wed, 28 Dec 2005 11:58:37 -0800 Date: Wed, 28 Dec 2005 11:58:37 -0800 Message-Id: <200512281958.jBSJwbJT012939@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErhRX-0000pb-A9 9ae46649482bed7e1c2050a9934c4ed9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 200] remove "bis" compliance class X-Archived-At: http://www.w3.org/mid/200512281958.jBSJwbJT012939@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11409 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:58:58 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=200 Bug 200 depends on bug 171, which changed state. Bug 171 Summary: If header grammar http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 What |Old Value |New Value ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 14:59:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhSh-0006G8-9m for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 14:59:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02746 for ; Wed, 28 Dec 2005 14:58:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErhRk-0006d4-CW for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 19:58:52 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1ErhRd-0006bo-9q for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 19:58:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1ErhRX-0000pV-7A for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 19:58:44 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSJwaNW012929; Wed, 28 Dec 2005 11:58:36 -0800 Date: Wed, 28 Dec 2005 11:58:36 -0800 Message-Id: <200512281958.jBSJwaNW012929@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1ErhRX-0000pV-7A 005a22b9a7036d9fb3766116dff3525b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 171] If header grammar X-Archived-At: http://www.w3.org/mid/200512281958.jBSJwaNW012929@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11408 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 19:58:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=171 elias@cse.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From elias@cse.ucsc.edu 2005-12-28 11:58 ------- note that the definition of coded url has moved to another section. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 15:24:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erhqx-0003cA-V7 for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 15:24:56 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05682 for ; Wed, 28 Dec 2005 15:23:46 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1ErhqD-0005BF-Ln for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 20:24:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Erhq6-00059r-BD for w3c-dist-auth@listhub.w3.org; Wed, 28 Dec 2005 20:24:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Erhq2-0007sQ-Kd for w3c-dist-auth@w3.org; Wed, 28 Dec 2005 20:24:01 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBSKNukw013035; Wed, 28 Dec 2005 12:23:56 -0800 Date: Wed, 28 Dec 2005 12:23:56 -0800 Message-Id: <200512282023.jBSKNukw013035@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Erhq2-0007sQ-Kd e4d7c6fbfdf516faf023bd5097305221 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 206] broken RFC2616 references for some DAV:get* properties X-Archived-At: http://www.w3.org/mid/200512282023.jBSKNukw013035@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11410 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 20:24:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=206 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |lisa@osafoundation.org ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Wed Dec 28 16:00:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriPN-0005Dz-IQ for webdav-archive@megatron.ietf.org; Wed, 28 Dec 2005 16:00:31 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12271 for ; Wed, 28 Dec 2005 15:59:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EriOD-0003hD-57 for w3c-dist-auth-dist@listhub.w3.org; Wed, 28 Dec 2005 20:59:17 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EriO4-0003fF-SJ; Wed, 28 Dec 2005 20:59:09 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by aji.w3.org with esmtp (Exim 4.50) id 1EriNz-0002NY-Kl; Wed, 28 Dec 2005 20:59:07 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBSKwuJ6006166; Wed, 28 Dec 2005 15:58:56 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBSKwua4121670; Wed, 28 Dec 2005 15:58:56 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBSKwtXg005887; Wed, 28 Dec 2005 15:58:55 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBSKwt3d005881; Wed, 28 Dec 2005 15:58:55 -0500 In-Reply-To: <5cd6cb95354036ea59c277750774a89b@osafoundation.org> To: Lisa Dusseault Cc: webdav WG , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Wed, 28 Dec 2005 15:58:58 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/28/2005 15:58:55, Serialize complete at 12/28/2005 15:58:55 Content-Type: multipart/alternative; boundary="=_alternative 007342F1852570E5_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: aji.w3.org 1EriNz-0002NY-Kl 2a57965b91c69d02be7076cb2fb569d8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments in XML-valued dead properties X-Archived-At: http://www.w3.org/mid/OF973B365D.B4C63642-ON852570E5.0073324F-852570E5.007343AC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11411 X-Loop: w3c-dist-auth@w3.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, 28 Dec 2005 20:59:17 +0000 This is a multipart message in MIME format. --=_alternative 007342F1852570E5_= Content-Type: text/plain; charset="US-ASCII" I prefer saying nothing about comment preservation. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 12/28/2005 01:13:37 PM: > > > We've had some discussion of the preservation of comments in XML-valued > properties. I believe we came to consensus on what Geoff pointed out, > that when the XML-valued property is a live property, the server has > very good reasons not to preserve comments -- the live property that is > writable can be considered a configuration setting, the value of which > the server uses to affect its own behavior. There may be other ways > the server wishes to normalize live XML properties (e.g. replacing > prefixes!) > > But at any rate, I had wondered if we consider dead properties to be > different. A dead property is used for a client to set information > that it can use later, or for a client to set information that other > clients can use. Some dead properties are even for human consumption > (perhaps with some processing). Thus, it's quite possible for clients > to have a use case where the comment is important. Following this line > of reasoning I added to the -09 draft some "test balloon" text: > > "In dead properties (considered as content, like document bodies) > servers are encouraged to (MAY) preserve, for any Comment Information > Item in the value: > > "[content]" > > Julian's the only one who has commented on this and proposed removing > that text which I admit is rather weak as it tries to land somewhere > between MAY and SHOULD. Saying nothing about comment preservation > would have clients unable to rely on that: > > "XML Infoset attributes not listed above MAY be preserved by the > server, but clients MUST NOT rely on them being preserved." > > What do y'all prefer? > - Servers SHOULD preserve comments > - Servers are encouraged to preserve comments > - Say nothing about comments thus clients MUST NOT rely on them > - Other... ? > > Lisa > > --=_alternative 007342F1852570E5_= Content-Type: text/html; charset="US-ASCII"
I prefer saying nothing about comment preservation.

Cheers,
Geoff


w3c-dist-auth-request@w3.org wrote on 12/28/2005 01:13:37 PM:

>
>
> We've had some discussion of the preservation of comments in XML-valued
> properties.  I believe we came to consensus on what Geoff pointed out,
> that when the XML-valued property is a live property, the server has
> very good reasons not to preserve comments -- the live property that is
> writable can be considered a configuration setting, the value of which
> the server uses to affect its own behavior.  There may be other ways
> the server wishes to normalize live XML properties (e.g. replacing
> prefixes!)
>
> But at any rate, I had wondered if we consider dead properties to be
> different.  A dead property is used for a client to set information
> that it can use later, or for a client to set information that other
> clients can use.  Some dead properties are even for human consumption
> (perhaps with some processing).  Thus, it's quite possible for clients
> to have a use case where the comment is important.  Following this line
> of reasoning I added to the -09 draft some "test balloon" text:
>
>     "In dead properties (considered as content, like document bodies)
>     servers are encouraged to (MAY) preserve, for any Comment Information
>     Item in the value:
>
>        "[content]"
>
> Julian's the only one who has commented on this and proposed removing
> that text which I admit is rather weak as it tries to land somewhere
> between MAY and SHOULD.  Saying nothing about comment preservation
> would have clients unable to rely on that:
>
>     "XML Infoset attributes not listed above MAY be preserved by the
>     server, but clients MUST NOT rely on them being preserved."
>
> What do y'all prefer?
>   - Servers SHOULD preserve comments
>   - Servers are encouraged to preserve comments
>   - Say nothing about comments thus clients MUST NOT rely on them
>   - Other... ?
>
> Lisa
>
>
--=_alternative 007342F1852570E5_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 29 18:16:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es70h-0005F1-2y for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 18:16:39 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00406 for ; Thu, 29 Dec 2005 18:15:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es6yu-0007fn-1y for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 Dec 2005 23:14:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Es6yg-0007dd-Pc for w3c-dist-auth@listhub.w3.org; Thu, 29 Dec 2005 23:14:35 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Es6yc-0001t2-40 for w3c-dist-auth@w3.org; Thu, 29 Dec 2005 23:14:33 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B1D6142281 for ; Thu, 29 Dec 2005 15:14:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) To: webdav WG Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-11-824557280 From: Lisa Dusseault Date: Thu, 29 Dec 2005 15:14:23 -0800 X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Es6yc-0001t2-40 b72fdcf5ac40e477db7eff796062487d X-Original-To: w3c-dist-auth@w3.org Subject: Question on GULP - resources added to locked collection X-Archived-At: http://www.w3.org/mid/e364035c1e3b6be586a99b65cce3cdc2@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11412 X-Loop: w3c-dist-auth@w3.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, 29 Dec 2005 23:14:48 +0000 --Apple-Mail-11-824557280 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Looking closely at the text of GULP, point the third (from ): "- If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of deleting an internal member URI is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock." The part that confuses me is "if the resource is not locked by that lock". I am not sure how that can be the case, and if it can never happen, then the clause should be removed from the sentence. Even if it can happen, I think the sentence is even more true without that clause: "In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, then the resource becomes indirectly locked by that lock." Is that correct? Thanks, Lisa --Apple-Mail-11-824557280 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Looking closely at the text of GULP, point the third (from <): "- If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of deleting an internal member URI is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock." The part that confuses me is "if the resource is not locked by that lock". I am not sure how that can be the case, and if it can never happen, then the clause should be removed from the sentence. Even if it can happen, I think the sentence is even more true without that clause: "In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, then the resource becomes indirectly locked by that lock." Is that correct? Thanks, Lisa --Apple-Mail-11-824557280-- From w3c-dist-auth-request@frink.w3.org Thu Dec 29 18:26:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es7A7-0008UC-Q9 for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 18:26:28 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01164 for ; Thu, 29 Dec 2005 18:25:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es79R-0001xK-3J for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 Dec 2005 23:25:41 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Es79F-0001w0-4C for w3c-dist-auth@listhub.w3.org; Thu, 29 Dec 2005 23:25:29 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by aji.w3.org with esmtp (Exim 4.50) id 1Es79A-0003zj-Ib for w3c-dist-auth@w3.org; Thu, 29 Dec 2005 23:25:28 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBTNPI3d019606 for ; Thu, 29 Dec 2005 18:25:18 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBTNPIL8102044 for ; Thu, 29 Dec 2005 18:25:18 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBTNPIfA005157 for ; Thu, 29 Dec 2005 18:25:18 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBTNPIIp005137; Thu, 29 Dec 2005 18:25:18 -0500 In-Reply-To: To: Lisa Dusseault Cc: webdav WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 29 Dec 2005 18:25:46 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/29/2005 18:25:17, Serialize complete at 12/29/2005 18:25:17 Content-Type: multipart/alternative; boundary="=_alternative 0080B3F4852570E6_=" Received-SPF: pass (aji.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: aji.w3.org 1Es79A-0003zj-Ib aa4ae123a17c46c4e29da999f529bfcf X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on GULP - resources added to locked collection X-Archived-At: http://www.w3.org/mid/OFA7EBED84.09212549-ON852570E6.00803A02-852570E6.0080B42D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11413 X-Loop: w3c-dist-auth@w3.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, 29 Dec 2005 23:25:41 +0000 This is a multipart message in MIME format. --=_alternative 0080B3F4852570E6_= Content-Type: text/plain; charset="US-ASCII" The current text handles the case where the directly locked collection is being added as an internal member of a collection that is a member of that directly locked collection. In this case, the resource is already locked (so it does not "become locked"), and it is directly locked (so it does not "become indirectly locked"). Your proposed change does not handle this case. Cheers, Geoff Lisa wrote on 12/29/2005 06:14:23 PM: > > Looking closely at the text of GULP, point the third (from > 0177.html>): > > "- If a collection is directly locked by a depth:infinity lock, all > members of that collection (other than the collection itself) are > indirectly locked by that lock. In particular, if an internal > member resource is added to a collection that is locked by a > depth:infinity lock, and if the resource is not locked by that lock, > then the resource becomes indirectly locked by that lock. > Conversely, if a resource is indirectly locked with a depth:infinity > lock, and if the result of deleting an internal member URI is that > the resource is no longer a member of the collection that is > directly locked by that lock, then the resource is no longer locked > by that lock." > > The part that confuses me is "if the resource is not locked by that > lock". I am not sure how that can be the case, and if it can never > happen, then the clause should be removed from the sentence. Even if > it can happen, I think the sentence is even more true without that > clause: > > "In particular, if an internal member resource is added to > a collection that is locked by a depth:infinity lock, > then the resource becomes indirectly locked by that lock." > > Is that correct? > > Thanks, > Lisa --=_alternative 0080B3F4852570E6_= Content-Type: text/html; charset="US-ASCII"
The current text handles the case where the directly locked
collection is being added as an internal member of a collection
that is a member of that directly locked collection.

In this case, the resource is already locked (so it does not
"become locked"), and it is directly locked (so it does not
"become indirectly locked").

Your proposed change does not handle this case.

Cheers,
Geoff

Lisa wrote on 12/29/2005 06:14:23 PM:

>
> Looking closely at the text of GULP, point the third (from  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/
> 0177.html>):
>
> "- If a collection is directly locked by a depth:infinity lock, all
>     members of that collection (other than the collection itself) are
>     indirectly locked by that lock.  In particular, if an internal
>     member resource is added to a collection that is locked by a
>     depth:infinity lock, and if the resource is not locked by that lock,
>     then the resource becomes indirectly locked by that lock.
>     Conversely, if a resource is indirectly locked with a depth:infinity
>     lock, and if the result of deleting an internal member URI is that
>     the resource is no longer a member of the collection that is
>     directly locked by that lock, then the resource is no longer locked
>     by that lock."
>
> The part that confuses me is "if the resource is not locked by that  
> lock".  I am not sure how that can be the case, and if it can never  
> happen, then the clause should be removed from the sentence.  Even if  
> it can happen, I think the sentence is even more true without that  
> clause:
>
>     "In particular, if an internal member resource is added to
>     a collection that is locked by a depth:infinity lock,
>     then the resource becomes indirectly locked by that lock."
>
> Is that correct?
>
> Thanks,
> Lisa --=_alternative 0080B3F4852570E6_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 29 18:36:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es7Jx-0002n6-NB for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 18:36:33 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01931 for ; Thu, 29 Dec 2005 18:35:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es7JI-0004Sw-K5 for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 Dec 2005 23:35:52 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Es7JE-0004SH-Bj for w3c-dist-auth@listhub.w3.org; Thu, 29 Dec 2005 23:35:48 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Es7J6-000695-5k for w3c-dist-auth@w3.org; Thu, 29 Dec 2005 23:35:47 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 29533142281 for ; Thu, 29 Dec 2005 15:35:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: webdav WG From: Lisa Dusseault Date: Thu, 29 Dec 2005 15:35:36 -0800 X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Es7J6-000695-5k 1c39d866574353d2fba91d58c1913a81 X-Original-To: w3c-dist-auth@w3.org Subject: Question on GULP - properties defined as lockable, and content of a resource X-Archived-At: http://www.w3.org/mid/da65f3364c2b0f1f1ec90c405aa5de08@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11414 X-Loop: w3c-dist-auth@w3.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, 29 Dec 2005 23:35:52 +0000 Content-Transfer-Encoding: 7bit Looking carefully at the text of GULP from : - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. I see two problems with this paragraph - The content of a resource is not defined anywhere. Should this be rewritten as "any variant" in order to consistently use RFC2616 terminology? - The phrase "a live property that is defined to be lockable" implies that we define properties to be lockable, but we don't. Any suggestions for fixing this? One simplifying possibility is that if the request would modify *any* live property, the lock token is required. However I'm concerned that there are some calculated live properties for which that would be undesirable. For example, if a resource had a live property called "last-copied-to", and a COPY of that locked resource to some other location caused the server to change the value of that live property to the copy destination, then we wouldn't want to require the lock-token of the source just because of that live property. As a strawman, here's a proposed rewrite of the para, including minor rewording/rearrangement for readability: "A lock-token must be submitted in a request if that request would modify any of the following aspects of a locked resource: - any variant, - any dead property, - any live property (unless otherwise specified for that property), - for a collection, an internal member URI. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource." Lisa From w3c-dist-auth-request@frink.w3.org Thu Dec 29 18:48:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es7V1-0006JQ-GK for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 18:48:01 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02793 for ; Thu, 29 Dec 2005 18:46:48 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es7UG-0007UB-DR for w3c-dist-auth-dist@listhub.w3.org; Thu, 29 Dec 2005 23:47:12 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Es7UC-0007Tb-SL for w3c-dist-auth@listhub.w3.org; Thu, 29 Dec 2005 23:47:09 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by aji.w3.org with esmtp (Exim 4.50) id 1Es7U9-0008Ol-Bn for w3c-dist-auth@w3.org; Thu, 29 Dec 2005 23:47:08 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 055BE142281; Thu, 29 Dec 2005 15:47:02 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: multipart/alternative; boundary=Apple-Mail-12-826513748 Message-Id: Cc: webdav WG From: Lisa Dusseault Date: Thu, 29 Dec 2005 15:46:59 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.623) Received-SPF: pass (aji.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Es7U9-0008Ol-Bn 5836186954416b8618981f69777b4ab0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on GULP - resources added to locked collection X-Archived-At: http://www.w3.org/mid/a158c951518cbd4233305643d96e0408@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11415 X-Loop: w3c-dist-auth@w3.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, 29 Dec 2005 23:47:12 +0000 --Apple-Mail-12-826513748 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable So an example of this occurring is a COPY of a locked collection to a=20 location inside the locked collection ( to make a copy inside itself). =20= Still, doesn't the new member become indirectly locked? It's not the=20= same resource as the original locked collection. Since it's not the=20 same resource, I disagree with your point -- I think it's still=20 accurate to say that the new member (the copy) becomes indirectly=20 locked. Perhaps another tenet of our locking model is that a copy of a locked=20 resource does not create a new lock, nor is it directly or indirectly=20 locked by the original lock, unless the original locked resource is a=20 collection and the copy destination is a member of that locked=20 collection. Lisa On Dec 29, 2005, at 3:25 PM, Geoffrey M Clemm wrote: > > The current text handles the case where the directly locked > collection is being added as an internal member of a collection > that is a member of that directly locked collection. > > In this case, the resource is already locked (so it does not > "become locked"), and it is directly locked (so it does not > "become indirectly locked"). > > Your proposed change does not handle this case. > > Cheers, > Geoff > > Lisa wrote on 12/29/2005 06:14:23 PM: > > > > > Looking closely at the text of GULP, point the third (from =A0 > > > 0177.html>): > > > > "- If a collection is directly locked by a depth:infinity lock, all > > =A0 =A0 members of that collection (other than the collection = itself)=20 > are > > =A0 =A0 indirectly locked by that lock. =A0In particular, if an = internal > > =A0 =A0 member resource is added to a collection that is locked by = a > > =A0 =A0 depth:infinity lock, and if the resource is not locked by = that=20 > lock, > > =A0 =A0 then the resource becomes indirectly locked by that lock. > > =A0 =A0 Conversely, if a resource is indirectly locked with a=20 > depth:infinity > > =A0 =A0 lock, and if the result of deleting an internal member URI = is=20 > that > > =A0 =A0 the resource is no longer a member of the collection that = is > > =A0 =A0 directly locked by that lock, then the resource is no = longer=20 > locked > > =A0 =A0 by that lock." > > > > The part that confuses me is "if the resource is not locked by that=20= > =A0 > > lock". =A0I am not sure how that can be the case, and if it can = never=20 > =A0 > > happen, then the clause should be removed from the sentence. =A0Even=20= > if =A0 > > it can happen, I think the sentence is even more true without that = =A0 > > clause: > > > > =A0 =A0 "In particular, if an internal member resource is added to > > =A0 =A0 a collection that is locked by a depth:infinity lock, > > =A0 =A0 then the resource becomes indirectly locked by that lock." > > > > Is that correct? > > > > Thanks, > > Lisa= --Apple-Mail-12-826513748 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So an example of this occurring is a COPY of a locked collection to a location inside the locked collection ( to make a copy inside itself). =20= Still, doesn't the new member become indirectly locked? It's not the same resource as the original locked collection. Since it's not the same resource, I disagree with your point -- I think it's still accurate to say that the new member (the copy) becomes indirectly locked. Perhaps another tenet of our locking model is that a copy of a locked resource does not create a new lock, nor is it directly or indirectly locked by the original lock, unless the original locked resource is a collection and the copy destination is a member of that locked collection. =20 Lisa On Dec 29, 2005, at 3:25 PM, Geoffrey M Clemm wrote: The current text handles the case where the directly locked=20 collection is being added as an internal member of a collection=20 that is a member of that directly locked collection.=20 In this case, the resource is already locked (so it does not=20 "become locked"), and it is directly locked (so it does not=20 "become indirectly locked").=20 Your proposed change does not handle this case.=20 Cheers,=20 Geoff=20 Lisa wrote on 12/29/2005 06:14:23 = PM: > > Looking closely at the text of GULP, point the third (from =A0 > = < > 0177.html>): > > "- If a collection is directly locked by a depth:infinity lock, all > =A0 =A0 members of that collection (other than the collection itself) are > =A0 =A0 indirectly locked by that lock. =A0In particular, if an internal > =A0 =A0 member resource is added to a = collection that is locked by a > =A0 =A0 depth:infinity lock, and if the = resource is not locked by that lock, > =A0 =A0 then the resource becomes indirectly locked by that lock. > =A0 =A0 Conversely, if a resource is indirectly locked with a depth:infinity > =A0 =A0 lock, and if the result of deleting an internal member URI is that > =A0 =A0 the resource is no longer a member of = the collection that is > =A0 =A0 directly locked by that lock, then the resource is no longer locked > =A0 =A0 by that lock." > > The part that confuses me is "if the resource is not locked by that =A0 > lock". =A0I am not sure how that can be the case, and if it can never =A0 > happen, then the clause should be removed from the sentence. =A0Even if =A0 > it can happen, I think the sentence is even more true without that =A0 > clause: > > =A0 =A0 "In particular, if an internal member resource is added to > =A0 =A0 a collection that is locked by a depth:infinity lock, > =A0 =A0 then the resource becomes indirectly locked by that lock." > > Is that correct? > > Thanks, > Lisa= --Apple-Mail-12-826513748-- From w3c-dist-auth-request@frink.w3.org Thu Dec 29 20:09:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8m1-0005S9-80 for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 20:09:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10664 for ; Thu, 29 Dec 2005 20:08:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es8kq-0007Ep-1N for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 01:08:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Es8kd-0007Ce-Mg for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 01:08:11 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by lisa.w3.org with esmtp (Exim 4.50) id 1Es8ka-0000kt-Nm for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 01:08:11 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBU187jW020132 for ; Thu, 29 Dec 2005 20:08:07 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBU187hd118782 for ; Thu, 29 Dec 2005 20:08:07 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBU187nt021530 for ; Thu, 29 Dec 2005 20:08:07 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBU187QP021527 for ; Thu, 29 Dec 2005 20:08:07 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 29 Dec 2005 20:08:36 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/29/2005 20:08:06, Serialize complete at 12/29/2005 20:08:06 Content-Type: multipart/alternative; boundary="=_alternative 000647AF852570E7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: lisa.w3.org 1Es8ka-0000kt-Nm 2e69b0d3159ac386b6a7ec62df2973e9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on GULP - properties defined as lockable, and content of a resource X-Archived-At: http://www.w3.org/mid/OF2432E463.B628A827-ON852570E7.0006293B-852570E7.00064825@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11416 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 01:08:24 +0000 This is a multipart message in MIME format. --=_alternative 000647AF852570E7_= Content-Type: text/plain; charset="US-ASCII" This rewording is fine with me. Cheers, Geoff Lisa wrote on 12/29/2005 06:35:36 PM: > > Looking carefully at the text of GULP from > 0177.html>: > > - If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or an internal member URI of a > locked collection, the request MUST fail unless the lock-token for > that lock is submitted in the request. An internal member URI > of a collection is considered to be modified if it is added, > removed, or identifies a different resource. > > > I see two problems with this paragraph > - The content of a resource is not defined anywhere. Should this be > rewritten as "any variant" in order to consistently use RFC2616 > terminology? > - The phrase "a live property that is defined to be lockable" implies > that we define properties to be lockable, but we don't. Any > suggestions for fixing this? > > One simplifying possibility is that if the request would modify *any* > live property, the lock token is required. However I'm concerned that > there are some calculated live properties for which that would be > undesirable. For example, if a resource had a live property called > "last-copied-to", and a COPY of that locked resource to some other > location caused the server to change the value of that live property to > the copy destination, then we wouldn't want to require the lock-token > of the source just because of that live property. > > As a strawman, here's a proposed rewrite of the para, including minor > rewording/rearrangement for readability: > > "A lock-token must be submitted in a request if that request would > modify any of the following aspects of a locked resource: > - any variant, > - any dead property, > - any live property (unless otherwise specified for that property), > - for a collection, an internal member URI. > An internal member URI of a collection is considered to be modified > if it is added, removed, or identifies a different resource." > > Lisa > > --=_alternative 000647AF852570E7_= Content-Type: text/html; charset="US-ASCII"
This rewording is fine with me.

Cheers,
Geoff

Lisa wrote on 12/29/2005 06:35:36 PM:

>
> Looking carefully at the text of GULP from  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/
> 0177.html>:
>
> - If a request would modify the content for a locked resource, a dead
>     property of a locked resource, a live property that is defined to be
>     lockable for a locked resource, or an internal member URI of a
>     locked collection, the request MUST fail unless the lock-token for
>     that lock is submitted in the request.  An internal member URI
>     of a collection is considered to be modified if it is added,
>     removed, or identifies a different resource.
>
>
> I see two problems with this paragraph
>   - The content of a resource is not defined anywhere.  Should this be  
> rewritten as "any variant" in order to consistently use RFC2616  
> terminology?
>   - The phrase "a live property that is defined to be lockable" implies  
> that we define properties to be lockable, but we don't.  Any  
> suggestions for fixing this?
>
> One simplifying possibility is that if the request would modify *any*  
> live property, the lock token is required.  However I'm concerned that  
> there are some calculated live properties for which that would be  
> undesirable.  For example, if a resource had a live property called  
> "last-copied-to", and a COPY of that locked resource to some other  
> location caused the server to change the value of that live property to  
> the copy destination, then we wouldn't want to require the lock-token  
> of the source just because of that live property.
>
> As a strawman, here's a proposed rewrite of the para, including minor  
> rewording/rearrangement for readability:
>
>     "A lock-token must be submitted in a request if that request would
>     modify any of the following aspects of a locked resource:
>      - any variant,
>    - any dead property,
>    - any live property (unless otherwise specified for that property),
>    - for a collection, an internal member URI.
>     An internal member URI of a collection is considered to be modified
>     if it is added, removed, or identifies a different resource."
>
> Lisa
>
>
--=_alternative 000647AF852570E7_=-- From w3c-dist-auth-request@frink.w3.org Thu Dec 29 20:18:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8ul-00013C-GM for webdav-archive@megatron.ietf.org; Thu, 29 Dec 2005 20:18:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11446 for ; Thu, 29 Dec 2005 20:17:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Es8u6-0001wV-DT for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 01:17:58 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Es8u2-0001uL-CQ for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 01:17:54 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.50) id 1Es8tz-0002x9-7x for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 01:17:53 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBU1Ho6N018515 for ; Thu, 29 Dec 2005 20:17:50 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBU1HoL8117570 for ; Thu, 29 Dec 2005 20:17:50 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBU1HoIr016647 for ; Thu, 29 Dec 2005 20:17:50 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBU1HoJV016644 for ; Thu, 29 Dec 2005 20:17:50 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Thu, 29 Dec 2005 20:18:18 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/29/2005 20:17:50, Serialize complete at 12/29/2005 20:17:50 Content-Type: multipart/alternative; boundary="=_alternative 00072B37852570E7_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Es8tz-0002x9-7x 85557746529e9d4a0ff1b6680be555df X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on GULP - resources added to locked collection X-Archived-At: http://www.w3.org/mid/OFE227362E.0903F43E-ON852570E7.00064D36-852570E7.00072B9E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11417 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 01:17:58 +0000 This is a multipart message in MIME format. --=_alternative 00072B37852570E7_= Content-Type: text/plain; charset="US-ASCII" Lisa Dusseault wrote on 12/29/2005 06:46:59 PM: > So an example of this occurring is a COPY of a locked collection to a > location inside the locked collection ( to make a copy inside itself). > Still, doesn't the new member become indirectly locked? It's not the > same resource as the original locked collection. Since it's not the > same resource, I disagree with your point -- I think it's still > accurate to say that the new member (the copy) becomes indirectly > locked. No, this is not an example, because as you point out, this creates a new resource, which becomes indirectly locked. An example of this is a BIND of the locked collection to a location inside the locked collection. Another example is when there are two URL's that are mapped to the locked collection, and you issue a MOVE request on the URL that is not the lock-root, with a Destination that is a member of the locked collection. > Perhaps another tenet of our locking model is that a copy of a locked > resource does not create a new lock, nor is it directly or indirectly > locked by the original lock, unless the original locked resource is a > collection and the copy destination is a member of that locked > collection. That is true, but it follows from the fact that the lock is associated with the request-URL of the LOCK (i.e., the lock-root). So I wouldn't state this as part of GULP, since it is redundant (although I wouldn't object if something like this were added to some discursive text elsewhere in the locking section). Cheers, Geoff > On Dec 29, 2005, at 3:25 PM, Geoffrey M Clemm wrote: > > > The current text handles the case where the directly locked > > collection is being added as an internal member of a collection > > that is a member of that directly locked collection. > > > > In this case, the resource is already locked (so it does not > > "become locked"), and it is directly locked (so it does not > > "become indirectly locked"). > > > > Your proposed change does not handle this case. > > > > Lisa wrote on 12/29/2005 06:14:23 PM: > > > > > > > > Looking closely at the text of GULP, point the third (from > > > > > 0177.html>): > > > > > > "- If a collection is directly locked by a depth:infinity lock, all > > > members of that collection (other than the collection itself) > > are > > > indirectly locked by that lock. In particular, if an internal > > > member resource is added to a collection that is locked by a > > > depth:infinity lock, and if the resource is not locked by that > > lock, > > > then the resource becomes indirectly locked by that lock. > > > Conversely, if a resource is indirectly locked with a > > depth:infinity > > > lock, and if the result of deleting an internal member URI is > > that > > > the resource is no longer a member of the collection that is > > > directly locked by that lock, then the resource is no longer > > locked > > > by that lock." > > > > > > The part that confuses me is "if the resource is not locked by that > > > > > lock". I am not sure how that can be the case, and if it can never > > > > > happen, then the clause should be removed from the sentence. Even > > if > > > it can happen, I think the sentence is even more true without that > > > clause: > > > > > > "In particular, if an internal member resource is added to > > > a collection that is locked by a depth:infinity lock, > > > then the resource becomes indirectly locked by that lock." > > > > > > Is that correct? > > > > > > Thanks, > > > Lisa --=_alternative 00072B37852570E7_= Content-Type: text/html; charset="US-ASCII"
Lisa Dusseault <lisa@osafoundation.org> wrote on 12/29/2005 06:46:59 PM:

> So an example of this occurring is a COPY of a locked collection to a
> location inside the locked collection ( to make a copy inside itself).  
>   Still, doesn't the new member become indirectly locked?  It's not the
> same resource as the original locked collection.  Since it's not the
> same resource, I disagree with your point -- I think it's still
> accurate to say that the new member (the copy) becomes indirectly
> locked.

No, this is not an example, because as you point out, this
creates a new resource, which becomes indirectly locked.

An example of this is a BIND of the locked collection to a location
inside the locked collection.  Another example is when there are
two URL's that are mapped to the locked collection, and you issue
a MOVE request on the URL that is not the lock-root, with a
Destination that is a member of the locked collection.

> Perhaps another tenet of our locking model is that a copy of a locked
> resource does not create a new lock, nor is it directly or indirectly
> locked by the original lock, unless the original locked resource is a
> collection and the copy destination is a member of that locked
> collection.

That is true, but it follows from the fact that the lock is associated
with the request-URL of the LOCK (i.e., the lock-root).  So I wouldn't
state this as part of GULP, since it is redundant (although I wouldn't
object if something like this were added to some discursive text
elsewhere in the locking section).

Cheers,
Geoff



> On Dec 29, 2005, at 3:25 PM, Geoffrey M Clemm wrote:
>
> > The current text handles the case where the directly locked
> > collection is being added as an internal member of a collection
> > that is a member of that directly locked collection.
> >
> > In this case, the resource is already locked (so it does not
> > "become locked"), and it is directly locked (so it does not
> > "become indirectly locked").
> >
> > Your proposed change does not handle this case.
> >
> > Lisa wrote on 12/29/2005 06:14:23 PM:
> >
> >  >
> >  > Looking closely at the text of GULP, point the third (from  
> >  > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/
> >  > 0177.html>):
> >  >
> >  > "- If a collection is directly locked by a depth:infinity lock, all
> >  >     members of that collection (other than the collection itself)
> > are
> >  >     indirectly locked by that lock.  In particular, if an internal
> >  >     member resource is added to a collection that is locked by a
> >  >     depth:infinity lock, and if the resource is not locked by that
> > lock,
> >  >     then the resource becomes indirectly locked by that lock.
> >  >     Conversely, if a resource is indirectly locked with a
> > depth:infinity
> >  >     lock, and if the result of deleting an internal member URI is
> > that
> >  >     the resource is no longer a member of the collection that is
> >  >     directly locked by that lock, then the resource is no longer
> > locked
> >  >     by that lock."
> >  >
> >  > The part that confuses me is "if the resource is not locked by that
> >  
> >  > lock".  I am not sure how that can be the case, and if it can never
> >  
> >  > happen, then the clause should be removed from the sentence.  Even
> > if  
> >  > it can happen, I think the sentence is even more true without that  
> >  > clause:
> >  >
> >  >     "In particular, if an internal member resource is added to
> >  >     a collection that is locked by a depth:infinity lock,
> >  >     then the resource becomes indirectly locked by that lock."
> >  >
> >  > Is that correct?
> >  >
> >  > Thanks,
> >  > Lisa --=_alternative 00072B37852570E7_=-- From w3c-dist-auth-request@frink.w3.org Fri Dec 30 13:19:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOqE-0000Nm-TO for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 13:19:03 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22783 for ; Fri, 30 Dec 2005 13:17:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsOoM-0005FA-8u for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 18:17:06 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsOo6-0005D8-CA for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 18:16:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsOo1-0006Pc-4p for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 18:16:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUIGgwS014918; Fri, 30 Dec 2005 10:16:42 -0800 Date: Fri, 30 Dec 2005 10:16:42 -0800 Message-Id: <200512301816.jBUIGgwS014918@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsOo1-0006Pc-4p 4ba050916fe01e897ed08ab981db45ff X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 206] broken RFC2616 references for some DAV:get* properties X-Archived-At: http://www.w3.org/mid/200512301816.jBUIGgwS014918@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11418 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 18:17:06 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=206 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:16 ------- Thanks, this was easy to fix and I added the new references too ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 13:21:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOsZ-0000fp-5Q for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 13:21:27 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23296 for ; Fri, 30 Dec 2005 13:20:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsOrw-0005zv-AL for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 18:20:48 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsOrt-0005zL-Fq for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 18:20:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsOrr-0008Py-KM for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 18:20:45 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUIKUbW014946; Fri, 30 Dec 2005 10:20:30 -0800 Date: Fri, 30 Dec 2005 10:20:30 -0800 Message-Id: <200512301820.jBUIKUbW014946@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EsOrr-0008Py-KM 4f2303f1c10b18b4de2f5b96e965de1b X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 210] incorrect statement on PROPPATCH and property recurrence X-Archived-At: http://www.w3.org/mid/200512301820.jBUIKUbW014946@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11419 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 18:20:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=210 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|joe-bugzilla@cursive.net |elias@cse.ucsc.edu ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:20 ------- It's true that RFC2518 made no restriction on whether a PROPPATCH could set the same property more than once. This might be a good restriction to add, however. If we do add it, it should be a requirement in the PROPPATCH section instead of just a note elsewhere. Let's discuss in some con call. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 13:23:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOv0-0001Co-Kl for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 13:23:58 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23553 for ; Fri, 30 Dec 2005 13:22:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsOuL-0006KG-Jx for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 18:23:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsOuJ-0006Jg-KZ for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 18:23:15 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsOuH-0000hH-Nn for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 18:23:15 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUINDrk014967; Fri, 30 Dec 2005 10:23:13 -0800 Date: Fri, 30 Dec 2005 10:23:13 -0800 Message-Id: <200512301823.jBUINDrk014967@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EsOuH-0000hH-Nn 9e930115333ada6db59151de523dca29 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 209] invalid etag in example X-Archived-At: http://www.w3.org/mid/200512301823.jBUINDrk014967@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11420 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 18:23:17 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=209 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:23 ------- I guess you mean that this etag is invalid because it wasn't quoted. I've fixed that now. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 13:45:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPG8-000079-8K for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 13:45:48 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25423 for ; Fri, 30 Dec 2005 13:44:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsPFL-0002Pi-Ld for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 18:44:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsPFE-0002P5-3p for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 18:44:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsPFC-0006Ut-4b for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 18:44:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUIinXS015001; Fri, 30 Dec 2005 10:44:49 -0800 Date: Fri, 30 Dec 2005 10:44:49 -0800 Message-Id: <200512301844.jBUIinXS015001@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EsPFC-0006Ut-4b 50473d924deeab71265e0e9d7da0d855 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 208] spec contradictory in ETag requirements X-Archived-At: http://www.w3.org/mid/200512301844.jBUIinXS015001@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11421 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 18:44:59 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=208 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:44 ------- This bug doesn't really explain what the contradiction is thought to be... - RFC2616 sats the ETag header "provides the current value of the entity tag for the requested variant" - RFC2518 has the language about "the ETag header returned by a GET without accept headers." Another way of stating the requirement for RFC2518 is that when the 'getetag' property is returned, the value is returned for the default variant. So the GET and PUT requests defined in 2616 are for the requested variant, while the getetag property is for the default variant. The new requirement assumes that these are the same (that there is only one variant) which is not always the case in theory. If that's the source of the problem, I can fix that -- I think the easiest way is simply to remove the clause beginning with "as well". ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 13:48:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPIx-0000tf-V6 for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 13:48:44 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25607 for ; Fri, 30 Dec 2005 13:47:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsPIH-0004IV-8b for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 18:48:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsPIC-0004GV-BD for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 18:47:56 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsPI5-0007GP-Ge for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 18:47:56 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUIlmqp015027; Fri, 30 Dec 2005 10:47:48 -0800 Date: Fri, 30 Dec 2005 10:47:48 -0800 Message-Id: <200512301847.jBUIlmqp015027@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EsPI5-0007GP-Ge 1db6309ea85665d0d7e055bb3a48d966 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 207] Compliance class descriptions for "1" and "2" X-Archived-At: http://www.w3.org/mid/200512301847.jBUIlmqp015027@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11422 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 18:48:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=207 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:47 ------- This text was unchanged from RFC2518 yet somehow people figured that one out :) If this text is acceptable then we can consider this bug fixed: " A class 1 compliant resource MUST meet all "MUST" requirements in all sections of this document, except those related to locking. " (added last phrase) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 14:00:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPUj-00048u-C5 for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 14:00:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26959 for ; Fri, 30 Dec 2005 13:59:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsPU0-0007Aw-Kq for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 19:00:08 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsPTw-0006wS-Ri for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 19:00:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsPTr-0001tb-VS for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 19:00:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUIxvt5015058; Fri, 30 Dec 2005 10:59:57 -0800 Date: Fri, 30 Dec 2005 10:59:57 -0800 Message-Id: <200512301859.jBUIxvt5015058@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsPTr-0001tb-VS df36bed88e6bd3b8b1cf65fbaa340d84 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 184] Section 19.8 added with no open issue nor WG consensus X-Archived-At: http://www.w3.org/mid/200512301859.jBUIxvt5015058@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11423 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 19:00:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From lisa@osafoundation.org 2005-12-30 10:59 ------- This bug is a process objection, not a spec issue. If there's a problem with the text or a proposal that it be removed, please change the bug summary/description or enter a new bug and describe what the problem with the text is. For the record, the section added is "Hosting malicious scripts executed on client machines". This is a security consideration that has actually come up in the field, as reported to me by Barry Lind of Xythos a few months ago. Some schools deploying WebDAV servers have also deployed filters or disallowed certain content types as they've figured out this security risk on their own. I can ask that Barry send his mail to the list but I think it's pretty obvious from the text in recent drafts what Barry's proposal was. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 14:27:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPuG-0003JA-N4 for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 14:27:16 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29968 for ; Fri, 30 Dec 2005 14:26:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsPtL-0003h3-GW for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 19:26:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsPtE-0003fe-DZ for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 19:26:12 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsPtC-0001Kh-C4 for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 19:26:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUJQ9dD015093; Fri, 30 Dec 2005 11:26:09 -0800 Date: Fri, 30 Dec 2005 11:26:09 -0800 Message-Id: <200512301926.jBUJQ9dD015093@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EsPtC-0001Kh-C4 280ffc82a258a09914d94d9d2c782d46 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 208] spec contradictory in ETag requirements X-Archived-At: http://www.w3.org/mid/200512301926.jBUJQ9dD015093@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11424 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 19:26:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=208 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-30 11:26 ------- Yes, that would fix the conflict. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 14:32:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPzF-00059O-6i for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 14:32:25 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00548 for ; Fri, 30 Dec 2005 14:31:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsPyd-0005Yt-By for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 19:31:47 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsPyZ-0005Xo-Qp for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 19:31:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsPyV-0002IE-FX for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 19:31:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUJVd6U015112; Fri, 30 Dec 2005 11:31:39 -0800 Date: Fri, 30 Dec 2005 11:31:39 -0800 Message-Id: <200512301931.jBUJVd6U015112@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsPyV-0002IE-FX ea285e40f413f3b5cf0d7f829a4dd375 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 184] Section 19.8 added with no open issue nor WG consensus X-Archived-At: http://www.w3.org/mid/200512301931.jBUJVd6U015112@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11425 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 19:31:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-30 11:31 ------- See discussion in . ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 17:13:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsSUt-0000pP-6c for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 17:13:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19295 for ; Fri, 30 Dec 2005 17:12:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsSUG-0002tx-0U for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 22:12:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsSUC-0002so-RE for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 22:12:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsSU8-0004G1-MD for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 22:12:31 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBUMCOn2015245; Fri, 30 Dec 2005 14:12:24 -0800 Date: Fri, 30 Dec 2005 14:12:24 -0800 Message-Id: <200512302212.jBUMCOn2015245@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsSU8-0004G1-MD 11bb57cc783bdfebee79705ab3d03214 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 184] Clarifications requested for section 19.8 on hosting malicious content X-Archived-At: http://www.w3.org/mid/200512302212.jBUMCOn2015245@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11427 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 22:12:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Section 19.8 added with no |Clarifications requested for |open issue nor WG consensus |section 19.8 on hosting | |malicious content ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 17:13:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsSUt-0000pQ-Kd for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 17:13:15 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19294 for ; Fri, 30 Dec 2005 17:12:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsSTV-0002rl-UU for w3c-dist-auth-dist@listhub.w3.org; Fri, 30 Dec 2005 22:11:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsSTI-0002qx-2x for w3c-dist-auth@listhub.w3.org; Fri, 30 Dec 2005 22:11:36 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1EsSSz-0007ap-Lk for w3c-dist-auth@w3.org; Fri, 30 Dec 2005 22:11:35 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5A0911422B9; Fri, 30 Dec 2005 14:11:10 -0800 (PST) In-Reply-To: <43882769.5010500@gmx.de> References: <43882769.5010500@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDav From: Lisa Dusseault Date: Fri, 30 Dec 2005 14:11:05 -0800 To: Julian Reschke , Barry Lind X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EsSSz-0007ap-Lk 875af61945475fd9b775622ca2a07b40 X-Original-To: w3c-dist-auth@w3.org Subject: New Security considerations (was: Re: [Bug 184] ) X-Archived-At: http://www.w3.org/mid/d85c43f6ed7af2fdc64ccebd62a6e409@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11426 X-Loop: w3c-dist-auth@w3.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, 30 Dec 2005 22:11:49 +0000 Content-Transfer-Encoding: 7bit Barry, can you provide more info or pointers on how a script can read another user's cookies? Aside from that point of confusion, Julian, it sounds like you have some ways to improve this section, but I'm not sure which way you propose to go (e.g. whether the discussion of arbitrary content needs to be expanded or other). Can you make a concrete proposal? Lisa On Nov 26, 2005, at 1:14 AM, Julian Reschke wrote: > > Cullen Jennings wrote: >> Do you think it is wrong? > > It's not necessarily wrong, but it definitively needs to be discussed > and understood. This is a Security Consideration, and if we add > something new *here*, we better make sure it's correct. > > Quoting: > -08.html#rfc.section.19.8>: > >> HTTP has the ability to host scripts which are executed on client >> machines. These scripts can be used to read another user's cookies >> and therefore may provide an attacker the ability to use another >> user's session, assume their identity temporarily and gain access >> to >> their resources. Other attacks are also possible with client- >> executed scripts. > > 1) How would a script be able to read another user's cookies? If this > is about potential bugs in user agents, it should say so. The way it's > written now confuses me, because I don't understand the risk yet. > > 2) And yes, letting people store arbitrary content on a shared server > introduces the same security problems when people share a file server, > or people download code from the Web. In particular, this includes > executables, or file types with security issues (such as the recent > JPG-related attacks). RFC2518bis *could* talk about that, but then > this really needs to be expanded a lot. > >> WebDAV may worsen this situation only by making it easier for a Web >> server to host content provided by many different authors (making >> it >> harder to trust the content providers) and to host content with >> restricted access alongside public pages (see particularly >> RFC3744). > > How is the latter a security problem? > >> HTTP servers may mitigate some of these threats by filtering >> content >> in areas where many authors contribute pages -- the server could, >> for >> example, remove script from HTML pages. > > It could also run virus scanners on new content. > >> This vulnerability should provide yet another reason for server >> implementors and administrators not to replace authentication >> mechanisms with cookie-based session tokens if there's any >> sensitive >> information relying on the authenticated identity. > > This relates back to the cookie discussion above. I prefer HTTP auth > as well, but I don't think this is the right place to evangelize it. > >> HTTP and WebDAV client implementors might consider locking down the >> use of scripts and cookies based on these considerations. > > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Fri Dec 30 19:11:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsULl-0005BT-2v for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:11:57 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02840 for ; Fri, 30 Dec 2005 19:10:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsUKO-0000bq-VC for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 00:10:32 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsUKC-0000Zn-RS for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 00:10:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EsUKA-0001MY-7H for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 00:10:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBV0AG78015318; Fri, 30 Dec 2005 16:10:16 -0800 Date: Fri, 30 Dec 2005 16:10:16 -0800 Message-Id: <200512310010.jBV0AG78015318@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EsUKA-0001MY-7H 682fa6570d20f05524aac272cd1890ae X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512310010.jBV0AG78015318@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11428 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 00:10:32 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From lisa@osafoundation.org 2005-12-30 16:10 ------- I can't follow the reasons for all the changes in that document, so it's hard for me to tell what your (Julian's) intent is with the changes. I don't like having all the normative text in section 8.1.5 -- that section was intended to be an introduction to the topic and has gotten out of hand. I'd like to leave that as an introduction because section 8.1 is already a large enough digression from the actual methods we discuss in the rest of section 8. Other comments: - This text proposed is inconsistent with issues you've raised before, with regards to making 403 and 409 the only allowed error codes. - the last paragraph in your proposal for section 8.1.5 is redundant with earlier text - Some of the changes (e.g. in section 8.2) are unrelated to this issue - The guidance on creating one's own error codes was seemingly removed - Some of the error code sections (from 8.2 to 8.12) were reorganized but others remained organized differently. I haven't adopted these changes, is there some reason for them? - I don't agree that we should list the preconditions/postconditions without suggesting what status code to use with. I find the formatting I've been using clearer than that of the proposed change. I'm making a number of modifications to the draft based on these proposals but I'm sure we'll have to iterate. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 19:15:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUPY-0006OG-R0 for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:15:52 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03155 for ; Fri, 30 Dec 2005 19:14:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsUOw-0002AS-3b for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 00:15:14 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsUOt-0001wm-72 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 00:15:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsUOp-0004uf-A8 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 00:15:10 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBV0F4d0015341; Fri, 30 Dec 2005 16:15:04 -0800 Date: Fri, 30 Dec 2005 16:15:04 -0800 Message-Id: <200512310015.jBV0F4d0015341@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsUOp-0004uf-A8 9723a4abaccf9c63aa6830a84a9e4245 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 179] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200512310015.jBV0F4d0015341@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11429 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 00:15:14 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 16:15 ------- The text that the no-lock is not special was already in the main If header section text, but I'm happy to reiterate that in the not production section. I prefer to keep the MUST language, however -- requirements are just so much clearer than descriptive statements when we're able to use them. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 19:23:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUWW-0007tM-Qq for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:23:04 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03898 for ; Fri, 30 Dec 2005 19:21:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsUVr-0003LW-Fe for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 00:22:23 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsUVo-0003KP-AT for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 00:22:20 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EsUVk-0003dQ-IK for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 00:22:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBV0MFd1015363; Fri, 30 Dec 2005 16:22:15 -0800 Date: Fri, 30 Dec 2005 16:22:15 -0800 Message-Id: <200512310022.jBV0MFd1015363@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EsUVk-0003dQ-IK c28b1ed834087d159707094e90f9811c X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 177] "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/200512310022.jBV0MFd1015363@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11430 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 00:22:23 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=177 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 16:22 ------- Agreed, it's not good to suggest that 403 was defined specifically for PROPFIND. Suggested text to fix this intro: This section, as with similar sections for other methods, provides some guidance on error codes and preconditions or postconditions (defined in Section 15) that might be particularly useful with PROPFIND. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Fri Dec 30 19:27:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUau-0000b3-8Y for webdav-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:27:37 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04824 for ; Fri, 30 Dec 2005 19:26:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsUaE-0004H0-Cg for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 00:26:54 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsUaA-0004Fq-H2 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 00:26:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsUa7-00077Z-S8 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 00:26:49 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBV0QlnG015384; Fri, 30 Dec 2005 16:26:47 -0800 Date: Fri, 30 Dec 2005 16:26:47 -0800 Message-Id: <200512310026.jBV0QlnG015384@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsUa7-00077Z-S8 33af3ee72e9a1cdc6d41d856ca451e8e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 176] Etag requirements (unchanged body for resource) X-Archived-At: http://www.w3.org/mid/200512310026.jBV0QlnG015384@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11431 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 00:26:54 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=176 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From lisa@osafoundation.org 2005-12-30 16:26 ------- Ok, how about this " Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged body and location. " ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:38:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ese8S-00009n-HA for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:38:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24812 for ; Sat, 31 Dec 2005 05:37:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ese6Z-00063T-Fn for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:36:55 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ese6M-00062E-Qc for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:36:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ese5y-0008QO-N6 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:36:41 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVAaI0g016086; Sat, 31 Dec 2005 02:36:18 -0800 Date: Sat, 31 Dec 2005 02:36:18 -0800 Message-Id: <200512311036.jBVAaI0g016086@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ese5y-0008QO-N6 b0b164b725717ed5cf68f7f61298d033 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 176] Etag requirements (unchanged body for resource) X-Archived-At: http://www.w3.org/mid/200512311036.jBVAaI0g016086@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11433 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:36:55 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=176 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 02:36 ------- That's much better. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:38:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ese8S-00009o-H8 for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:38:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24811 for ; Sat, 31 Dec 2005 05:37:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Ese6S-00062y-U9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:36:48 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Ese6H-00061O-9X for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:36:37 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Ese5r-0008IS-7O for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:36:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVAa8B9016074; Sat, 31 Dec 2005 02:36:08 -0800 Date: Sat, 31 Dec 2005 02:36:08 -0800 Message-Id: <200512311036.jBVAa8B9016074@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Ese5r-0008IS-7O 3562a728b6cdcaa6d7cd5dcaaf38956d X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 177] "PROPFIND status codes" section X-Archived-At: http://www.w3.org/mid/200512311036.jBVAa8B9016074@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11432 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:36:48 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=177 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 02:36 ------- As far as I can tell, this would only address some of the concerns raised with this issue. I may be wrong, but it's hard to tell without seeing the complete new text for that subsection. Specifically note that 12.4 () is misleading in saying: "Section 8.3.1, Section 8.2.2, Section 8.7.1, Section 8.9.3 and Section 8.10.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses." That makes it sound as if it's necessary for this spec to define the meanings. It's not. In general, the meaning of any status code inside a multistatus body is defined by the spec that defines that status. Minimally, the paragraph should be altered to something like... "Section 8.3.1, Section 8.2.2, Section 8.7.1, Section 8.9.3 and Section 8.10.2 explain the use of various status codes used in Multi-Status responses." ...optimally, it would get removed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:44:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseDc-0001Hv-Pc for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:44:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25341 for ; Sat, 31 Dec 2005 05:43:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EseD0-0006vL-Fr for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:43:34 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EseCx-0006ug-3K for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:43:31 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EseCg-0003ko-Bm for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:43:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVAhEP8016115; Sat, 31 Dec 2005 02:43:14 -0800 Date: Sat, 31 Dec 2005 02:43:14 -0800 Message-Id: <200512311043.jBVAhEP8016115@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EseCg-0003ko-Bm d8b97d10106ed26ea38d6ba9f394a3eb X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 184] Clarifications requested for section 19.8 on hosting malicious content X-Archived-At: http://www.w3.org/mid/200512311043.jBVAhEP8016115@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11434 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:43:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=184 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 02:43 ------- The new summary does not reflect what I was asking for when I opened the bug - as far as I can tell, this section should not be in at all, unless there's *both* consensus that have it at all, and the potential problems with the text are fixed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:47:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseGP-0001Ui-2B for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:47:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25648 for ; Sat, 31 Dec 2005 05:45:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EseFk-0008NO-Ks for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:46:24 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EseFh-0008Mq-JE for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:46:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EseAW-0000oZ-JT for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:46:18 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVAekhM016101; Sat, 31 Dec 2005 02:40:46 -0800 Date: Sat, 31 Dec 2005 02:40:46 -0800 Message-Id: <200512311040.jBVAekhM016101@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EseAW-0000oZ-JT 16b393ea7d6a0a22d26904efdc85b34e X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 179] DAV:no-lock X-Archived-At: http://www.w3.org/mid/200512311040.jBVAekhM016101@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11435 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:46:24 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 02:40 ------- (now in ) I still that this is the incorrect approach. Don't use RFC2119 keywords for stuff that is a consequence from other requirements. Just explain why it follows (if you feel that's necessary), but don't claim it's a requirement on it's own, because that may confuse people to think that DAV:no-lock is special and different from something like DAV:this-is-really-a-locktoken. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:54:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseNG-0003Tx-M7 for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:54:12 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26105 for ; Sat, 31 Dec 2005 05:52:58 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EseMc-0000mm-QT for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:53:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EseMZ-0000mD-SC for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:53:27 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.50) id 1EseMX-0002Vf-1n for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:53:27 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBVArMmX028652 for ; Sat, 31 Dec 2005 05:53:22 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBVArMRN123814 for ; Sat, 31 Dec 2005 05:53:22 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jBVArMDU024365 for ; Sat, 31 Dec 2005 05:53:22 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jBVArMRK024362 for ; Sat, 31 Dec 2005 05:53:22 -0500 In-Reply-To: <200512311040.jBVAekhM016101@ietf.cse.ucsc.edu> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Sat, 31 Dec 2005 05:53:47 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/31/2005 05:53:21, Serialize complete at 12/31/2005 05:53:21 Content-Type: multipart/alternative; boundary="=_alternative 003BDB39852570E8_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EseMX-0002Vf-1n 5f8a8195a6fa7e455091073fe3216927 X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 179] DAV:no-lock X-Archived-At: http://www.w3.org/mid/OF0B723FF9.DEDB2614-ON852570E8.003BCEEE-852570E8.003BDBAD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11436 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:53:30 +0000 This is a multipart message in MIME format. --=_alternative 003BDB39852570E8_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian. Cheers, Geoff Julian wrote on 12/31/2005 05:40:46 AM: > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179 > > julian.reschke@greenbytes.de changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |REOPENED > Resolution|FIXED | > Version|-08 |-09 > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-12-31 02:40 ------- > (now in > html#rfc.section.9.5.4.p.4>) > > I still that this is the incorrect approach. Don't use RFC2119 keywords for > stuff that is a consequence from other requirements. Just explain > why it follows > (if you feel that's necessary), but don't claim it's a requirement > on it's own, > because that may confuse people to think that DAV:no-lock is special and > different from something like DAV:this-is-really-a-locktoken. > > > > > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > --=_alternative 003BDB39852570E8_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian.

Cheers,
Geoff

Julian wrote on 12/31/2005 05:40:46 AM:

>
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=179
>
> julian.reschke@greenbytes.de changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|FIXED                       |
>             Version|-08                         |-09
>
>
>
> ------- Additional Comments From julian.reschke@greenbytes.de  
> 2005-12-31 02:40 -------
> (now in
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.
> html#rfc.section.9.5.4.p.4>)
>
> I still that this is the incorrect approach. Don't use RFC2119 keywords for
> stuff that is a consequence from other requirements. Just explain
> why it follows
> (if you feel that's necessary), but don't claim it's a requirement
> on it's own,
> because that may confuse people to think that DAV:no-lock is special and
> different from something like DAV:this-is-really-a-locktoken.
>
>
>
>
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug, or are watching the QA contact.
>
--=_alternative 003BDB39852570E8_=-- From w3c-dist-auth-request@frink.w3.org Sat Dec 31 05:58:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseRd-0004Aj-Uy for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 05:58:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26448 for ; Sat, 31 Dec 2005 05:57:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EseR5-0001Ws-Ev for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 10:58:07 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EseR2-0001WA-0B for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 10:58:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EseQi-0005Q6-Hf for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 10:58:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVAviwM016130; Sat, 31 Dec 2005 02:57:44 -0800 Date: Sat, 31 Dec 2005 02:57:44 -0800 Message-Id: <200512311057.jBVAviwM016130@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EseQi-0005Q6-Hf af523d27f1f34722db9cddbadfd572f0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512311057.jBVAviwM016130@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11437 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 10:58:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 02:57 ------- > I can't follow the reasons for all the changes in that document, so it's hard > for me to tell what your (Julian's) intent is with the changes. I don't like > having all the normative text in section 8.1.5 -- that section was intended to > be an introduction to the topic and has gotten out of hand. I'd like to leave > that as an introduction because section 8.1 is already a large enough digression > from the actual methods we discuss in the rest of section 8. Other comments: If we use preconditions in the subsequent subsections, I believe it would be better to have the concept explained completely fully in advance. > - This text proposed is inconsistent with issues you've raised before, with > regards to making 403 and 409 the only allowed error codes. I'm not sure what you're referring to. The text says If a method precondition or postcondition for a request is not satisfied and unless specified explicitly otherwise, the response status of the request MUST be either 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request. which I think reflects WG consensus (the status will be 403 or 409, unless the spec explicitly says something else). > - the last paragraph in your proposal for section 8.1.5 is redundant with > earlier text In this specification, both the HTTP status code and the condition name are defined for some failure situations, in which case the XML condition element is in the "DAV:" namespace, appears in the "error" root element, and SHOULD be returned in a body with the specified numeric HTTP status code. Of this, only the last two parts seem redundant. Feel free to strip those. > - Some of the changes (e.g. in section 8.2) are unrelated to this issue They are related, in that the spec mades inocrrect statements about depth: infinity requirements for PROPFIND. Should I open a separate bug for that? > - The guidance on creating one's own error codes was seemingly removed Redundant wording (you don't like that as well, right?) was removed. The proposed text still says: However, it does remove the need to define new numeric error codes. The machine-readable codes used for this purpose are XML elements classified as preconditions and postconditions. As always, the "DAV:" namespace is reserved for use by IETF-chartered WebDAV working groups. > - Some of the error code sections (from 8.2 to 8.12) were reorganized but > others remained organized differently. I haven't adopted these changes, is > there some reason for them? I'd like them to be consistent. I may have not catched all variations. Should we open a separate ticket? > - I don't agree that we should list the preconditions/postconditions without > suggesting what status code to use with. I find the formatting I've been using > clearer than that of the proposed change. IMHO the definition of the condition is independant of a suggested status code. When specific method descriptions recommend a specific status code to use them with, that's fine. Having it in both places seems like a bad idea. > I'm making a number of modifications to the draft based on these proposals but > I'm sure we'll have to iterate. Yes. As a matter of fact, it would be nice if people could comment on the proposal as is, so that the editor has some indication about how to proceed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 06:07:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseZx-0005tB-Kf for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 06:07:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27441 for ; Sat, 31 Dec 2005 06:06:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EseZL-0003fk-3z for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 11:06:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EseZH-0003en-8m for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 11:06:35 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1EseZE-0006ca-Mn for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 11:06:34 +0000 Received: (qmail invoked by alias); 31 Dec 2005 10:59:49 -0000 Received: from p508FB3D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.216] by mail.gmx.net (mp020) with SMTP; 31 Dec 2005 11:59:49 +0100 X-Authenticated: #1915285 Message-ID: <43B66442.6080800@gmx.de> Date: Sat, 31 Dec 2005 11:58:10 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault CC: Barry Lind , WebDav References: <43882769.5010500@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1EseZE-0006ca-Mn 90da1891613316d31a7f460e0a13ee74 X-Original-To: w3c-dist-auth@w3.org Subject: Re: New Security considerations X-Archived-At: http://www.w3.org/mid/43B66442.6080800@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11438 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 11:06:39 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Barry, can you provide more info or pointers on how a script can read > another user's cookies? > > Aside from that point of confusion, Julian, it sounds like you have some > ways to improve this section, but I'm not sure which way you propose to > go (e.g. whether the discussion of arbitrary content needs to be > expanded or other). Can you make a concrete proposal? My concrete proposal is not to have that section at all. If it's going to stay, it will need more review as it is relevant to Security. Getting things wrong or even confusing here seems to be worse than not saying anything at all. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Dec 31 07:04:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsfTe-0008C0-Ij for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 07:04:50 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02335 for ; Sat, 31 Dec 2005 07:03:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsfSM-0005yQ-EA for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 12:03:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsfSC-0005xC-O4 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 12:03:20 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1EsfSA-0007Wi-16 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 12:03:20 +0000 Received: (qmail invoked by alias); 31 Dec 2005 12:03:15 -0000 Received: from p508FB3D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.216] by mail.gmx.net (mp033) with SMTP; 31 Dec 2005 13:03:15 +0100 X-Authenticated: #1915285 Message-ID: <43B67321.3080908@gmx.de> Date: Sat, 31 Dec 2005 13:01:37 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EsfSA-0007Wi-16 29cd7b3a6e66250974382edfc80a2c39 X-Original-To: w3c-dist-auth@w3.org Subject: Re-using 414 status codes (related to Bug 31) X-Archived-At: http://www.w3.org/mid/43B67321.3080908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11439 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 12:03:30 +0000 Content-Transfer-Encoding: 7bit Hi, (see also ). In Section 11.2, draft 09 of RFC2518bis currently says (): 11.2 414 Request-URI Too Long This status code is used in HTTP 1.1 only for Request-URIs, because full URIs aren't used in other headers. WebDAV specifies full URLs in other headers, therefore this error MAY be used if the URI is too long in other locations as well. I note that this statement is non-compliant to RFC2616 (which says that 414 is just for the case where a Request-URI is too long, that's it). The only good reason for being inconsistent with RFC2616 would be if this would be documenting existing practice that can't easily be fixed. So is anybody aware of servers that do this? In our last conference call, we also discussed that although this problem may be nothing a user agent can fix automatically, it nevertheless may be good if it could display a meaningful error message to the user. To go forward, there seem to be at least three choices: 1) Remove that paragraph, thus be silent on what servers return in this case, which in general would mean 400 Bad Request. This is consistent with RFC2616, but doesn't give clients a mean of detecting this error condition. 2) Keep Section 11.2 (being inconsistent with RFC2616) 3) Define a precondition code that could be used with status 400, and which would allow not only to describe the general problem, but also could include the URI that was actually causing the problem (keep in mind that URIs can appear in several places in the request headers, such as "Destination" and Tagged-Lists in "If"). The exact proposal for this is below. Feedback appreciated, mine would be: 1) +.5 2) -1 (because of inconsistency with RFC2616) 3) +.5 (it doesn't hurt) Feedback appreciated, Julian -- proposal for precondition code -- 15.7 DAV:uri-reference-length-within-limits (precondition) Servers MAY restrict the length of URI references in certain header fields, such as "Destination" or "If". This condition code can be used to signal this condition, and also to include the actual URI reference causing the problem. User agents may be able to take advantage of this to display a meaningful error message to the user. Servers SHOULD insert DAV:href elements for the URI reference(s) that caused the problem. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 07:11:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsfZt-0000Uy-9M for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 07:11:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02871 for ; Sat, 31 Dec 2005 07:10:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsfZH-0007CB-Br for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 12:10:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsfZD-0007BY-G5 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 12:10:35 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1EsfZA-0001Je-PS for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 12:10:34 +0000 Received: (qmail invoked by alias); 31 Dec 2005 12:10:29 -0000 Received: from p508FB3D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.216] by mail.gmx.net (mp020) with SMTP; 31 Dec 2005 13:10:29 +0100 X-Authenticated: #1915285 Message-ID: <43B674D3.1060204@gmx.de> Date: Sat, 31 Dec 2005 13:08:51 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1EsfZA-0001Je-PS 8acec802e3aaee98d62dc7971d202547 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Question on GULP - properties defined as lockable, and content of a resource X-Archived-At: http://www.w3.org/mid/43B674D3.1060204@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11440 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 12:10:39 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Looking carefully at the text of GULP from > : > > - If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or an internal member URI of a > locked collection, the request MUST fail unless the lock-token for > that lock is submitted in the request. An internal member URI > of a collection is considered to be modified if it is added, > removed, or identifies a different resource. > > > I see two problems with this paragraph > - The content of a resource is not defined anywhere. Should this be > rewritten as "any variant" in order to consistently use RFC2616 > terminology? > - The phrase "a live property that is defined to be lockable" implies > that we define properties to be lockable, but we don't. Any suggestions > for fixing this? > > One simplifying possibility is that if the request would modify *any* > live property, the lock token is required. However I'm concerned that > there are some calculated live properties for which that would be > undesirable. For example, if a resource had a live property called > "last-copied-to", and a COPY of that locked resource to some other > location caused the server to change the value of that live property to > the copy destination, then we wouldn't want to require the lock-token of > the source just because of that live property. > > As a strawman, here's a proposed rewrite of the para, including minor > rewording/rearrangement for readability: > > "A lock-token must be submitted in a request if that request would > modify any of the following aspects of a locked resource: > - any variant, > - any dead property, > - any live property (unless otherwise specified for that property), > - for a collection, an internal member URI. > An internal member URI of a collection is considered to be modified > if it is added, removed, or identifies a different resource." That's ok, except for a) we lost the MUST here (and this is a place where it's really needed), and b) we then also have to think about which live properties defined in RFC2518bis are not lockable (note that it's probably wise to keep that terminology); DAV:lockdiscovery comes to mind. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Dec 31 07:48:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsgAF-0008PX-GE for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 07:48:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06968 for ; Sat, 31 Dec 2005 07:47:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Esg9J-0006O7-CX for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 12:47:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Esg98-0006Mk-So for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 12:47:43 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Esg94-0004Mt-4Z for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 12:47:42 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVClYLX016418; Sat, 31 Dec 2005 04:47:34 -0800 Date: Sat, 31 Dec 2005 04:47:34 -0800 Message-Id: <200512311247.jBVClYLX016418@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Esg94-0004Mt-4Z 3f40a0b6adbd1de445b183c8c20fc649 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512311247.jBVClYLX016418@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11441 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 12:47:53 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Status|ASSIGNED |NEW Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 04:47 ------- Here's the full set of differences ("OLD" is draft-ietf-rfc2518bis-09, "NEW" is the text I have proposed in November, and that we've been discussing on the mailing list). (also re-assigning to Elias for next conference call) Section 4., para. 18: OLD: A property is always represented in XML with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: NEW: A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist: (note the redundant "...in XML..." -- is there another way to represent a property that the spec describes?) Section 4., para. 19: OLD: NEW: (this is about the simplest possible property, and adding a namespace prefix here IMHO is just confusing) Section 4., para. 20: OLD: The value of a property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. In the latter case, servers MUST preserve certain aspects of the content (described using the terminology from [W3C.REC-xml-infoset-20040204]). NEW: The value of the property appears inside the property name element. It may be any kind of well-formed XML content, including both text- only and mixed content. In the latter case, servers MUST preserve certain aspects of the content. Using the terminology from [REC-XML- INFOSET], the following rules apply: (I think "The value of *the* property..." is better here, because this is a continuation from the previous section; also even to a non-native english speaker having two sentences start with the same words looks bad (why this change???) Section 4., para. 22: OLD: [namespace name] [local name] [attributes] named "xml:lang" or any such attribute in scope [children] of type element or character NEW: [namespace name], [local name], [attributes] named "xml:lang" or any such attribute in scope, [children] of type element or character. (Punctuation) Section 4., para. 24: OLD: On all Element Information Items in the value: [namespace name] [local name] [attributes] [children] of type element or character NEW: On all Element Information Items that are descendants of the property name element: [namespace name], [local name], [attributes] and [children] of type element or character. (Editorial) Section 4., para. 29: OLD: On Attribute Information Items in the value: [namespace name] [local name] [normalized value] NEW: On Attribute Information Items: [namespace name], [local name] and [normalized value]. (Punctuation; also "in the value" doesn't seem to be precise to me, what does "in" mean?) Section 4., para. 33: OLD: On Character Information Items in the value: [character code] NEW: On Character Information Items: [character code]. Again, what does "in the value" mean here? Are there Character Information Items "outside" the value? Section 4., para. 35: OLD: Since prefixes are used in some XML query/handling tools, servers SHOULD preserve, for any Information Item in the value: [prefix] NEW: Future revisions of this specification may also require to preserve namespace prefixes for child elements of the property name elements, thus servers SHOULD preserve the [prefix] as well. [[preserve.more.xml: Feedback if we should ask implementors to preserve more in the future is appreciated (such as comments).]] (I do not object to changing the language here, but "..are used in some XML query/handling tools..." certainly doesn't help explaining the issue) Section 4., para. 37: OLD: In dead properties (considered as content, like document bodies) servers are encouraged to (MAY) preserve, for any Comment Information Item in the value: [content] NEW: (remove this; servers MAY preserve whatever they want; the introduction of a distinction between dead and live properties doesn't make things clearer) Section 4., para. 39: OLD: The XML attribute xml:space MUST NOT be used to change white space handling. White space in property values is significant. NEW: Also note that whitespace inside values is always significant, and that servers MUST NOT support overriding this using the xml:space attribute. (This is almost the same. The "OLD" text seems to make a PROPPATCH with xml:space="preserve" illegal, while the "NEW" text tells servers to ignore it should it be there; I think the latter more accurately reflects WG consensus). Section 4., para. 42: OLD: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of ]]>. NEW: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of ]]>. (these seem to be identical except for whitespace between attributes) Section 4., para. 43: OLD: When this property is requested, a server might return: NEW: When retrieving the property, a server may return: (don't care) Section 4., para. 44: OLD: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of <RFC2518>. Note in this example: NEW: Jane Doe mailto:jane.doe@example.com http://www.example.com Jane has been working way too long on the long-awaited revision of <RFC2518>. Note: (the "OLD" example is broken in at least three ways: (1) amount of whitespace in property value changed, (2) parse errors (mismatched start/end tags), (3) usage of undefined namespace prefix; as a general comment: if people start editing carefully crafted XML examples, please run them through an XML parser afterwards). Section 4., para. 45: OLD: o The [prefix] for the property name itself was not preserved, being non-significant NEW: o The [prefix] for the property name itself was not preserved, being non-significant, (Punctuation) Section 4., para. 48: OLD: o whitespace between tags has been preserved everywhere (whitespace between attributes not so), o CDATA encapsulation was replaced with character escaping (the reverse would also be legal), NEW: o the [prefix] has been preserved on the child element "notes", o whitespace between tags has been preserved everywhere (but the fact that CDATA escaping was used is irrelevant), and (note the absense of the statement about prefix preservation in "OLD", the remainder seems to be editorial) Section 4., para. 51: OLD: Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character-by- character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing. NEW: Implementation note: There are cases such as editing scenarios where clients may require that XML content is preserved character-by-character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing. (Indentation) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 07:52:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsgDx-0000nG-3a for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 07:52:41 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07352 for ; Sat, 31 Dec 2005 07:51:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsgDP-00079j-5A for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 12:52:07 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsgDL-000790-67 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 12:52:03 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EsgDI-0005c7-Mi for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 12:52:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVCpxjF016441; Sat, 31 Dec 2005 04:51:59 -0800 Date: Sat, 31 Dec 2005 04:51:59 -0800 Message-Id: <200512311251.jBVCpxjF016441@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EsgDI-0005c7-Mi 177cddc597bb07af5d3a92e476d528b9 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 10] Round-tripping various information in properties X-Archived-At: http://www.w3.org/mid/200512311251.jBVCpxjF016441@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11442 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 12:52:07 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 04:51 ------- Also, draft-ietf-rfc2518bis-09 has the Infoset reference listes as "informative". It is normative. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 08:03:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsgOj-0002zW-I6 for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 08:03:51 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09067 for ; Sat, 31 Dec 2005 08:02:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsgO3-0001UP-Dj for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 13:03:07 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsgNy-0001Tk-5Z for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 13:03:02 +0000 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by aji.w3.org with smtp (Exim 4.50) id 1EsgNr-0006o5-3R for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 13:03:01 +0000 Received: (qmail invoked by alias); 31 Dec 2005 12:56:09 -0000 Received: from p508FB3D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.216] by mail.gmx.net (mp039) with SMTP; 31 Dec 2005 13:56:09 +0100 X-Authenticated: #1915285 Message-ID: <43B67F85.4020104@gmx.de> Date: Sat, 31 Dec 2005 13:54:29 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Desruisseaux CC: webdav WG , briank@networkresonance.com, Lisa Dusseault References: <43979C55.9040408@oracle.com> In-Reply-To: <43979C55.9040408@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (aji.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsgNr-0006o5-3R 7117dc3379b0df8cf4608da099ced08d X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-ietf-webdav-quota-07.txt: DAV:quota-not-exceeded X-Archived-At: http://www.w3.org/mid/43B67F85.4020104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11443 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 13:03:07 +0000 Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > In Section 6. Error reporting shouldn't DAV:quota-not-exceeded be a > postcondition instead of a precondition? Yes, I think so. Alternatively, the definition could be rewritten so that it becomes a precondition. Lisa, Brian? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sat Dec 31 10:46:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esivl-0001GB-Lo for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 10:46:05 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22510 for ; Sat, 31 Dec 2005 10:44:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsiuK-0006aB-DQ for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 15:44:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Esiu5-0006Yh-Am for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 15:44:21 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Esiu1-0007KY-8W for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 15:44:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVFiEet016599; Sat, 31 Dec 2005 07:44:14 -0800 Date: Sat, 31 Dec 2005 07:44:14 -0800 Message-Id: <200512311544.jBVFiEet016599@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Esiu1-0007KY-8W 65d86823c0ee061cc5cad8329266313f X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 121] OVERWRITE_DELETE_ERROR_STATUS X-Archived-At: http://www.w3.org/mid/200512311544.jBVFiEet016599@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11444 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 15:44:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=121 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Version|-07 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 07:44 ------- Re-assigning to Elias to schedule discussion in conference call. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 10:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esivy-0001IS-NY for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 10:46:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22528 for ; Sat, 31 Dec 2005 10:45:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsivR-0007uc-4x for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 15:45:45 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsivJ-0007t8-S1 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 15:45:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EsivH-0007h5-00 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 15:45:36 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVFjYN4016615; Sat, 31 Dec 2005 07:45:34 -0800 Date: Sat, 31 Dec 2005 07:45:34 -0800 Message-Id: <200512311545.jBVFjYN4016615@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EsivH-0007h5-00 81c471d901905065af760732e8478e90 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 147] CLARIFY_UNTAGGED_IF_HEADER_APPLICATION X-Archived-At: http://www.w3.org/mid/200512311545.jBVFjYN4016615@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11445 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 15:45:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 07:45 ------- Re-assigning to Elias to schedule discussion in conference call. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 10:47:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esiwn-0001hr-8X for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 10:47:09 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22582 for ; Sat, 31 Dec 2005 10:45:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsiwF-000851-2z for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 15:46:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EsiwA-00083W-P6 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 15:46:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Esivt-0002k2-Jk for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 15:46:30 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVFkBqe016631; Sat, 31 Dec 2005 07:46:11 -0800 Date: Sat, 31 Dec 2005 07:46:11 -0800 Message-Id: <200512311546.jBVFkBqe016631@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Esivt-0002k2-Jk 645a3a3fab8786a9945e456a910d1387 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed X-Archived-At: http://www.w3.org/mid/200512311546.jBVFkBqe016631@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11446 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 15:46:35 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Status|ASSIGNED |NEW Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 07:46 ------- Re-assigning to Elias to schedule discussion in conference call. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 10:48:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esixt-0001nU-3V for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 10:48:17 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22693 for ; Sat, 31 Dec 2005 10:47:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsixL-0008Fv-4W for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 15:47:43 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsixG-0008Er-OA for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 15:47:38 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EsixE-0005NH-2D for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 15:47:38 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVFlYDv016651; Sat, 31 Dec 2005 07:47:34 -0800 Date: Sat, 31 Dec 2005 07:47:34 -0800 Message-Id: <200512311547.jBVFlYDv016651@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EsixE-0005NH-2D 53c10fce02fae96db2a9e119302c6c03 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 124] REPORT_OTHER_RESOURCE_LOCKED X-Archived-At: http://www.w3.org/mid/200512311547.jBVFlYDv016651@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11447 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 15:47:43 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=124 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |w3c-dist-auth@w3.org ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 10:49:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esiys-00023V-Eh for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 10:49:18 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22769 for ; Sat, 31 Dec 2005 10:48:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsiyF-0008ON-Aq for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 15:48:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EsiyB-0008Ne-7x for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 15:48:35 +0000 Received: from mail.gmx.net ([213.165.64.21]) by maggie.w3.org with smtp (Exim 4.50) id 1Esiy8-0005ek-NJ for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 15:48:34 +0000 Received: (qmail invoked by alias); 31 Dec 2005 15:48:31 -0000 Received: from p508FB3D8.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.179.216] by mail.gmx.net (mp020) with SMTP; 31 Dec 2005 16:48:31 +0100 X-Authenticated: #1915285 Message-ID: <43B6A7E2.40809@gmx.de> Date: Sat, 31 Dec 2005 16:46:42 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <200512311547.jBVFlYDv016651@ietf.cse.ucsc.edu> In-Reply-To: <200512311547.jBVFlYDv016651@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (maggie.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.21 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Esiy8-0005ek-NJ 1a404dfd7997500f2ef5eaef2a6956ce X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 124] REPORT_OTHER_RESOURCE_LOCKED X-Archived-At: http://www.w3.org/mid/43B6A7E2.40809@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11448 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 15:48:39 +0000 Content-Transfer-Encoding: 7bit Proposed changes in (reassigning to Elias to schedule discussion in conference call) In particular: Section 7., para. 71: OLD: If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'lock-token-present' precondition. NEW: If a depth-infinity write LOCK request is issued to a collection containing member URLs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code, and the response SHOULD contain the 'no-conflicting-lock' (Section 15.7) precondition. Section 8., para. 271: OLD: 423 (Locked) - The resource is locked already. NEW: 423 (Locked), potentially with 'no-conflicting-lock' (Section 15.7) precondition code - There is already a lock on the resource which is not compatible with the requested lock (see lock compatibility table above). Section 10., para. 7: OLD: The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain the 'lock-token- present' precondition element and corresponding 'href' in the error body. NEW: The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition code, such as 'lock-token-present' (Section 15.6) or 'no-conflicting-lock' (Section 15.7). NEW: 15.7 DAV:no-conflicting-lock (precondition) This precondition code can be used to signal that a lock request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which the request was directed is only indirectly locked. In this case, the precondition code can be used to inform the client about the resource which is the root of the conflicting lock, avoiding a separate lookup of the "lockdiscovery" property. [[anchor103: Make sure the document actually defines "indirectly locked".]] Servers SHOULD insert a DAV:href element for the URL of the root of the conflicting lock. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 12:23:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EskSL-0004vw-NU for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 12:23:49 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29843 for ; Sat, 31 Dec 2005 12:22:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EskRA-0002de-JK for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 17:22:36 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EskQy-0002bo-Ox for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 17:22:25 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EskQf-00055C-PE for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 17:22:23 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVHM30H017476; Sat, 31 Dec 2005 09:22:03 -0800 Date: Sat, 31 Dec 2005 09:22:03 -0800 Message-Id: <200512311722.jBVHM30H017476@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EskQf-00055C-PE f882e3ac1ddd139f33c2fa1341f6b632 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200512311722.jBVHM30H017476@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11449 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 17:22:36 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-09 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:12:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EslDX-0006fF-L6 for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:12:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03459 for ; Sat, 31 Dec 2005 13:11:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EslCb-0006jB-GG for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:11:37 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EslCM-0006hc-D1 for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:11:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EslCJ-0001uq-RB for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:11:21 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIBIEX017519; Sat, 31 Dec 2005 10:11:18 -0800 Date: Sat, 31 Dec 2005 10:11:18 -0800 Message-Id: <200512311811.jBVIBIEX017519@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EslCJ-0001uq-RB 51c0251b87a65c1486e63885b088fa50 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 181] error element X-Archived-At: http://www.w3.org/mid/200512311811.jBVIBIEX017519@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11450 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:11:37 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-12-31 10:11 ------- I agree with Julian's responses. I liked Julian's text, and suggest that it be adopted verbatim (removing the redundant clauses in 8.1.5 is fine). In particular, it should be adopted verbatim unless there is consensus that there is a problem with something in it (following the general rule that if a co- author produces text, it should be adopted by the editor, unless there is a problem with it). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:19:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EslKO-0007yu-1c for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:19:40 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03908 for ; Sat, 31 Dec 2005 13:18:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EslJn-0008RE-86 for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:19:03 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1EslJj-0008QX-Kd for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:18:59 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1EslJg-00016d-Ij for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:18:59 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIItC6017534; Sat, 31 Dec 2005 10:18:55 -0800 Date: Sat, 31 Dec 2005 10:18:55 -0800 Message-Id: <200512311818.jBVIItC6017534@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1EslJg-00016d-Ij 5ff05cefe6f5a739a8b5e15ee63acab0 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 80] Specify idempotence and safeness for all new methods X-Archived-At: http://www.w3.org/mid/200512311818.jBVIItC6017534@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11451 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:19:03 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 10:18 ------- Reassigning to Elias for schedule in conference call. See also . For the proposed changes, please follow links from . In particular: Section 8., para. 45: OLD: The results of this method SHOULD NOT be cached. NEW: The results of this method SHOULD NOT be cached. This method is both safe and idempotent (see Section 9.1 of [RFC2616]). Section 8., para. 90: OLD: 8.3.1 Status Codes for use in 207 (Multi-Status) NEW: This method is not safe, but idempotent (see Section 9.1 of [RFC2616]). 8.3.1 Status Codes for use in 207 (Multi-Status) Section 8., para. 110: OLD: 8.4.1 MKCOL Status Codes NEW: Responses from a MKCOL request MUST NOT be cached. [[anchor28: Now that we clarify that MKCOL indeed is idempotent, does this change our position about result cacheability???]] This method is not safe, but idempotent (see Section 9.1 of [RFC2616]). 8.4.1 MKCOL Status Codes Section 8., para. 111: OLD: Responses from a MKCOL request MUST NOT be cached as MKCOL has non- idempotent semantics. In addition to the general status codes possible, the following status codes have specific applicability to MKCOL: NEW: In addition to the general status codes possible, the following status codes have specific applicability to MKCOL: Section 8., para. 160: OLD: 8.9.1 COPY for Non-collection Resources NEW: This method is not safe, but idempotent (see Section 9.1 of [RFC2616]). 8.9.1 COPY for Non-collection Resources Section 8., para. 215: OLD: 8.10.1 MOVE for Properties NEW: This method is not safe, but idempotent (see Section 9.1 of [RFC2616]). 8.10.1 MOVE for Properties Section 8., para. 259: OLD: 8.11.1 Refreshing Locks NEW: This method is neither safe, nor idempotent (see Section 9.1 of [RFC2616]). 8.11.1 Refreshing Locks Section 8., para. 315: OLD: 8.12.1 Status Codes NEW: This method is not safe, but idempotent (see Section 9.1 of [RFC2616]). 8.12.1 Status Codes ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:33:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EslY9-0002UO-Kx for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:33:53 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05016 for ; Sat, 31 Dec 2005 13:32:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EslXE-0003al-Rg for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:32:56 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1EslXA-0003a6-GN for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:32:52 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1EslX7-0007Ge-17 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:32:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIWh1a017556; Sat, 31 Dec 2005 10:32:43 -0800 Date: Sat, 31 Dec 2005 10:32:43 -0800 Message-Id: <200512311832.jBVIWh1a017556@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1EslX7-0007Ge-17 ed1a37d5e4c2600138d41b133733ab22 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 211] New: Inconsistencies about Destination header X-Archived-At: http://www.w3.org/mid/200512311832.jBVIWh1a017556@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11452 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:32:56 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=211 Summary: Inconsistencies about Destination header Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.9.3 OS/Version: other Status: NEW Severity: major Priority: P2 Component: 09. HTTP Headers for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org CC: w3c-dist-auth@w3.org I find the changes regarding the Destination header confusing. 1) In the Changes section, the spec claims... "Tightened requirement for "Destination:" header to work with path values" () Then later...: "Removed ability for Destination header to take "abs_path" in order to keep consistent with other places where client provides URLs (If header, href element in request body)" () As a matter of fact, the Destination header in RFC2518 already was defined as being an "absoluteURI" (). RFC2518bis still says "absolute-URI" (this is an update from RFC2396 to RFC3986), but then says: "If the Destination value is an absolute URI, it may name a different server (or different port or scheme). If the source server cannot attempt a copy to the remote server, it MUST fail the request with a 502 (Bad Gateway) response." (). As written this is confusing because the Destination header always is an absolute URI. Please clarify what the intended change is, remove the confusing language, and fix the Changes section accordingly (if necessary). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:39:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esldr-0003du-PR for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:39:47 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05374 for ; Sat, 31 Dec 2005 13:38:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1EsldE-0004Sk-50 for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:39:08 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1EsldA-0004SA-SG for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:39:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1Eslcm-0003s2-Tx for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:39:03 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIcca1017581; Sat, 31 Dec 2005 10:38:38 -0800 Date: Sat, 31 Dec 2005 10:38:38 -0800 Message-Id: <200512311838.jBVIcca1017581@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1Eslcm-0003s2-Tx 5367da5a09a1a1630aed88ea4622eb16 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 202] Move description of lock-null resources into appendix X-Archived-At: http://www.w3.org/mid/200512311838.jBVIcca1017581@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11453 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:39:08 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|-08 |-09 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 10:38 ------- The text is still confusing, in particular the Changes section claims ()... "Replaced lock-null resources with simpler locked empty resources. Lock-null resources are now not compliant with the requirements in this specification." It seems to me that this needs further discussion, both in what we say, and how we say it. I'd suggest that we define locking on unmapped resources in a way so that old servers simply happen to be compliant with it, while new servers can be simplified. This would save us from discussing to separate models. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:44:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eslic-0004QI-8R for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:44:42 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05606 for ; Sat, 31 Dec 2005 13:43:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eslhx-0005WI-JX for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:44:01 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eslhp-0005UA-Lk for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:43:53 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EslhS-0007N9-BF for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:43:51 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIhGsx017610; Sat, 31 Dec 2005 10:43:16 -0800 Date: Sat, 31 Dec 2005 10:43:16 -0800 Message-Id: <200512311843.jBVIhGsx017610@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact CC Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EslhS-0007N9-BF 5ddada60a9996c7a712f4f0703c3b285 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 213] New: Spec inconsistent on PROPFIND/Depth:infinity X-Archived-At: http://www.w3.org/mid/200512311843.jBVIhGsx017610@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11454 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:44:01 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213 Summary: Spec inconsistent on PROPFIND/Depth:infinity Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.8.2 OS/Version: other Status: NEW Severity: major Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org CC: w3c-dist-auth@w3.org In Section 8.2: "Servers MUST support the "0", "1" and "infinity" behaviors on WebDAV-compliant resources." In Section 8.2.1: "A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body." And finally, the Changes section doesn't mention this change, although it may be important to clients that may require this feature. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:44:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eslid-0004QU-Fm for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:44:43 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05610 for ; Sat, 31 Dec 2005 13:43:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Esli5-0005XS-Fn for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:44:09 +0000 Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1Eslhq-0005UB-4G for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:43:55 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by aji.w3.org with esmtp (Exim 4.50) id 1EslhS-0007NB-FZ for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:43:52 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIh161017600; Sat, 31 Dec 2005 10:43:01 -0800 Date: Sat, 31 Dec 2005 10:43:01 -0800 Message-Id: <200512311843.jBVIh161017600@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (aji.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: aji.w3.org 1EslhS-0007NB-FZ db2c3033fa0b1234a50b096474051c91 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 212] New: Spec inconsistent on PROPFIND/Depth:infinity X-Archived-At: http://www.w3.org/mid/200512311843.jBVIh161017600@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11455 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:44:09 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=212 Summary: Spec inconsistent on PROPFIND/Depth:infinity Product: WebDAV-RFC2518-bis Version: -09 Platform: Other URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav- rfc2518bis-09.html#rfc.section.8.2 OS/Version: other Status: NEW Severity: major Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org In Section 8.2: "Servers MUST support the "0", "1" and "infinity" behaviors on WebDAV-compliant resources." In Section 8.2.1: "A server MAY reject all PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body." And finally, the Changes section doesn't mention this change, although it may be important to clients that may require this feature. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:45:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsljO-0004XE-FB for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:45:30 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05655 for ; Sat, 31 Dec 2005 13:44:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eslim-0005nX-GU for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:44:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eslih-0005lh-Eb for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:44:47 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eslif-00085O-O6 for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:44:47 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIij3m017632; Sat, 31 Dec 2005 10:44:45 -0800 Date: Sat, 31 Dec 2005 10:44:45 -0800 Message-Id: <200512311844.jBVIij3m017632@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (lisa.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: lisa.w3.org 1Eslif-00085O-O6 82123bec3e627d94ed96e2fb52209898 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 212] Spec inconsistent on PROPFIND/Depth:infinity X-Archived-At: http://www.w3.org/mid/200512311844.jBVIij3m017632@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11456 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:44:52 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=212 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 10:44 ------- (argh - POST is not idempotent :-) *** This bug has been marked as a duplicate of 213 *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 13:45:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsljT-0004Xe-KW for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 13:45:35 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05663 for ; Sat, 31 Dec 2005 13:44:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Esliw-00064U-Nh for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 18:45:02 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Eslij-0005m5-Gm for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 18:44:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by maggie.w3.org with esmtp (Exim 4.50) id 1Eslih-0001jF-2p for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 18:44:48 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id jBVIijWt017642; Sat, 31 Dec 2005 10:44:45 -0800 Date: Sat, 31 Dec 2005 10:44:45 -0800 Message-Id: <200512311844.jBVIijWt017642@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact CC Received-SPF: none (maggie.w3.org: domain of hunkim@ietf.cse.ucsc.edu does not designate permitted sender hosts) X-W3C-Hub-Spam-Status: No, score=-2.5 X-W3C-Scan-Sig: maggie.w3.org 1Eslih-0001jF-2p e5713caa8d5bf6d386785d6a15dcebb7 X-Original-To: w3c-dist-auth@w3.org Subject: [Bug 213] Spec inconsistent on PROPFIND/Depth:infinity X-Archived-At: http://www.w3.org/mid/200512311844.jBVIijWt017642@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11457 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 18:45:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213 ------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 10:44 ------- *** Bug 212 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. You are on the CC list for the bug, or are watching someone who is. From w3c-dist-auth-request@frink.w3.org Sat Dec 31 16:15:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eso4w-0002Eo-Lr for webdav-archive@megatron.ietf.org; Sat, 31 Dec 2005 16:15:55 -0500 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15843 for ; Sat, 31 Dec 2005 16:14:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Eso3Z-0001kQ-BM for w3c-dist-auth-dist@listhub.w3.org; Sat, 31 Dec 2005 21:14:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Eso3N-0001ib-Gj for w3c-dist-auth@listhub.w3.org; Sat, 31 Dec 2005 21:14:17 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.50) id 1Eso3L-0008JK-Nz for w3c-dist-auth@w3.org; Sat, 31 Dec 2005 21:14:17 +0000 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FBED142296; Sat, 31 Dec 2005 14:17:24 -0800 (PST) In-Reply-To: <43B67F85.4020104@gmx.de> References: <43979C55.9040408@oracle.com> <43B67F85.4020104@gmx.de> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <775026c0d04ea16307b6388680ee0394@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: webdav WG , briank@networkresonance.com, Bernard Desruisseaux From: Lisa Dusseault Date: Sat, 31 Dec 2005 13:14:11 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.623) Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Eso3L-0008JK-Nz 02f71324273e6fc3ba1735044ddb48d0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: draft-ietf-webdav-quota-07.txt: DAV:quota-not-exceeded X-Archived-At: http://www.w3.org/mid/775026c0d04ea16307b6388680ee0394@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/11458 X-Loop: w3c-dist-auth@w3.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, 31 Dec 2005 21:14:29 +0000 Content-Transfer-Encoding: 7bit Presumably we'll get a chance to fix this in Auth 48. lisa On Dec 31, 2005, at 4:54 AM, Julian Reschke wrote: > Bernard Desruisseaux wrote: >> In Section 6. Error reporting shouldn't DAV:quota-not-exceeded be a >> postcondition instead of a precondition? > > Yes, I think so. Alternatively, the definition could be rewritten so > that it becomes a precondition. Lisa, Brian? > > > Best regards, Julian >