From w3c-dist-auth-request@w3.org Wed Jan 5 15:46:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10085 for ; Wed, 5 Jan 2005 15:46:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CmHzG-00035z-SJ for w3c-dist-auth-dist@listhub.w3.org; Wed, 05 Jan 2005 20:42:34 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CmHzG-0002rw-GQ for w3c-dist-auth@listhub.w3.org; Wed, 05 Jan 2005 20:42:34 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by bart.w3.org with esmtp (Exim 4.34) id 1CmHz6-0000TO-Tg for w3c-dist-auth@w3.org; Wed, 05 Jan 2005 20:42:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09873; Wed, 5 Jan 2005 15:42:06 -0500 (EST) Message-Id: <200501052042.PAA09873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Wed, 05 Jan 2005 15:42:06 -0500 Received-SPF: none (bart.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-bind-10.txt X-Archived-At: http://www.w3.org/mid/200501052042.PAA09873@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9228 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 05 Jan 2005 20:42:34 +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 : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) Author(s) : G. Clemm, et al. Filename : draft-ietf-webdav-bind-10.txt Pages : 42 Date : 2005-1-5 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.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-bind-10.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-bind-10.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-1-5153213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-5153213.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jan 11 19:45:12 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21197 for ; Tue, 11 Jan 2005 19:45:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CoWb8-00030i-1Z for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 00:42:54 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CoWb7-00030C-MG for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 00:42:53 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1CoWb7-0002dL-EZ for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 00:42:53 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CK25PM1J; Tue, 11 Jan 2005 17:36:06 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDAV From: Joe Hildebrand Date: Tue, 11 Jan 2005 17:42:26 -0700 X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/D4D7B726-6432-11D9-9BF0-000A959A17A6@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 00:42:54 +0000 Content-Transfer-Encoding: 7bit This e-mail serves as the Working Group Last Call for BIND: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt Here is the process we are going to use: - Issues entered into the issue tracker: http://ietf.webdav.org:8080/bugzilla/ - Discuss issues on the list by replying to the issue e-mail - If you believe you have the resolution of the issue, attach it as a comment on the tracker - If you agree with the issue, vote for it on the tracker - The issue opener may close the issue, if the vote count is still 0 - If the vote count is >0, only a working group chair or person designated by the chair may close the issue - Issues will be closed when consensus is achieved on the issue being resolved - Once an issue is closed according to this process, it may not be reopened - If you still have outstanding issues that were closed, that you believe are still an issue, reopen the issue, and we will use these rules to close them - Issues that have 0 votes at the end of last call will be closed automatically The vote count is not a 'majority wins' sort of vote, but hopefully will allow some of those who want to register concern to be able to do so in a relatively low-effort way. Last call will go on for three weeks, ending at 12 noon GMT February 2, 2005. -- Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Tue Jan 11 20:04:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22557 for ; Tue, 11 Jan 2005 20:04:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CoWut-0000bv-EP for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 01:03:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CoWut-0000b2-3F for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 01:03:19 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CoWus-0007Xb-Oz for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 01:03:19 +0000 Received: (qmail invoked by alias); 12 Jan 2005 01:02:45 -0000 Received: from pD9535827.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.88.39) by mail.gmx.net (mp022) with SMTP; 12 Jan 2005 02:02:45 +0100 X-Authenticated: #1915285 Message-ID: <41E4772E.9030305@gmx.de> Date: Wed, 12 Jan 2005 02:02:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/41E4772E.9030305@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 01:03:19 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > This e-mail serves as the Working Group Last Call for BIND: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt Thanks. Procedural questions...: > Here is the process we are going to use: > - Issues entered into the issue tracker: > http://ietf.webdav.org:8080/bugzilla/ > - Discuss issues on the list by replying to the issue e-mail > - If you believe you have the resolution of the issue, attach it as a > comment on the tracker > - If you agree with the issue, vote for it on the tracker If I disagree, then....? > - The issue opener may close the issue, if the vote count is still 0 > - If the vote count is >0, only a working group chair or person > designated by the chair may close the issue > - Issues will be closed when consensus is achieved on the issue being > resolved Shouldn't that be "rough consensus"? As far as I can tell, I expect that there'll be issues for which we definitively won't reach consensus, judging from past discussions. > - Once an issue is closed according to this process, it may not be reopened > - If you still have outstanding issues that were closed, that you > believe are still an issue, reopen the issue, and we will use these > rules to close them Nit: that seems to say that an issue may not be re-opened unless somebody feels it needs to :-) > - Issues that have 0 votes at the end of last call will be closed > automatically Are votes from the issue opener counted? > The vote count is not a 'majority wins' sort of vote, but hopefully will > allow some of those who want to register concern to be able to do so in > a relatively low-effort way. As there doesn't seem to be a way to vote against an issue, this doesn't seem to work. > Last call will go on for three weeks, ending at 12 noon GMT February 2, > 2005. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 11 23:33:16 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05768 for ; Tue, 11 Jan 2005 23:33:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CoaAD-0001Vz-Cy for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 04:31:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CoaAC-0001VV-UL for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 04:31:20 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CoaA3-0002XY-E2 for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 04:31:11 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0C4UhBW014524 for ; Tue, 11 Jan 2005 23:30:43 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0C4Ubvh277770 for ; Tue, 11 Jan 2005 23:30:37 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0C4Ua81005296 for ; Tue, 11 Jan 2005 23:30:36 -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 j0C4UaMv005293 for ; Tue, 11 Jan 2005 23:30:36 -0500 In-Reply-To: <41E4772E.9030305@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 11 Jan 2005 23:30:34 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/11/2005 23:30:36, Serialize complete at 01/11/2005 23:30:36 Content-Type: multipart/alternative; boundary="=_alternative 0018C45A85256F87_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/OF58667192.407C1E55-ON85256F87.00157C7C-85256F87.0018C45D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 04:31:21 +0000 This is a multipart message in MIME format. --=_alternative 0018C45A85256F87_= Content-Type: text/plain; charset="US-ASCII" I share Julian's concern that the lack of a "vote against" feature makes the bugzilla voting mechanism not very useful/appropriate for specifications issues. The policy of limiting the number of votes (currently set to just 1) further limits the utility of this mechanism (and encourages bundling all of ones issues into a single "report" so that you can vote for all of them without spending multiple votes). I also share his puzzlement over the "you can't reopen an issue unless you want to" rule (:-). A key point is how one determines rough consensus (since the voting mechanism doesn't help with that). Any thoughts on how that would be determined? Cheers, Geoff Julian wrote on 01/11/2005 08:02:38 PM: > > Joe Hildebrand wrote: > > > This e-mail serves as the Working Group Last Call for BIND: > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt > > Thanks. > > Procedural questions...: > > > Here is the process we are going to use: > > - Issues entered into the issue tracker: > > http://ietf.webdav.org:8080/bugzilla/ > > - Discuss issues on the list by replying to the issue e-mail > > - If you believe you have the resolution of the issue, attach it as a > > comment on the tracker > > - If you agree with the issue, vote for it on the tracker > > If I disagree, then....? > > > - The issue opener may close the issue, if the vote count is still 0 > > - If the vote count is >0, only a working group chair or person > > designated by the chair may close the issue > > - Issues will be closed when consensus is achieved on the issue being > > resolved > > Shouldn't that be "rough consensus"? As far as I can tell, I expect that > there'll be issues for which we definitively won't reach consensus, > judging from past discussions. > > > - Once an issue is closed according to this process, it may not be reopened > > - If you still have outstanding issues that were closed, that you > > believe are still an issue, reopen the issue, and we will use these > > rules to close them > > Nit: that seems to say that an issue may not be re-opened unless > somebody feels it needs to :-) > > > - Issues that have 0 votes at the end of last call will be closed > > automatically > > Are votes from the issue opener counted? > > > The vote count is not a 'majority wins' sort of vote, but hopefully will > > allow some of those who want to register concern to be able to do so in > > a relatively low-effort way. > > As there doesn't seem to be a way to vote against an issue, this doesn't > seem to work. > > > Last call will go on for three weeks, ending at 12 noon GMT February 2, > > 2005. > > Best regards, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0018C45A85256F87_= Content-Type: text/html; charset="US-ASCII"
I share Julian's concern that the lack of a "vote against" feature makes the bugzilla voting mechanism not very useful/appropriate for specifications issues.  The policy of limiting the number of votes (currently set to just 1) further limits the utility of this mechanism (and encourages bundling all of ones issues into a single "report" so that you can vote for all of them without spending multiple votes).

I also share his puzzlement over the "you can't reopen an issue unless you want to" rule (:-).

A key point is how one determines rough consensus (since the voting mechanism doesn't help with that).  Any thoughts on how that would be determined?

Cheers,
Geoff


Julian wrote on 01/11/2005 08:02:38 PM:
>
> Joe Hildebrand wrote:
>
> > This e-mail serves as the Working Group Last Call for BIND:
> > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt
>
> Thanks.
>
> Procedural questions...:
>
> > Here is the process we are going to use:
> > - Issues entered into the issue tracker:
> > http://ietf.webdav.org:8080/bugzilla/
> > - Discuss issues on the list by replying to the issue e-mail
> > - If you believe you have the resolution of the issue, attach it as a
> > comment on the tracker
> > - If you agree with the issue, vote for it on the tracker
>
> If I disagree, then....?
>
> > - The issue opener may close the issue, if the vote count is still 0
> > - If the vote count is >0, only a working group chair or person
> > designated by the chair may close the issue
> > - Issues will be closed when consensus is achieved on the issue being
> > resolved
>
> Shouldn't that be "rough consensus"? As far as I can tell, I expect that
> there'll be issues for which we definitively won't reach consensus,
> judging from past discussions.
>
> > - Once an issue is closed according to this process, it may not be reopened
> > - If you still have outstanding issues that were closed, that you
> > believe are still an issue, reopen the issue, and we will use these
> > rules to close them
>
> Nit: that seems to say that an issue may not be re-opened unless
> somebody feels it needs to :-)
>
> > - Issues that have 0 votes at the end of last call will be closed
> > automatically
>
> Are votes from the issue opener counted?
>
> > The vote count is not a 'majority wins' sort of vote, but hopefully will
> > allow some of those who want to register concern to be able to do so in
> > a relatively low-effort way.
>
> As there doesn't seem to be a way to vote against an issue, this doesn't
> seem to work.
>
> > Last call will go on for three weeks, ending at 12 noon GMT February 2,
> > 2005.
>
> Best regards, Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0018C45A85256F87_=-- From w3c-dist-auth-request@w3.org Wed Jan 12 01:23:16 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12135 for ; Wed, 12 Jan 2005 01:23:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cobst-0002HJ-8q for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 06:21:35 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cobss-0002Gk-U1 for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 06:21:34 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1Cobss-0001ae-NQ for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 06:21:34 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CK25PTMV; Tue, 11 Jan 2005 23:14:43 -0700 In-Reply-To: <41E4772E.9030305@gmx.de> References: <41E4772E.9030305@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21CCB5F5-6462-11D9-9BF0-000A959A17A6@jabber.com> Content-Transfer-Encoding: 7bit Cc: WebDAV From: Joe Hildebrand Date: Tue, 11 Jan 2005 23:21:02 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/21CCB5F5-6462-11D9-9BF0-000A959A17A6@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9232 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 06:21:35 +0000 Content-Transfer-Encoding: 7bit >> - If you agree with the issue, vote for it on the tracker > > If I disagree, then....? You voice your disagreement on the list. It's not an actual vote, it's a way to find out if certain issues are just outliers. My understanding of some of the disagreements that have happened in the past is that people have had issues, other people have agreed with them but not said anything. I'd say that by definition, an issue that only has a single supporter shouldn't hinder rough consensus. This is actually an attempt to weed out those issues more easily. >> - The issue opener may close the issue, if the vote count is still 0 >> - If the vote count is >0, only a working group chair or person >> designated by the chair may close the issue >> - Issues will be closed when consensus is achieved on the issue being >> resolved > > Shouldn't that be "rough consensus"? As far as I can tell, I expect > that there'll be issues for which we definitively won't reach > consensus, judging from past discussions. Sorry, I was slightly unclear. "consensus is achieved" should have read something like "when the chairs decide that rough consensus has been reached". > >> - Once an issue is closed according to this process, it may not be >> reopened >> - If you still have outstanding issues that were closed, that you >> believe are still an issue, reopen the issue, and we will use these >> rules to close them > > Nit: that seems to say that an issue may not be re-opened unless > somebody feels it needs to :-) We didn't have process for closing issues until now. Some of them may have been closed without the opener feeling their issue got full treatment. My intent was that only issues that have been closed prior to this last call could be re-opened. > >> - Issues that have 0 votes at the end of last call will be closed >> automatically > > Are votes from the issue opener counted? As the 0th vote. :) >> The vote count is not a 'majority wins' sort of vote, but hopefully >> will allow some of those who want to register concern to be able to >> do so in a relatively low-effort way. > > As there doesn't seem to be a way to vote against an issue, this > doesn't seem to work. The word "vote" is perhaps confusing. It's just a way of registering the fact that an issue is important to more than one person. From w3c-dist-auth-request@w3.org Wed Jan 12 01:38:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13090 for ; Wed, 12 Jan 2005 01:38:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Coc8T-0006Uy-Rr for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 06:37:41 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Coc8T-0006UU-J7 for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 06:37:41 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by lisa.w3.org with esmtp (Exim 4.34) id 1Coc8K-0005Qx-23 for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 06:37:32 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CK25PTS5; Tue, 11 Jan 2005 23:30:54 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.com> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Joe Hildebrand Date: Tue, 11 Jan 2005 23:37:13 -0700 X-Mailer: Apple Mail (2.619) Received-SPF: none (lisa.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.com To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9233 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 06:37:41 +0000 Content-Transfer-Encoding: quoted-printable > I share Julian's concern that the lack of a "vote against" feature=20 > makes the bugzilla voting mechanism not very useful/appropriate for=20 > specifications issues. =A0The policy of limiting the number of votes=20= > (currently set to just 1) further limits the utility of this mechanism=20= > (and encourages bundling all of ones issues into a single "report" so=20= > that you can vote for all of them without spending multiple votes). Sorry about that. I've set the max votes to 100. > I also share his puzzlement over the "you can't reopen an issue unless=20= > you want to" rule (:-). Hopefully I clarified that in my response to him. > A key point is how one determines rough consensus (since the voting=20 > mechanism doesn't help with that). =A0Any thoughts on how that would = be=20 > determined? Chair omniscience. :) Seriously, if there are multiple camps that can't come together, we'll=20= have to keep working. I'll suggest again that those who want these drafts to continue to make=20= forward progress would benefit from coming to an IETF meeting and doing=20= some good old-fashioned politics. Meet people. Make friends. Explain=20= your point of view. Relationships, trust, and respect can drive a=20 group towards consensus. http://ietf.org/meetings/IETF-62.html From w3c-dist-auth-request@w3.org Wed Jan 12 03:44:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22935 for ; Wed, 12 Jan 2005 03:44:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Coe5g-0001Nw-2h for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 08:42:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Coe5f-0001Mv-O9 for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 08:42:55 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Coe5W-0001eN-3L for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 08:42:46 +0000 Received: (qmail invoked by alias); 12 Jan 2005 08:42:22 -0000 Received: from pD9535827.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.88.39) by mail.gmx.net (mp013) with SMTP; 12 Jan 2005 09:42:22 +0100 X-Authenticated: #1915285 Message-ID: <41E4E2EB.40507@gmx.de> Date: Wed, 12 Jan 2005 09:42:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: w3c-dist-auth@w3.org References: <64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.com> In-Reply-To: <64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/41E4E2EB.40507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 08:42:56 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > ... > I'll suggest again that those who want these drafts to continue to make > forward progress would benefit from coming to an IETF meeting and doing > some good old-fashioned politics. Meet people. Make friends. Explain > your point of view. Relationships, trust, and respect can drive a group > towards consensus. > ... I find this comment puzzling. BIND has passed already one WG last call a few years ago, has been on the WG's agenda almost since day one (as part of "advanced collections"), and has been the top priority in the WebDAV WG's charter for quite some time. Does it really need additional political lobbying at this point? After all, there is no requirement whatsoever that WGs indeed meet at each IETF (or at all, for that matter). If the WG chairs want to promote a meeting, it would be helpful if there'd be some more advance planning than in the past, so that people would have some idea about what the goals are (just re-stating the status quo isn't that helpful). As far as I can tell, the current contents of BIND indeed represents rough consensus (in the semantics the WG wanted to achieve) *and* running code (interoperable code being *deployed*, not only in development), so it's really really time that it get's out of ID state (even if this means publishing as "Experimental" if that is needed to overcome the opposition of a few who, for reasons unclear to me, seem to prefer blocking the progress). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 12 07:38:46 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07178 for ; Wed, 12 Jan 2005 07:38:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CohkN-0000KG-A9 for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 12:37:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CohkM-0000Jm-Ti for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 12:37:10 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CohkD-0002ej-DN for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 12:37:01 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0CCaUBW009155 for ; Wed, 12 Jan 2005 07:36:30 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0CCaOHZ249130 for ; Wed, 12 Jan 2005 07:36:24 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0CCaOeK012211 for ; Wed, 12 Jan 2005 07:36:24 -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 j0CCaOha012205 for ; Wed, 12 Jan 2005 07:36:24 -0500 In-Reply-To: <64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 12 Jan 2005 07:36:25 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/12/2005 07:36:23, Serialize complete at 01/12/2005 07:36:23 Content-Type: multipart/alternative; boundary="=_alternative 00453F6D85256F87_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/OFE95A2323.CC1E9517-ON85256F87.0044E42A-85256F87.00453F6E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9235 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 12:37:11 +0000 This is a multipart message in MIME format. --=_alternative 00453F6D85256F87_= Content-Type: text/plain; charset="US-ASCII" I'm happy with all of Joe's answers, so I'm +1 for the process (in the spirit of getting rough consensus on the process for determining rough consensus :-). BTW, I encourage folks to review the outstanding issues against 2518bis, and vote for the ones you care about. Cheers, Geoff Joe wrote on 01/12/2005 01:37:13 AM: > > > I share Julian's concern that the lack of a "vote against" feature > > makes the bugzilla voting mechanism not very useful/appropriate for > > specifications issues. The policy of limiting the number of votes > > (currently set to just 1) further limits the utility of this mechanism > > (and encourages bundling all of ones issues into a single "report" so > > that you can vote for all of them without spending multiple votes). > > Sorry about that. I've set the max votes to 100. > > > I also share his puzzlement over the "you can't reopen an issue unless > > you want to" rule (:-). > > Hopefully I clarified that in my response to him. > > > A key point is how one determines rough consensus (since the voting > > mechanism doesn't help with that). Any thoughts on how that would be > > determined? > > Chair omniscience. :) > > Seriously, if there are multiple camps that can't come together, we'll > have to keep working. > > I'll suggest again that those who want these drafts to continue to make > forward progress would benefit from coming to an IETF meeting and doing > some good old-fashioned politics. Meet people. Make friends. Explain > your point of view. Relationships, trust, and respect can drive a > group towards consensus. > > http://ietf.org/meetings/IETF-62.html > > --=_alternative 00453F6D85256F87_= Content-Type: text/html; charset="US-ASCII"
I'm happy with all of Joe's answers, so I'm +1 for the process
(in the spirit of getting rough consensus on the process for
determining rough consensus :-).

BTW, I encourage folks to review the outstanding issues against
2518bis, and vote for the ones you care about.

Cheers,
Geoff


Joe wrote on 01/12/2005 01:37:13 AM:
>
> > I share Julian's concern that the lack of a "vote against" feature
> > makes the bugzilla voting mechanism not very useful/appropriate for
> > specifications issues.  The policy of limiting the number of votes
> > (currently set to just 1) further limits the utility of this mechanism
> > (and encourages bundling all of ones issues into a single "report" so
> > that you can vote for all of them without spending multiple votes).
>
> Sorry about that.  I've set the max votes to 100.
>
> > I also share his puzzlement over the "you can't reopen an issue unless
> > you want to" rule (:-).
>
> Hopefully I clarified that in my response to him.
>
> > A key point is how one determines rough consensus (since the voting
> > mechanism doesn't help with that).  Any thoughts on how that would be
> > determined?
>
> Chair omniscience.  :)
>
> Seriously, if there are multiple camps that can't come together, we'll
> have to keep working.
>
> I'll suggest again that those who want these drafts to continue to make
> forward progress would benefit from coming to an IETF meeting and doing
> some good old-fashioned politics.  Meet people.  Make friends.  Explain
> your point of view.  Relationships, trust, and respect can drive a
> group towards consensus.
>
> http://ietf.org/meetings/IETF-62.html
>
>
--=_alternative 00453F6D85256F87_=-- From w3c-dist-auth-request@w3.org Wed Jan 12 07:47:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07725 for ; Wed, 12 Jan 2005 07:47:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cohsh-0002RC-FN for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 12:45:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cohsh-0002QT-7T for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 12:45:47 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1CohsX-0003dq-NG for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 12:45:37 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0CCjGZo028429 for ; Wed, 12 Jan 2005 07:45:16 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0CCjFHZ285106 for ; Wed, 12 Jan 2005 07:45:15 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0CCjF23005486 for ; Wed, 12 Jan 2005 07:45:15 -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 j0CCjF5a005356 for ; Wed, 12 Jan 2005 07:45:15 -0500 In-Reply-To: <41E4E2EB.40507@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 12 Jan 2005 07:45:10 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/12/2005 07:45:14, Serialize complete at 01/12/2005 07:45:14 Content-Type: multipart/alternative; boundary="=_alternative 00460CCF85256F87_=" Received-SPF: none (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/OFD7569480.7C3DDB5F-ON85256F87.00455603-85256F87.00460CD0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 12:45:47 +0000 This is a multipart message in MIME format. --=_alternative 00460CCF85256F87_= Content-Type: text/plain; charset="US-ASCII" I believe Joe was just responding to my question about the general process of achieving rough consensus, and not speaking primarily about the BIND specification. In particular, during the design phase of a new specification, face-to-face communication is often required to iron out different points of view. During the "review" phase, I've found that email is often sufficient (and often preferable, because it widens the discussion to a larger group, since often it is only the "designers" whose companies are willing to fund travel). Cheers, Geoff Julian wrote on 01/12/2005 03:42:19 AM: > > Joe Hildebrand wrote: > > ... > > I'll suggest again that those who want these drafts to continue to make > > forward progress would benefit from coming to an IETF meeting and doing > > some good old-fashioned politics. Meet people. Make friends. Explain > > your point of view. Relationships, trust, and respect can drive a group > > towards consensus. > > ... > > I find this comment puzzling. BIND has passed already one WG last call a > few years ago, has been on the WG's agenda almost since day one (as part > of "advanced collections"), and has been the top priority in the WebDAV > WG's charter for quite some time. Does it really need additional > political lobbying at this point? > > After all, there is no requirement whatsoever that WGs indeed meet at > each IETF (or at all, for that matter). If the WG chairs want to promote > a meeting, it would be helpful if there'd be some more advance planning > than in the past, so that people would have some idea about what the > goals are (just re-stating the status quo isn't that helpful). > > As far as I can tell, the current contents of BIND indeed represents > rough consensus (in the semantics the WG wanted to achieve) *and* > running code (interoperable code being *deployed*, not only in > development), so it's really really time that it get's out of ID state > (even if this means publishing as "Experimental" if that is needed to > overcome the opposition of a few who, for reasons unclear to me, seem to > prefer blocking the progress). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 00460CCF85256F87_= Content-Type: text/html; charset="US-ASCII"
I believe Joe was just responding to my question about the general
process of achieving rough consensus, and not speaking primarily about
the BIND specification.   In particular, during the design phase of
a new specification, face-to-face communication is often required to
iron out different points of view.  During the "review" phase, I've
found that email is often sufficient (and often preferable, because
it widens the discussion to a larger group, since often it is only the
"designers" whose companies are willing to fund travel).

Cheers,
Geoff

Julian wrote on 01/12/2005 03:42:19 AM:

>
> Joe Hildebrand wrote:
>  > ...
> > I'll suggest again that those who want these drafts to continue to make
> > forward progress would benefit from coming to an IETF meeting and doing
> > some good old-fashioned politics.  Meet people.  Make friends.  Explain
> > your point of view.  Relationships, trust, and respect can drive a group
> > towards consensus.
> > ...
>
> I find this comment puzzling. BIND has passed already one WG last call a
> few years ago, has been on the WG's agenda almost since day one (as part
> of "advanced collections"), and has been the top priority in the WebDAV
> WG's charter for quite some time. Does it really need additional
> political lobbying at this point?
>
> After all, there is no requirement whatsoever that WGs indeed meet at
> each IETF (or at all, for that matter). If the WG chairs want to promote
> a meeting, it would be helpful if there'd be some more advance planning
> than in the past, so that people would have some idea about what the
> goals are (just re-stating the status quo isn't that helpful).
>
> As far as I can tell, the current contents of BIND indeed represents
> rough consensus (in the semantics the WG wanted to achieve) *and*
> running code (interoperable code being *deployed*, not only in
> development), so it's really really time that it get's out of ID state
> (even if this means publishing as "Experimental" if that is needed to
> overcome the opposition of a few who, for reasons unclear to me, seem to
> prefer blocking the progress).
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 00460CCF85256F87_=-- From w3c-dist-auth-request@w3.org Wed Jan 12 09:35:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16819 for ; Wed, 12 Jan 2005 09:35:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CojZX-00028I-8n for w3c-dist-auth-dist@listhub.w3.org; Wed, 12 Jan 2005 14:34:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CojZW-00027o-Vi for w3c-dist-auth@listhub.w3.org; Wed, 12 Jan 2005 14:34:06 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1CojZW-00062x-Ow for w3c-dist-auth@w3.org; Wed, 12 Jan 2005 14:34:06 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CK25P9BD; Wed, 12 Jan 2005 07:27:19 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41E4E2EB.40507@gmx.de> References: <64E7D471-6464-11D9-9BF0-000A959A17A6@jabber.com> <41E4E2EB.40507@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Hildebrand Date: Wed, 12 Jan 2005 07:33:38 -0700 To: webdav X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: WG Last call for BIND X-Archived-At: http://www.w3.org/mid/F2E2D070-64A6-11D9-9BF0-000A959A17A6@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9237 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 12 Jan 2005 14:34:07 +0000 Content-Transfer-Encoding: 7bit This is a good example of how, if you knew me a little better, our communication could be improved. This was off the topic of BIND in specific, on to how to achieve consensus in general. BIND should be fine. 2518bis may yet need some discussion, as may other topics. -- Joe Hildebrand Denver, CO, USA On Jan 12, 2005, at 1:42 AM, Julian Reschke wrote: > > Joe Hildebrand wrote: > > ... >> I'll suggest again that those who want these drafts to continue to >> make forward progress would benefit from coming to an IETF meeting >> and doing some good old-fashioned politics. Meet people. Make >> friends. Explain your point of view. Relationships, trust, and >> respect can drive a group towards consensus. >> ... > > I find this comment puzzling. BIND has passed already one WG last call > a few years ago, has been on the WG's agenda almost since day one (as > part of "advanced collections"), and has been the top priority in the > WebDAV WG's charter for quite some time. Does it really need > additional political lobbying at this point? > > After all, there is no requirement whatsoever that WGs indeed meet at > each IETF (or at all, for that matter). If the WG chairs want to > promote a meeting, it would be helpful if there'd be some more advance > planning than in the past, so that people would have some idea about > what the goals are (just re-stating the status quo isn't that > helpful). > > As far as I can tell, the current contents of BIND indeed represents > rough consensus (in the semantics the WG wanted to achieve) *and* > running code (interoperable code being *deployed*, not only in > development), so it's really really time that it get's out of ID state > (even if this means publishing as "Experimental" if that is needed to > overcome the opposition of a few who, for reasons unclear to me, seem > to prefer blocking the progress). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Wed Jan 12 19:10:58 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02088 for ; Wed, 12 Jan 2005 19:10:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CosY4-0000HK-38 for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 00:09:12 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CosY3-0000Gl-LX for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 00:09:11 +0000 Received: from wproxy.gmail.com ([64.233.184.192]) by bart.w3.org with esmtp (Exim 4.34) id 1CosY3-0005GE-Fc for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 00:09:11 +0000 Received: by wproxy.gmail.com with SMTP id 37so104070wra for ; Wed, 12 Jan 2005 16:08:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=rNvvWjspGtJrYzkcvGK5cg07/nqM14LCk2fQnIAWzYRikSS5IslQMycpyuaB/5NTJ5so+D+fvX14ASKD4nhdJNILQFO1rau3E9rdrYHnmeKyKcs1+BlzPZtSUXkEsjPRACPYaI8kHaKB5ftEdZhzqwwzKTKZWiKDJLO2fM5SHo0= Received: by 10.54.29.67 with SMTP id c67mr224528wrc; Wed, 12 Jan 2005 16:08:40 -0800 (PST) Received: by 10.54.48.38 with HTTP; Wed, 12 Jan 2005 16:08:40 -0800 (PST) Message-ID: <522020a4050112160836afe9eb@mail.gmail.com> Date: Wed, 12 Jan 2005 16:08:40 -0800 From: Mike Lindsey Reply-To: Mike Lindsey To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (bart.w3.org: domain of coyote@gmail.com designates 64.233.184.192 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/522020a4050112160836afe9eb@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9238 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 00:09:12 +0000 Content-Transfer-Encoding: 7bit If this isn't the right list, I apologize, point me on my way and I'll go bother the right people. I've got an apache 2 server running with two dav directories. One I store my sunbird calendar files in. It works, it's fine. I can also mount that directory as a ms web folder, through windows 2000. The other directory, which has the same ownership and permissions, I can hit in my browser, but I can't mount as a web folder. Windows tells me that it's not a valid folder. But, as far as I can tell, my configuration is identical. My conf output: DavMinTimeout 600 Options None Dav On AuthType Digest AuthName Calendars AuthDigestDomain /cal/calendars/ AuthDigestFile /etc/apache2/conf/digest_pw Require valid-user Options None Dav On AuthType Digest AuthName Mike AuthDigestDomain /roam/mike/ AuthDigestFile /etc/apache2/conf/digest_pw Require valid-user access_log output for the failed mount: 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam HTTP/1.1" 200 - 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "GET /_vti_inf.html HTTP/1.1" 404 346 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 360 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam/mike HTTP/1.1" 200 - and for the successful mount: 192.138.150.250 - - [12/Jan/2005:23:22:21 +0000] "OPTIONS /cal HTTP/1.1" 200 - 192.138.150.250 - - [12/Jan/2005:23:22:21 +0000] "PROPFIND /cal/calendars HTTP/1.1" 207 789 192.138.150.250 - - [12/Jan/2005:23:22:26 +0000] "PROPFIND /cal/calendars HTTP/1.1" 207 6295 -- Mike Lindsey From w3c-dist-auth-request@w3.org Thu Jan 13 10:50:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20702 for ; Thu, 13 Jan 2005 10:50:07 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cp7Bp-0007PF-Di for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 15:47:13 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cp7Bp-0007Ol-3b for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 15:47:13 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cp7Bf-00055q-A2 for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 15:47:03 +0000 Received: (qmail invoked by alias); 13 Jan 2005 15:46:40 -0000 Received: from p50825059.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.80.89) by mail.gmx.net (mp013) with SMTP; 13 Jan 2005 16:46:40 +0100 X-Authenticated: #1915285 Message-ID: <41E697DD.6040407@gmx.de> Date: Thu, 13 Jan 2005 16:46:37 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Lindsey CC: w3c-dist-auth@w3.org References: <522020a4050112160836afe9eb@mail.gmail.com> In-Reply-To: <522020a4050112160836afe9eb@mail.gmail.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/41E697DD.6040407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 15:47:13 +0000 Content-Transfer-Encoding: 7bit Mike Lindsey wrote: > If this isn't the right list, I apologize, point me on my way and I'll > go bother the right people. > > I've got an apache 2 server running with two dav directories. One I > store my sunbird calendar files in. It works, it's fine. I can also > mount that directory as a ms web folder, through windows 2000. The > other directory, which has the same ownership and permissions, I can > hit in my browser, but I can't mount as a web folder. Windows tells > me that it's not a valid folder. > > But, as far as I can tell, my configuration is identical. > ... Hi, it would be interesting to see full HTTP traces for both cases. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jan 13 11:13:37 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22654 for ; Thu, 13 Jan 2005 11:13:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cp7aH-0006qR-MN for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 16:12:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cp7aH-0006pt-GZ for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 16:12:29 +0000 Received: from mail22.sea5.speakeasy.net ([69.17.117.24] helo=mail14.speakeasy.net) by bart.w3.org with esmtp (Exim 4.34) id 1Cp7aH-0000NJ-64 for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 16:12:29 +0000 Received: (qmail 25856 invoked from network); 13 Jan 2005 16:12:27 -0000 Received: from adsl-63-194-88-161.dsl.snfc21.pacbell.net (HELO cse.ucsc.edu) (elias@[63.194.88.161]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 Jan 2005 16:12:27 -0000 Message-ID: <41E69DE9.1000905@cse.ucsc.edu> Date: Thu, 13 Jan 2005 08:12:25 -0800 From: Elias Sinderson User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Lindsey CC: w3c-dist-auth@w3.org References: <522020a4050112160836afe9eb@mail.gmail.com> In-Reply-To: <522020a4050112160836afe9eb@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/41E69DE9.1000905@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9240 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 16:12:29 +0000 Content-Transfer-Encoding: 7bit Mike Lindsey wrote: >[...] My conf output: >[...] >[...] access_log output for the failed mount: >[...] 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "GET /_vti_inf.html HTTP/1.1" 404 346 >192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 360 >192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam/mike HTTP/1.1" 200 - > Please correct me if I'm wrong, but this doesn't appear to be a DAV issue. Note the differing locations in your DAV configuration (/roam/mike/) and requests (/_vti_inf.html and /_vti_bin/shtml.exe/_vti_rpc), where the requests return 404s (Not Found). Also note that GET and POST won't really test your DAV configuration, even if pointed at the DAV enabled area of your server. As your configurations appear identical, you may wish to point your Sunbird (DAV) client at /roam/mike to see if that works as expected. Cheers, Elias From w3c-dist-auth-request@w3.org Thu Jan 13 14:08:37 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04397 for ; Thu, 13 Jan 2005 14:08:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpAIO-0000OD-Eq for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 19:06:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpAIO-0000Ne-2E for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 19:06:12 +0000 Received: from wproxy.gmail.com ([64.233.184.201]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpAIE-0008R0-G9 for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 19:06:02 +0000 Received: by wproxy.gmail.com with SMTP id 37so65347wra for ; Thu, 13 Jan 2005 11:05:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a6i6Oh880mEhaFhHD/M4v8CrCEMH5HlrmVgAjVZFlmzevmIigpEOea4O63fTu/xMGGHwf55nNunrMcvvXtJvu9VxApquRNGRAndU+L8pKq+Rl1GqE9hN5h8hstfWjUTMg/w6f3FfLvMXZh/l0wJAcuc6EZEqyIz574Yy7S9eDK4= Received: by 10.54.39.10 with SMTP id m10mr210120wrm; Thu, 13 Jan 2005 11:05:40 -0800 (PST) Received: by 10.54.48.38 with HTTP; Thu, 13 Jan 2005 11:05:40 -0800 (PST) Message-ID: <522020a40501131105959e65c@mail.gmail.com> Date: Thu, 13 Jan 2005 11:05:40 -0800 From: Mike Lindsey Reply-To: Mike Lindsey To: w3c-dist-auth@w3.org In-Reply-To: <41E6A1DA.8010601@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <522020a4050112160836afe9eb@mail.gmail.com> <41E69DE9.1000905@cse.ucsc.edu> <41E6A1DA.8010601@gmx.de> Received-SPF: pass (lisa.w3.org: domain of coyote@gmail.com designates 64.233.184.201 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/522020a40501131105959e65c@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9241 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 19:06:12 +0000 Content-Transfer-Encoding: 7bit On Thu, 13 Jan 2005 17:29:14 +0100, Julian Reschke wrote: > What we see is Windows trying to connect through Frontpage Server > Extensions (which occurs when it thinks there is no WebDAV support). But there -is- webdav support. I can connect to that directory with a different dav client, just fine. Any ideas on how to convince windows that it's a dav directory? Or where to look for logs (hahah) that might give a better idea of what windows thinks is wrong? I've tried on multiple machines with the same error. -- Mike Lindsey From w3c-dist-auth-request@w3.org Thu Jan 13 14:29:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06100 for ; Thu, 13 Jan 2005 14:29:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpAe6-0000Hf-Ie for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 19:28:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpAe6-0000H6-CI for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 19:28:38 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpAdw-0003tr-ND for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 19:28:28 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0DJSZaa007965 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jan 2005 11:28:36 -0800 In-Reply-To: <522020a4050112160836afe9eb@mail.gmail.com> References: <522020a4050112160836afe9eb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4B364D5D-6599-11D9-8F63-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Lisa Dusseault Date: Thu, 13 Jan 2005 11:28:25 -0800 To: Mike Lindsey X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/4B364D5D-6599-11D9-8F63-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9242 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 19:28:38 +0000 Content-Transfer-Encoding: 7bit You might look at the response to the first OPTIONS request (via TCPdump or sniffer), in each case, to see if the server is returning something different. If the server is returning the identical thing (particularly the custom non-standard Microsoft header that Web Folders used to expect) then start looking at the client side steps instead. lisa On Jan 12, 2005, at 4:08 PM, Mike Lindsey wrote: > > If this isn't the right list, I apologize, point me on my way and I'll > go bother the right people. > > I've got an apache 2 server running with two dav directories. One I > store my sunbird calendar files in. It works, it's fine. I can also > mount that directory as a ms web folder, through windows 2000. The > other directory, which has the same ownership and permissions, I can > hit in my browser, but I can't mount as a web folder. Windows tells > me that it's not a valid folder. > > But, as far as I can tell, my configuration is identical. > > My conf output: > > DavMinTimeout 600 > > Options None > Dav On > AuthType Digest > AuthName Calendars > AuthDigestDomain /cal/calendars/ > AuthDigestFile /etc/apache2/conf/digest_pw > Require valid-user > MOVE LOCK UNLOCK> > > > > Options None > Dav On > AuthType Digest > AuthName Mike > AuthDigestDomain /roam/mike/ > AuthDigestFile /etc/apache2/conf/digest_pw > Require valid-user > MOVE LOCK UNLOCK> > > > > > > access_log output for the failed mount: > 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam > HTTP/1.1" 200 - > 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "GET /_vti_inf.html > HTTP/1.1" 404 346 > 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "POST > /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 360 > 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam/mike > HTTP/1.1" 200 - > > and for the successful mount: > 192.138.150.250 - - [12/Jan/2005:23:22:21 +0000] "OPTIONS /cal > HTTP/1.1" 200 - > 192.138.150.250 - - [12/Jan/2005:23:22:21 +0000] "PROPFIND > /cal/calendars HTTP/1.1" 207 789 > 192.138.150.250 - - [12/Jan/2005:23:22:26 +0000] "PROPFIND > /cal/calendars HTTP/1.1" 207 6295 > > > -- > Mike Lindsey > From w3c-dist-auth-request@w3.org Thu Jan 13 14:41:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07669 for ; Thu, 13 Jan 2005 14:41:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpApH-0004So-Mt for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 19:40:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpApH-0004SK-F4 for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 19:40:11 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CpApH-0007BY-6d for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 19:40:11 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0DJe8eV020081; Thu, 13 Jan 2005 11:40:08 -0800 Date: Thu, 13 Jan 2005 11:40:08 -0800 Message-Id: <200501131940.j0DJe8eV020081@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200501131940.j0DJe8eV020081@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 19:40:11 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From lisa@osafoundation.org 2005-01-13 11:40 ------- We've addressed some of Jim's related concerns, but not yet addressed the original specific questions in this bug: - when a resource with bindings A, B is locked via a LOCK request to A, what MUST the contents of the lockdiscovery property look like for both A and B? (to be clear, can A either B appear in the lockdiscovery property, or MUST A appear, or MUST B appear?) - when a resource with bindings A, B is locked via a LOCK request to A, how MUST the server respond to an UNLOCK request to B? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Jan 13 18:46:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06443 for ; Thu, 13 Jan 2005 18:46:03 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpEdm-0006OC-DX for w3c-dist-auth-dist@listhub.w3.org; Thu, 13 Jan 2005 23:44:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpEdl-0006N4-UA for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 23:44:33 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpEdc-0006Qf-8K for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 23:44:24 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0DNiWxs020219; Thu, 13 Jan 2005 15:44:32 -0800 Date: Thu, 13 Jan 2005 15:44:32 -0800 Message-Id: <200501132344.j0DNiWxs020219@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200501132344.j0DNiWxs020219@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9244 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jan 2005 23:44:34 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-13 15:44 ------- I'm not sure why you keep re-opening this issue. Your particular questions answered in , and these answers follow from what RFC2518 already says. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Thu Jan 13 19:02:45 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07932 for ; Thu, 13 Jan 2005 19:02:45 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpEuY-0002rU-IK for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 00:01:54 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpEuY-0002r0-4t for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 00:01:54 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CpEuX-0006sp-Tk for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 00:01:54 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0E01laa010688 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jan 2005 16:01:48 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501132344.j0DNiWbD020215@ietf.cse.ucsc.edu> References: <200501132344.j0DNiWbD020215@ietf.cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Thu, 13 Jan 2005 16:01:41 -0800 To: Julian Reschke , "WebDAV WG))'" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9245 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 00:01:54 +0000 Content-Transfer-Encoding: 7bit I keep re-opening this issue because the spec still doesn't say what the server MUST do or what the client must be prepared to handle. I don't care how you answer it on the list or in bugzilla; I am not even arguing for any specific answer. I am arguing for some *specification* here. These answers may follow from RFC2518 in your interpretation, but there have been and will be other interpretations. Without clear guidance, some clients will assume that the URL that they query (the target of PROPFIND) is the one that MUST appear in the lockdiscovery property for that URL, and that if another URL appears the server must be broken. Some clients will associate only one URL with each locktoken and be confused if the same locktoken appears on some other URL. Some clients will assume that if a URL that they query is locked (and they have the lock token, etc) they can UNLOCK the same URL. If server implementors aren't forced to make compatible choices, then we will have interoperability problems surrounding bindings. We have specifications not just so we can explain the model, but also to make requirements of implementors. Lisa On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote: > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-01-13 15:44 ------- > I'm not sure why you keep re-opening this issue. Your particular > questions > answered in > , and > these answers follow from what RFC2518 already says. > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. From w3c-dist-auth-request@w3.org Thu Jan 13 19:22:50 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09307 for ; Thu, 13 Jan 2005 19:22:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpFE2-0000xN-MQ for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 00:22:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpFE2-0000wo-CT for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 00:22:02 +0000 Received: from cats-mx3.ucsc.edu ([128.114.125.36]) by bart.w3.org with esmtp (Exim 4.34) id 1CpFE2-0002lv-4j for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 00:22:02 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by cats-mx3.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0E0LLMV003514; Thu, 13 Jan 2005 16:21:24 -0800 (PST) Message-Id: <200501140021.j0E0LLMV003514@cats-mx3.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV'" Cc: "'Michael Balloni'" Date: Thu, 13 Jan 2005 16:21:13 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcT5ximGJIOaT3dnQ2eHmtzlaIUMIgACBOIA X-UCSC-CATS-MailScanner: Found to be clean Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: hello from Streamload X-Archived-At: http://www.w3.org/mid/200501140021.j0E0LLMV003514@cats-mx3.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9246 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 00:22:02 +0000 Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Michael to the accept2 list. - Jim -----Original Message----- From: Michael Balloni [mailto:michael@streamload.com] Sent: Thursday, January 13, 2005 3:19 PM To: dav-announce@lyra.org; w3c-dist-auth@w3.org Subject: [Moderator Action] hello from Streamload Hi, I'm Michael Balloni from Streamload (http://www.streamload.com). We are interested in providing WebDAV access to our online file storage. Streamload is no ordinary file system. Hundreds of servers manage hundreds of terabytes of customer data, all using pre-.NET Microsoft technology. At this point I'm interested in hearing about different experiences y'all have had (and services and expertise that can assist us) with implementing highly trafficked real world WebDAV servers with custom backends. Python (Twisted or not) seems like it might be a good way to write a WebDAV server, but is the performance and stability production grade for 100's of Mbps bandwidth and big files, many > 1 GB each? Would the old MP3.com have been able to use Python to dish out its song downloads, for example? Apache's mod_dav with its storage layer API seems up to the job, but how hard is it to get something working really well vs. IIS/ISAPI? Has anybody had any luck (good or bad) doing custom WebDAV programming using IIS/ISAPI? One design goal is that all file byte processing be performed by core (read low memory & CPU usage) web server code...I don't want "read bytes from file/client, write bytes to client/file" loops, I just want to tell something where to get it from and where to stick it. The "where to get it from" will be a server apart from the WebDAV server, so unless WebDAV clients support redirects for file downloads (?), proxying file bytes between servers is another requirement. Our WebDAV software cannot connect directly to our databases, so communicating with other servers (via HTTP magic URLs or XMLRPC) to perform all operations is another requirement. Streamload has a rich metadata model that's compatible with WebDAV...we're very excited about bringing our storage technology together with WebDAV because it creates so much value for our customers. Any anecdotes or tidbits of advice or gut feelings you have, please let me know. Oh, and please CC michael@streamload.com with your responses, and business-related replies should be to me personally so we don't clutter up the list. Thanks, Michael Balloni Streamload Development From w3c-dist-auth-request@w3.org Thu Jan 13 21:18:11 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17268 for ; Thu, 13 Jan 2005 21:18:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpH0v-0001Dn-7r for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 02:16:37 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpH0u-0001Cy-IL; Fri, 14 Jan 2005 02:16:36 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.34) id 1CpH0u-0005V5-Av; Fri, 14 Jan 2005 02:16:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0E2G5BW022383; Thu, 13 Jan 2005 21:16: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/VER6.6) with ESMTP id j0E2G4er245556; Thu, 13 Jan 2005 21:16:05 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0E2G4mw020375; Thu, 13 Jan 2005 21:16:04 -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 j0E2G4ha020364; Thu, 13 Jan 2005 21:16:04 -0500 In-Reply-To: <7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org> To: Lisa Dusseault Cc: Julian Reschke , "WebDAV WG))'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 13 Jan 2005 21:16:10 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/13/2005 21:16:04, Serialize complete at 01/13/2005 21:16:04 Content-Type: multipart/alternative; boundary="=_alternative 000C750885256F89_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/OF99FB12BE.450A822E-ON85256F89.000BCC97-85256F89.000C7509@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9247 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 02:16:37 +0000 This is a multipart message in MIME format. --=_alternative 000C750885256F89_= Content-Type: text/plain; charset="US-ASCII" Lisa, you say the same thing every time, and we give the same response every time (:-). Locking behavior for RFC2518 features (multiple URLs mapped to the same resource) needs to be defined by the locking specification, not by the BIND specification. Otherwise, there will be mass confusion when the locking specification says one thing and the BIND specification says something else. The question of whether or you can apply UNLOCK to a locked resource using a URL other than the one the LOCK was applied to is an open question for the locking specification, and the BIND protocol is not the place to resolve that open locking question (the same question applies to depth locks, which have nothing remotely to do with the BIND protocol). OK, Joe, here's our first test of the "rough consensus" mechanism (:-). Cheers, Geoff Lisa wrote on 01/13/2005 07:01:41 PM: > > I keep re-opening this issue because the spec still doesn't say what > the server MUST do or what the client must be prepared to handle. I > don't care how you answer it on the list or in bugzilla; I am not even > arguing for any specific answer. I am arguing for some *specification* > here. > > These answers may follow from RFC2518 in your interpretation, but there > have been and will be other interpretations. Without clear guidance, > some clients will assume that the URL that they query (the target of > PROPFIND) is the one that MUST appear in the lockdiscovery property for > that URL, and that if another URL appears the server must be broken. > Some clients will associate only one URL with each locktoken and be > confused if the same locktoken appears on some other URL. Some > clients will assume that if a URL that they query is locked (and they > have the lock token, etc) they can UNLOCK the same URL. If server > implementors aren't forced to make compatible choices, then we will > have interoperability problems surrounding bindings. We have > specifications not just so we can explain the model, but also to make > requirements of implementors. > > Lisa > > On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote: > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > 2005-01-13 15:44 ------- > > I'm not sure why you keep re-opening this issue. Your particular > > questions > > answered in > > , and > > these answers follow from what RFC2518 already says. > > > > > > > > ------- You are receiving this mail because: ------- > > You reported the bug, or are watching the reporter. > > --=_alternative 000C750885256F89_= Content-Type: text/html; charset="US-ASCII"
Lisa, you say the same thing every time, and we give the same
response every time (:-).  Locking behavior for RFC2518 features
(multiple URLs mapped to the same resource) needs to be defined by the
locking specification, not by the BIND specification.  Otherwise,
there will be mass confusion when the locking specification says
one thing and the BIND specification says something else.
The question of whether or you can apply UNLOCK to a locked resource
using a URL other than the one the LOCK was applied to is an open
question for the locking specification, and the BIND protocol
is not the place to resolve that open locking question (the same question
applies to depth locks, which have nothing remotely to do with the
BIND protocol).

OK, Joe, here's our first test of the "rough consensus" mechanism (:-).

Cheers,
Geoff


Lisa wrote on 01/13/2005 07:01:41 PM:

>
> I keep re-opening this issue because the spec still doesn't say what
> the server MUST do or what the client must be prepared to handle.  I
> don't care how you answer it on the list or in bugzilla; I am not even
> arguing for any specific answer.  I am arguing for some *specification*
> here.
>
> These answers may follow from RFC2518 in your interpretation, but there
> have been and will be other interpretations.  Without clear guidance,
> some clients will assume that the URL that they query (the target of
> PROPFIND) is the one that MUST appear in the lockdiscovery property for
> that URL, and that if another URL appears the server must be broken.  
> Some clients will associate only one URL with each locktoken and be
> confused if the same locktoken appears on some other URL.   Some
> clients will assume that if a URL that they query is locked (and they
> have the lock token, etc) they can UNLOCK the same URL.   If server
> implementors aren't forced to make compatible choices, then we will
> have interoperability problems surrounding bindings.  We have
> specifications not just so we can explain the model, but also to make
> requirements of implementors.
>
> Lisa
>
> On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote:
>
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
> >
> >
> >
> >
> >
> > ------- Additional Comments From julian.reschke@greenbytes.de  
> > 2005-01-13 15:44 -------
> > I'm not sure why you keep re-opening this issue. Your particular
> > questions
> > answered in
> > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>, and
> > these answers follow from what RFC2518 already says.
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You reported the bug, or are watching the reporter.
>
>
--=_alternative 000C750885256F89_=-- From w3c-dist-auth-request@w3.org Thu Jan 13 21:36:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18567 for ; Thu, 13 Jan 2005 21:36:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpHJk-0007E2-PY for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 02:36:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpHJk-0007DH-GR for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 02:36:04 +0000 Received: from 216-239-45-4.google.com ([216.239.45.4]) by bart.w3.org with esmtp (Exim 4.34) id 1CpHJk-0000ul-9w for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 02:36:04 +0000 Received: by 216-239-45-4.google.com with SMTP id 7so99391zzb for ; Thu, 13 Jan 2005 18:35:33 -0800 (PST) Received: by 172.25.12.85 with SMTP id 5mr346867zzb; Thu, 13 Jan 2005 18:36:03 -0800 (PST) Received: by 172.25.12.185 with HTTP; Thu, 13 Jan 2005 18:35:33 -0800 (PST) Message-ID: <76f0ff97050113183547ce5d00@mail.google.com> Date: Thu, 13 Jan 2005 18:35:33 -0800 From: Neal Gafter Reply-To: Neal Gafter To: Geoffrey M Clemm Cc: Lisa Dusseault , Julian Reschke , "WebDAV WG))'" , w3c-dist-auth-request@w3.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org> Received-SPF: pass (bart.w3.org: domain of gafter+cb1016f13550e2c404@google.com designates 216.239.45.4 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/76f0ff97050113183547ce5d00@mail.google.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9248 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 02:36:04 +0000 Content-Transfer-Encoding: 7bit I don't see how the locking specification (2518) can possibly say anything about this, as there is no way without the bind spec of getting more than one URL to the same resource. On Thu, 13 Jan 2005 21:16:10 -0500, Geoffrey M Clemm wrote: > > Lisa, you say the same thing every time, and we give the same > response every time (:-). Locking behavior for RFC2518 features > (multiple URLs mapped to the same resource) needs to be defined by the > locking specification, not by the BIND specification. Otherwise, > there will be mass confusion when the locking specification says > one thing and the BIND specification says something else. > The question of whether or you can apply UNLOCK to a locked resource > using a URL other than the one the LOCK was applied to is an open > question for the locking specification, and the BIND protocol > is not the place to resolve that open locking question (the same question > applies to depth locks, which have nothing remotely to do with the > BIND protocol). > > OK, Joe, here's our first test of the "rough consensus" mechanism (:-). > > Cheers, > Geoff > > > Lisa wrote on 01/13/2005 07:01:41 PM: > > > > > > I keep re-opening this issue because the spec still doesn't say what > > the server MUST do or what the client must be prepared to handle. I > > don't care how you answer it on the list or in bugzilla; I am not even > > arguing for any specific answer. I am arguing for some *specification* > > here. > > > > These answers may follow from RFC2518 in your interpretation, but there > > have been and will be other interpretations. Without clear guidance, > > some clients will assume that the URL that they query (the target of > > PROPFIND) is the one that MUST appear in the lockdiscovery property for > > that URL, and that if another URL appears the server must be broken. > > Some clients will associate only one URL with each locktoken and be > > confused if the same locktoken appears on some other URL. Some > > clients will assume that if a URL that they query is locked (and they > > have the lock token, etc) they can UNLOCK the same URL. If server > > implementors aren't forced to make compatible choices, then we will > > have interoperability problems surrounding bindings. We have > > specifications not just so we can explain the model, but also to make > > requirements of implementors. > > > > Lisa > > > > On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote: > > > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > > > > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > > 2005-01-13 15:44 ------- > > > I'm not sure why you keep re-opening this issue. Your particular > > > questions > > > answered in > > > , and > > > these answers follow from what RFC2518 already says. > > > > > > > > > > > > ------- You are receiving this mail because: ------- > > > You reported the bug, or are watching the reporter. > > > > > From w3c-dist-auth-request@w3.org Thu Jan 13 21:53:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19636 for ; Thu, 13 Jan 2005 21:53:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpHaF-0004pz-4R for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 02:53:07 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpHaE-0004pV-T4 for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 02:53:06 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by bart.w3.org with esmtp (Exim 4.34) id 1CpHaE-0004Gk-MH for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 02:53:06 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0E2qZTb017873 for ; Thu, 13 Jan 2005 21:52:35 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0E2qZer278268 for ; Thu, 13 Jan 2005 21:52:35 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0E2qZx2002539 for ; Thu, 13 Jan 2005 21:52:35 -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 j0E2qZZX002535 for ; Thu, 13 Jan 2005 21:52:35 -0500 In-Reply-To: <76f0ff97050113183547ce5d00@mail.google.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 13 Jan 2005 21:52:41 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/13/2005 21:52:35, Serialize complete at 01/13/2005 21:52:35 Content-Type: multipart/alternative; boundary="=_alternative 000FCCFB85256F89_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/OF6423A600.A2A4808D-ON85256F89.000EBB65-85256F89.000FCCFD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 02:53:07 +0000 This is a multipart message in MIME format. --=_alternative 000FCCFB85256F89_= Content-Type: text/plain; charset="US-ASCII" Hi Neal, It's great to have someone other than usual culprits (:-) contribute to the discussion! Although the 2518 does not provide a standard method for mapping a resource to more than one URL, it does explicitly state that in the WebDAV model, multiple URLs may identify the same resource. In particular, section 5.1 of RFC2518 states: "Although implicit in [RFC2068] and [RFC2396], any resource, including collection resources, MAY be identified by more than one URI. For example, a resource could be identified by multiple HTTP URLs." So since having multiple URLs identify the same resource is part of the 2518 model, how locks behave when multiple URLs identify the same resource must be defined by the locking model for 2518. On the other hand, the BIND specification must specify the locking semantics of anything new that it introduces, which is the BIND, REBIND, and UNBIND methods. And the locking behavior of those methods is defined in the BIND specification. Cheers, Geoff Neal wrote on 01/13/2005 09:35:33 PM: > > I don't see how the locking specification (2518) can possibly say > anything about this, as there is no way without the bind spec of > getting more than one URL to the same resource. > > On Thu, 13 Jan 2005 21:16:10 -0500, Geoffrey M Clemm > wrote: > > > > Lisa, you say the same thing every time, and we give the same > > response every time (:-). Locking behavior for RFC2518 features > > (multiple URLs mapped to the same resource) needs to be defined by the > > locking specification, not by the BIND specification. Otherwise, > > there will be mass confusion when the locking specification says > > one thing and the BIND specification says something else. > > The question of whether or you can apply UNLOCK to a locked resource > > using a URL other than the one the LOCK was applied to is an open > > question for the locking specification, and the BIND protocol > > is not the place to resolve that open locking question (the same question > > applies to depth locks, which have nothing remotely to do with the > > BIND protocol). > > > > OK, Joe, here's our first test of the "rough consensus" mechanism (:-). > > > > Cheers, > > Geoff > > > > > > Lisa wrote on 01/13/2005 07:01:41 PM: > > > > > > > > > > I keep re-opening this issue because the spec still doesn't say what > > > the server MUST do or what the client must be prepared to handle. I > > > don't care how you answer it on the list or in bugzilla; I am not even > > > arguing for any specific answer. I am arguing for some *specification* > > > here. > > > > > > These answers may follow from RFC2518 in your interpretation, but there > > > have been and will be other interpretations. Without clear guidance, > > > some clients will assume that the URL that they query (the target of > > > PROPFIND) is the one that MUST appear in the lockdiscovery property for > > > that URL, and that if another URL appears the server must be broken. > > > Some clients will associate only one URL with each locktoken and be > > > confused if the same locktoken appears on some other URL. Some > > > clients will assume that if a URL that they query is locked (and they > > > have the lock token, etc) they can UNLOCK the same URL. If server > > > implementors aren't forced to make compatible choices, then we will > > > have interoperability problems surrounding bindings. We have > > > specifications not just so we can explain the model, but also to make > > > requirements of implementors. > > > > > > Lisa > > > > > > On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote: > > > > > > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > > > > > > > > > > > > > > > > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > > > > 2005-01-13 15:44 ------- > > > > I'm not sure why you keep re-opening this issue. Your particular > > > > questions > > > > answered in > > > > , and > > > > these answers follow from what RFC2518 already says. > > > > > > > > > > > > > > > > ------- You are receiving this mail because: ------- > > > > You reported the bug, or are watching the reporter. > > > > > > > > > --=_alternative 000FCCFB85256F89_= Content-Type: text/html; charset="US-ASCII"
Hi Neal,

It's great to have someone other than usual culprits (:-) contribute
to the discussion!

Although the 2518 does not provide a standard method for mapping a
resource to more than one URL, it does explicitly state that in the
WebDAV model, multiple URLs may identify the same resource.
In particular, section 5.1 of RFC2518 states:

"Although implicit in [RFC2068] and [RFC2396], any resource, including
 collection resources, MAY be identified by more than one URI. For example,
 a resource could be identified by multiple HTTP URLs."

So since having multiple URLs identify the same resource is part of
the 2518 model, how locks behave when multiple URLs identify the same
resource must be defined by the locking model for 2518.

On the other hand, the BIND specification must specify the locking
semantics of anything new that it introduces, which is the BIND, REBIND,
and UNBIND methods.  And the locking behavior of those methods is
defined in the BIND specification.

Cheers,
Geoff



Neal wrote on 01/13/2005 09:35:33 PM:

>
> I don't see how the locking specification (2518) can possibly say
> anything about this, as there is no way without the bind spec of
> getting more than one URL to the same resource.
>
> On Thu, 13 Jan 2005 21:16:10 -0500, Geoffrey M Clemm
> <geoffrey.clemm@us.ibm.com> wrote:
> >  
> > Lisa, you say the same thing every time, and we give the same
> > response every time (:-).  Locking behavior for RFC2518 features
> > (multiple URLs mapped to the same resource) needs to be defined by the
> > locking specification, not by the BIND specification.  Otherwise,
> > there will be mass confusion when the locking specification says
> > one thing and the BIND specification says something else.
> > The question of whether or you can apply UNLOCK to a locked resource
> > using a URL other than the one the LOCK was applied to is an open
> > question for the locking specification, and the BIND protocol
> > is not the place to resolve that open locking question (the same question
> > applies to depth locks, which have nothing remotely to do with the
> > BIND protocol).
> >  
> > OK, Joe, here's our first test of the "rough consensus" mechanism (:-).
> >  
> > Cheers,
> > Geoff
> >  
> >  
> > Lisa wrote on 01/13/2005 07:01:41 PM:
> >
> >  
> >  >
> >  > I keep re-opening this issue because the spec still doesn't say what
> >  > the server MUST do or what the client must be prepared to handle.  I
> >  > don't care how you answer it on the list or in bugzilla; I am not even
> >  > arguing for any specific answer.  I am arguing for some *specification*
> >  > here.
> >  >
> >  > These answers may follow from RFC2518 in your interpretation, but there
> >  > have been and will be other interpretations.  Without clear guidance,
> >  > some clients will assume that the URL that they query (the target of
> >  > PROPFIND) is the one that MUST appear in the lockdiscovery property for
> >  > that URL, and that if another URL appears the server must be broken.  
> >  > Some clients will associate only one URL with each locktoken and be
> >  > confused if the same locktoken appears on some other URL.   Some
> >  > clients will assume that if a URL that they query is locked (and they
> >  > have the lock token, etc) they can UNLOCK the same URL.   If server
> >  > implementors aren't forced to make compatible choices, then we will
> >  > have interoperability problems surrounding bindings.  We have
> >  > specifications not just so we can explain the model, but also to make
> >  > requirements of implementors.
> >  >
> >  > Lisa
> >  >
> >  > On Jan 13, 2005, at 3:44 PM, bugzilla@soe.ucsc.edu wrote:
> >  >
> >  > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
> >  > >
> >  > >
> >  > >
> >  > >
> >  > >
> >  > > ------- Additional Comments From julian.reschke@greenbytes.de  
> >  > > 2005-01-13 15:44 -------
> >  > > I'm not sure why you keep re-opening this issue. Your particular
> >  > > questions
> >  > > answered in
> >  > > <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>, and
> >  > > these answers follow from what RFC2518 already says.
> >  > >
> >  > >
> >  > >
> >  > > ------- You are receiving this mail because: -------
> >  > > You reported the bug, or are watching the reporter.
> >  >
> >  >
> >
>
--=_alternative 000FCCFB85256F89_=-- From w3c-dist-auth-request@w3.org Thu Jan 13 23:04:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23138 for ; Thu, 13 Jan 2005 23:04:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpIfY-0003c4-RE for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 04:02:40 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cp7sL-0005P0-89 for w3c-dist-auth@listhub.w3.org; Thu, 13 Jan 2005 16:31:09 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cp7r4-0005Ey-2L for w3c-dist-auth@w3.org; Thu, 13 Jan 2005 16:29:50 +0000 Received: (qmail invoked by alias); 13 Jan 2005 16:29:17 -0000 Received: from p50825059.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.80.89) by mail.gmx.net (mp016) with SMTP; 13 Jan 2005 17:29:17 +0100 X-Authenticated: #1915285 Message-ID: <41E6A1DA.8010601@gmx.de> Date: Thu, 13 Jan 2005 17:29:14 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elias Sinderson CC: Mike Lindsey , w3c-dist-auth@w3.org References: <522020a4050112160836afe9eb@mail.gmail.com> <41E69DE9.1000905@cse.ucsc.edu> In-Reply-To: <41E69DE9.1000905@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/41E6A1DA.8010601@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9250 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 04:02:40 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > > Mike Lindsey wrote: > >> [...] My conf output: >> [...] >> [...] access_log output for the failed mount: >> [...] 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "GET >> /_vti_inf.html HTTP/1.1" 404 346 >> 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "POST >> /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 360 >> 192.138.150.250 - - [12/Jan/2005:22:43:32 +0000] "OPTIONS /roam/mike >> HTTP/1.1" 200 - >> > Please correct me if I'm wrong, but this doesn't appear to be a DAV > issue. Note the differing locations in your DAV configuration > (/roam/mike/) and requests (/_vti_inf.html and > /_vti_bin/shtml.exe/_vti_rpc), where the requests return 404s (Not > Found). Also note that GET and POST won't really test your DAV > configuration, even if pointed at the DAV enabled area of your server. > As your configurations appear identical, you may wish to point your > Sunbird (DAV) client at /roam/mike to see if that works as expected. What we see is Windows trying to connect through Frontpage Server Extensions (which occurs when it thinks there is no WebDAV support). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jan 13 23:33:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24591 for ; Thu, 13 Jan 2005 23:33:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpJ8N-00040S-8L for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 04:32:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpJ8M-0003zj-Pi for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 04:32:26 +0000 Received: from wproxy.gmail.com ([64.233.184.203]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpJ8D-0004UX-6I for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 04:32:17 +0000 Received: by wproxy.gmail.com with SMTP id 37so188606wra for ; Thu, 13 Jan 2005 20:31:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZypfY68MTifBNfvx+WgC3PWcxAJyNPYGI3/heiaOkpf0ARj1Q22KRwxQ+DNUL1pIJPrK7go3vUt4XT/pAmFpx/D4M61vKaaDJuugWOV0oxhmZ2CtmYIAEdwqist1xDxD+Tcs334K8XYIxCuoDL88xI1073GnJGR+QKIv/X85oqI= Received: by 10.54.54.71 with SMTP id c71mr276799wra; Thu, 13 Jan 2005 20:31:55 -0800 (PST) Received: by 10.54.48.38 with HTTP; Thu, 13 Jan 2005 20:31:55 -0800 (PST) Message-ID: <522020a405011320317b72a367@mail.gmail.com> Date: Thu, 13 Jan 2005 20:31:55 -0800 From: Mike Lindsey Reply-To: Mike Lindsey To: w3c-dist-auth@w3.org In-Reply-To: <41E6CE30.8010009@email.arc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <522020a4050112160836afe9eb@mail.gmail.com> <41E69DE9.1000905@cse.ucsc.edu> <522020a405011311022f1103b7@mail.gmail.com> <41E6CE30.8010009@email.arc.nasa.gov> Received-SPF: pass (lisa.w3.org: domain of coyote@gmail.com designates 64.233.184.203 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: mod_dav and ie web folders issue X-Archived-At: http://www.w3.org/mid/522020a405011320317b72a367@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9251 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 04:32:27 +0000 Content-Transfer-Encoding: 7bit On Thu, 13 Jan 2005 11:38:24 -0800, Elias Sinderson wrote: > Unfortunately I'm not as familliar with the Windows implementation of > DAV as I am with the protocol specification iteself. However, it is tcpdump at the end.. > P.S. have you tried using other (non-MS) WebDAV clients? Can you recommend any that would allow me to mount a webdav share as a drive or folder on a windows box? tcpdump: tcpdump -xx -n -i 1 -p -ttt -vv port 80 > webdav.dump tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes 000000 IP (tos 0x0, ttl 116, id 45028, offset 0, flags [DF], length: 48) 67.174. 229.158.2119 > 64.71.143.243.80: S [tcp sum ok] 1157708351:1157708351(0) win 655 35 0x0000: 0090 27f6 493a 0030 71f0 1dfe 0800 4500 ..'.I:.0q.....E. 0x0010: 0030 afe4 4000 7406 5d5c 43ae e59e 4047 .0..@.t.]\C...@G 0x0020: 8ff3 0847 0050 4501 3a3f 0000 0000 7002 ...G.PE.:?....p. 0x0030: ffff 0225 0000 0204 0550 0101 0402 ...%.....P.... 000143 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 48) 64.71.143.2 43.80 > 67.174.229.158.2119: S [tcp sum ok] 1514121766:1514121766(0) ack 1157708 352 win 5840 0x0000: 0030 71f0 1dfe 0090 27f6 493a 0800 4500 .0q.....'.I:..E. 0x0010: 0030 0000 4000 4006 4141 4047 8ff3 43ae .0..@.@.AA@G..C. 0x0020: e59e 0050 0847 5a3f aa26 4501 3a40 7012 ...P.GZ?.&E.:@p. 0x0030: 16d0 e679 0000 0204 05b4 0101 0402 ...y.......... 022001 IP (tos 0x0, ttl 116, id 45029, offset 0, flags [DF], length: 40) 67.174. 229.158.2119 > 64.71.143.243.80: . [tcp sum ok] 1:1(0) ack 1 win 65535 0x0000: 0090 27f6 493a 0030 71f0 1dfe 0800 4500 ..'.I:.0q.....E. 0x0010: 0028 afe5 4000 7406 5d63 43ae e59e 4047 .(..@.t.]cC...@G 0x0020: 8ff3 0847 0050 4501 3a40 5a3f aa27 5010 ...G.PE.:@Z?.'P. 0x0030: ffff 2a0e 0000 0000 0000 0000 ..*......... 006161 IP (tos 0x0, ttl 116, id 45030, offset 0, flags [DF], length: 209) 67.174 .229.158.2119 > 64.71.143.243.80: P 1:170(169) ack 1 win 65535 0x0000: 0090 27f6 493a 0030 71f0 1dfe 0800 4500 ..'.I:.0q.....E. 0x0010: 00d1 afe6 4000 7406 5cb9 43ae e59e 4047 ....@.t.\.C...@G 0x0020: 8ff3 0847 0050 4501 3a40 5a3f aa27 5018 ...G.PE.:@Z?.'P. 0x0030: ffff e620 0000 4f50 5449 4f4e 5320 2f72 ......OPTIONS./r 0x0040: 6f61 6d20 oam. 000090 IP (tos 0x0, ttl 64, id 649, offset 0, flags [DF], length: 40) 64.71.143 .243.80 > 67.174.229.158.2119: . [tcp sum ok] 1:1(0) ack 170 win 6432 0x0000: 0030 71f0 1dfe 0090 27f6 493a 0800 4500 .0q.....'.I:..E. 0x0010: 0028 0289 4000 4006 3ec0 4047 8ff3 43ae .(..@.@.>.@G..C. 0x0020: e59e 0050 0847 5a3f aa27 4501 3ae9 5010 ...P.GZ?.'E.:.P. 0x0030: 1920 1045 0000 ...E.. 000873 IP (tos 0x0, ttl 64, id 650, offset 0, flags [DF], length: 328) 64.71.14 3.243.80 > 67.174.229.158.2119: P 1:289(288) ack 170 win 6432 0x0000: 0030 71f0 1dfe 0090 27f6 493a 0800 4500 .0q.....'.I:..E. 0x0010: 0148 028a 4000 4006 3d9f 4047 8ff3 43ae .H..@.@.=.@G..C. 0x0020: e59e 0050 0847 5a3f aa27 4501 3ae9 5018 ...P.GZ?.'E.:.P. 0x0030: 1920 6fef 0000 4854 5450 2f31 2e31 2032 ..o...HTTP/1.1.2 0x0040: 3030 204f 00.O 232931 IP (tos 0x0, ttl 116, id 45031, offset 0, flags [DF], length: 40) 67.174. 229.158.2119 > 64.71.143.243.80: . [tcp sum ok] 170:170(0) ack 289 win 65247 0x0000: 0090 27f6 493a 0030 71f0 1dfe 0800 4500 ..'.I:.0q.....E. 0x0010: 0028 afe7 4000 7406 5d61 43ae e59e 4047 .(..@.t.]aC...@G 0x0020: 8ff3 0847 0050 4501 3ae9 5a3f ab47 5010 ...G.PE.:.Z?.GP. 0x0030: fedf 2965 0000 0000 0000 0000 ..)e........ -- Mike Lindsey From w3c-dist-auth-request@w3.org Fri Jan 14 03:46:12 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25624 for ; Fri, 14 Jan 2005 03:46:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpN4L-0003gI-9t for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 08:44:33 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpN4K-0003f5-Tp for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 08:44:32 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CpN4B-0000G7-58 for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 08:44:23 +0000 Received: (qmail invoked by alias); 14 Jan 2005 08:43:58 -0000 Received: from p5485656A.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.101.106) by mail.gmx.net (mp004) with SMTP; 14 Jan 2005 09:43:58 +0100 X-Authenticated: #1915285 Message-ID: <41E7864A.4000804@gmx.de> Date: Fri, 14 Jan 2005 09:43:54 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en 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 (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41E7864A.4000804@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9252 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 08:44:33 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Hi Neal, > > It's great to have someone other than usual culprits (:-) contribute > to the discussion! +1. > Although the 2518 does not provide a standard method for mapping a > resource to more than one URL, it does explicitly state that in the > WebDAV model, multiple URLs may identify the same resource. > In particular, section 5.1 of RFC2518 states: > > "Although implicit in [RFC2068] and [RFC2396], any resource, including > collection resources, MAY be identified by more than one URI. For example, > a resource could be identified by multiple HTTP URLs." > > So since having multiple URLs identify the same resource is part of > the 2518 model, how locks behave when multiple URLs identify the same > resource must be defined by the locking model for 2518. > > On the other hand, the BIND specification must specify the locking > semantics of anything new that it introduces, which is the BIND, REBIND, > and UNBIND methods. And the locking behavior of those methods is > defined in the BIND specification. > > Cheers, > Geoff I'd also like to add that - RFC2616 (the base protocol that we extend) also includes this concept, - RFC3253 (versioning) speaks of bindings and some RFC3253 operations indeed can create additional bindings to a resource, thus it's really time to actually get the BIND spec out of the door :-), and - that just because you don't have a specific WebDAV method to explicitly create bindings that doesn't mean that you can't create them at all (for instance, a server that maps directly to an underlying POSIX filesystem would naturally expose file system hard links as WebDAV bindings). (That's similar to although only the unfinished REDIRECTREF spec defines an explicit method to create a redirect resource, you already see lots of HTTP resources that answer with 301/302 status codes, right...?). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 04:16:50 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27203 for ; Fri, 14 Jan 2005 04:16:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpNYW-0007qy-Qo for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 09:15:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpNYW-0007qU-KV for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 09:15:44 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CpNYM-0006SD-Rx for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 09:15:35 +0000 Received: (qmail invoked by alias); 14 Jan 2005 09:15:12 -0000 Received: from p5485656A.dip.t-dialin.net (EHLO [192.168.0.3]) (84.133.101.106) by mail.gmx.net (mp002) with SMTP; 14 Jan 2005 10:15:12 +0100 X-Authenticated: #1915285 Message-ID: <41E78D9C.5050601@gmx.de> Date: Fri, 14 Jan 2005 10:15:08 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: "WebDAV WG))'" References: <200501132344.j0DNiWbD020215@ietf.cse.ucsc.edu> <7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org> In-Reply-To: <7854D650-65BF-11D9-8F63-000A95B2BB72@osafoundation.org> 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-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41E78D9C.5050601@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9253 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 09:15:44 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I keep re-opening this issue because the spec still doesn't say what the > server MUST do or what the client must be prepared to handle. I don't > care how you answer it on the list or in bugzilla; I am not even arguing > for any specific answer. I am arguing for some *specification* here. Lisa, it would be helpful if you would indeed *read* my replies. See ..: "General statement: it's not the BIND spec's job to resolve open issues with RFC2518's defintion of locking. RFC2518 explicitly allows multiple URIs to be mapped to the same resource (see for instance section 5.1), thus if there's some doubt about lock semantics, it needs to be clarified in RFC2518bis. That being said, both questions can be answered by looking in RFC2518: - the value of the DAV:lockdiscovery property will be the same, as both bindings refer to the same resource, and the lock is on the resource (RFC2518, section 13.8) - UNLOCK removes the lock identified by the lock token from the resource identified by the request-URI (and all other resources included in the lock), so again, it doesn't matter to which binding the UNLOCK is applied (section 8.11)" So I *both* answered the actual questions *and* explained how it is indeed specified through RFC2518 and BIND. So in order to have a constructive discussion, you'd need to challenge these statements. > These answers may follow from RFC2518 in your interpretation, but there > have been and will be other interpretations. Without clear guidance, > some clients will assume that the URL that they query (the target of > PROPFIND) is the one that MUST appear in the lockdiscovery property for > that URL, and that if another URL appears the server must be broken. I don't know what you're talking about. Where is the URI supposed to appear inside the DAV:lockdiscovery element at all? We're talking about RFC2518 + BIND, not RFC2518bis, right? (see ) > Some clients will associate only one URL with each locktoken and be > confused if the same locktoken appears on some other URL. Some clients Then they are buggy according to RFC2518 (). Can you name a client that has this problem? > will assume that if a URL that they query is locked (and they have the > lock token, etc) they can UNLOCK the same URL. If server implementors They can. > aren't forced to make compatible choices, then we will have > interoperability problems surrounding bindings. We have specifications > not just so we can explain the model, but also to make requirements of > implementors. Nobody argues with that. Can we please get back to the question *what* you think is underspecified? Finally, a general note on "what to UNLOCK". A properly written client will apply UNLOCK to the URI where it originally applied the LOCK request to. It's supposed to keep this information anyway. Questions about what to UNLOCK in case of "lock stealing" (removing a lock created by a different client (instance)) are interesting but really about an edge case that should not occur during normal operation. It's fine to discuss this in the context of RFC2518bis (DAV:lockroot child element, for instance), but this has nothing to do whatsover with BIND. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 07:42:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03547 for ; Fri, 14 Jan 2005 07:42:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpQlK-000121-WE for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 12:41:11 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpQlK-00011Q-Gj for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 12:41:10 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by bart.w3.org with esmtp (Exim 4.34) id 1CpQlK-00052Q-9g for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 12:41:10 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0ECedLI031957 for ; Fri, 14 Jan 2005 07:40:39 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0ECed1o233330 for ; Fri, 14 Jan 2005 07:40:39 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0ECedio019883 for ; Fri, 14 Jan 2005 07:40: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 j0ECeddA019880 for ; Fri, 14 Jan 2005 07:40:39 -0500 In-Reply-To: <41E78D9C.5050601@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 14 Jan 2005 07:40:43 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/14/2005 07:40:38, Serialize complete at 01/14/2005 07:40:38 Content-Type: multipart/alternative; boundary="=_alternative 0045A2BE85256F89_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/OF7E0EA988.54FEA6B4-ON85256F89.00448F9B-85256F89.0045A2C2@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9254 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 12:41:10 +0000 This is a multipart message in MIME format. --=_alternative 0045A2BE85256F89_= Content-Type: text/plain; charset="US-ASCII" I agree with everything Julian says here, including the fact that RFC-2518 answers both of these questions. When I said that "there is an issue to be resolved", I was referring to a suggestion that RFC-2518bis change the semantics of RFC-2518 to require that an UNLOCK be applied to the request-URL of the original LOCK request, but my understanding is that the most recent consensus is that RFC-2518bis not make this change, and stay consistent with RFC-2518 and allow an UNLOCK request to be applied to any resource locked by the lock. Thus one of the two questions that Lisa states should be answered by the BIND spec is an issue being explicitly discussed in the context of RFC-2518, which illustrates why these issues need to be handled by RFC-2518bis (or preferably, by a separate specification that is devoted to locking). Cheers, Geoff Julian wrote on 01/14/2005 04:15:08 AM: > > Lisa Dusseault wrote: > > I keep re-opening this issue because the spec still doesn't say what the > > server MUST do or what the client must be prepared to handle. I don't > > care how you answer it on the list or in bugzilla; I am not even arguing > > for any specific answer. I am arguing for some *specification* here. > > Lisa, > > it would be helpful if you would indeed *read* my replies. See > ..: > > "General statement: it's not the BIND spec's job to resolve open issues > with RFC2518's defintion of locking. RFC2518 explicitly allows multiple > URIs to be mapped to the same resource (see for instance section 5.1), > thus if there's some doubt about lock semantics, it needs to be > clarified in RFC2518bis. > > That being said, both questions can be answered by looking in RFC2518: > > - the value of the DAV:lockdiscovery property will be the same, as both > bindings refer to the same resource, and the lock is on the resource > (RFC2518, section 13.8) > > - UNLOCK removes the lock identified by the lock token from the resource > identified by the request-URI (and all other resources included in the > lock), so again, it doesn't matter to which binding the UNLOCK is > applied (section 8.11)" > > So I *both* answered the actual questions *and* explained how it is > indeed specified through RFC2518 and BIND. So in order to have a > constructive discussion, you'd need to challenge these statements. > > > These answers may follow from RFC2518 in your interpretation, but there > > have been and will be other interpretations. Without clear guidance, > > some clients will assume that the URL that they query (the target of > > PROPFIND) is the one that MUST appear in the lockdiscovery property for > > that URL, and that if another URL appears the server must be broken. > > I don't know what you're talking about. Where is the URI supposed to > appear inside the DAV:lockdiscovery element at all? We're talking about > RFC2518 + BIND, not RFC2518bis, right? (see > ) > > > Some clients will associate only one URL with each locktoken and be > > confused if the same locktoken appears on some other URL. Some clients > > Then they are buggy according to RFC2518 > (). > Can you name a client that has this problem? > > > will assume that if a URL that they query is locked (and they have the > > lock token, etc) they can UNLOCK the same URL. If server implementors > > They can. > > > aren't forced to make compatible choices, then we will have > > interoperability problems surrounding bindings. We have specifications > > not just so we can explain the model, but also to make requirements of > > implementors. > > Nobody argues with that. Can we please get back to the question *what* > you think is underspecified? > > Finally, a general note on "what to UNLOCK". A properly written client > will apply UNLOCK to the URI where it originally applied the LOCK > request to. It's supposed to keep this information anyway. > > Questions about what to UNLOCK in case of "lock stealing" (removing a > lock created by a different client (instance)) are interesting but > really about an edge case that should not occur during normal operation. > It's fine to discuss this in the context of RFC2518bis (DAV:lockroot > child element, for instance), but this has nothing to do whatsover with > BIND. > > Best regards, Julian > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0045A2BE85256F89_= Content-Type: text/html; charset="US-ASCII"
I agree with everything Julian says here, including the fact that RFC-2518
answers both of these questions.  When I said that "there is an issue to be
resolved", I was referring to a suggestion that RFC-2518bis change the semantics
of RFC-2518 to require that an UNLOCK be applied to the request-URL of the
original LOCK request, but my understanding is that the most recent consensus
is that RFC-2518bis not make this change, and stay consistent with RFC-2518
and allow an UNLOCK request to be applied to any resource locked by the lock.
Thus one of the two questions that Lisa states should be answered by the
BIND spec is an issue being explicitly discussed in the context of RFC-2518,
which illustrates why these issues need to be handled by RFC-2518bis (or preferably,
by a separate specification that is devoted to locking).

Cheers,
Geoff

Julian wrote on 01/14/2005 04:15:08 AM:

>
> Lisa Dusseault wrote:
> > I keep re-opening this issue because the spec still doesn't say what the
> > server MUST do or what the client must be prepared to handle.  I don't
> > care how you answer it on the list or in bugzilla; I am not even arguing
> > for any specific answer.  I am arguing for some *specification* here.
>
> Lisa,
>
> it would be helpful if you would indeed *read* my replies. See
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>..:
>
> "General statement: it's not the BIND spec's job to resolve open issues
> with RFC2518's defintion of locking. RFC2518 explicitly allows multiple
> URIs to be mapped to the same resource (see for instance section 5.1),
> thus if there's some doubt about lock semantics, it needs to be
> clarified in RFC2518bis.
>
> That being said, both questions can be answered by looking in RFC2518:
>
> - the value of the DAV:lockdiscovery property will be the same, as both
> bindings refer to the same resource, and the lock is on the resource
> (RFC2518, section 13.8)
>
> - UNLOCK removes the lock identified by the lock token from the resource
> identified by the request-URI (and all other resources included in the
> lock), so again, it doesn't matter to which binding the UNLOCK is
> applied (section 8.11)"
>
> So I *both* answered the actual questions *and* explained how it is
> indeed specified through RFC2518 and BIND. So in order to have a
> constructive discussion, you'd need to challenge these statements.
>
> > These answers may follow from RFC2518 in your interpretation, but there
> > have been and will be other interpretations.  Without clear guidance,
> > some clients will assume that the URL that they query (the target of
> > PROPFIND) is the one that MUST appear in the lockdiscovery property for
> > that URL, and that if another URL appears the server must be broken.
>
> I don't know what you're talking about. Where is the URI supposed to
> appear inside the DAV:lockdiscovery element at all? We're talking about
> RFC2518 + BIND, not RFC2518bis, right? (see
> <http://greenbytes.de/tech/webdav/rfc2518.html#PROPERTY_lockdiscovery>)
>
> > Some clients will associate only one URL with each locktoken and be
> > confused if the same locktoken appears on some other URL.   Some clients
>
> Then they are buggy according to RFC2518
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>).
> Can you name a client that has this problem?
>
> > will assume that if a URL that they query is locked (and they have the
> > lock token, etc) they can UNLOCK the same URL.   If server implementors
>
> They can.
>
> > aren't forced to make compatible choices, then we will have
> > interoperability problems surrounding bindings.  We have specifications
> > not just so we can explain the model, but also to make requirements of
> > implementors.
>
> Nobody argues with that. Can we please get back to the question *what*
> you think is underspecified?
>
> Finally, a general note on "what to UNLOCK". A properly written client
> will apply UNLOCK to the URI where it originally applied the LOCK
> request to. It's supposed to keep this information anyway.
>
> Questions about what to UNLOCK in case of "lock stealing" (removing a
> lock created by a different client (instance)) are interesting but
> really about an edge case that should not occur during normal operation.
>   It's fine to discuss this in the context of RFC2518bis (DAV:lockroot
> child element, for instance), but this has nothing to do whatsover with
> BIND.
>
> Best regards, Julian
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0045A2BE85256F89_=-- From w3c-dist-auth-request@w3.org Fri Jan 14 11:12:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24557 for ; Fri, 14 Jan 2005 11:12:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpU1S-00036w-DK for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 16:10:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpU1S-00032w-18 for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 16:10:02 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CpU1R-0004Mw-M4 for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 16:10:01 +0000 Received: (qmail invoked by alias); 14 Jan 2005 16:09:29 -0000 Received: from p50825E45.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.69) by mail.gmx.net (mp012) with SMTP; 14 Jan 2005 17:09:29 +0100 X-Authenticated: #1915285 Message-ID: <41E7EEB3.5020209@gmx.de> Date: Fri, 14 Jan 2005 17:09:23 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: BIND issue 3.1_uuids (action item) X-Archived-At: http://www.w3.org/mid/41E7EEB3.5020209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9255 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 16:10:02 +0000 Content-Transfer-Encoding: 7bit Hi, see : "Action item: if draft-mealling-uuid-urn gets accepted in time, consider referencing it and using urn:uuid URIs instead of opaquelocktoken URIs. See IETF I-D Tracker." In fact, the draft *has* been approved (see ) and now is in the RFC Editor's publication queue: . Thus, I'd propose to a) to mention urn:uuid URIs in the description of DAV:resource-id, b) to use them in examples and c) add an informative reference to draft-mealling-uuid-urn Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 12:39:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00682 for ; Fri, 14 Jan 2005 12:39:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpVOs-0001VB-Ur for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 17:38:18 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpVOs-0001Uf-Hh for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 17:38:18 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpVOi-0004E3-KN for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 17:38:08 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0EHc8aa012689 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jan 2005 09:38:10 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09C5CB6B-6653-11D9-BFDD-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: " webdav" From: Lisa Dusseault Date: Fri, 14 Jan 2005 09:38:01 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/09C5CB6B-6653-11D9-BFDD-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9256 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 17:38:18 +0000 Content-Transfer-Encoding: 7bit Does this mean that we agree that some specification must describe binding/locking interaction? As long as some document says something like "The server MUST allow UNLOCK to work on any binding to a locked resource, given an otherwise well-formed and permissioned request" (some standards-track document, not an email list or bug db), the requirements for interoperability have minimally been met. Now let's discuss which specification should say these kinds of things. 1) Bindings spec should say it. This works great -- it's a small clarification to add to a document which already describes bindings, and since it depends on RFC2518 it's perfectly easy to add text to describe how bindings works with the features described in RFC2518. Then Bindings can go to RFC, depending only on other RFCs. Easy, done. 2) RFC2518 should say it. Oops, too late. As you point out, RFC2518 didn't fully specify bindings -- it only described that they might exist. As did RFC2616. This is pretty typical, similar to the way variants are described as being possible in RFC2616 but it doesn't fully describe how they work (e.g. with PUT). Without a full specification, such a feature (bindings without the Bindings draft, and variants today) is not fully interoperable -- bindings and variants may exist, but servers may handle them differently, and clients have no reliable way of authoring them. That's why we write a bindings spec, to fully specify how bindings work. 3) RFC2518bis should say it. Well that's not an RFC yet, so this is problematic. How can the Bindings draft go to RFC if it depends on something that's still a draft? And why would you *want* to block Bindings behind a draft to revise WebDAV? It's not necessary. Why would you want to create this dependency? 4) Write some other document on "Interactions between Bindings and Locking". This would be a companion to both the bindings specification and the locking specification but separate from both. If implementors remember to consult this, it's a fine place to put information which discusses the interaction between two features. Now Bindings has a dependency on another Internet-Draft, but this is a small one and should be easy to progress. Lisa On Jan 14, 2005, at 4:40 AM, Geoffrey M Clemm wrote: > I agree with everything Julian says here, including the fact that > RFC-2518 > answers both of these questions. When I said that "there is an issue > to > be > resolved", I was referring to a suggestion that RFC-2518bis change the > semantics > of RFC-2518 to require that an UNLOCK be applied to the request-URL of > the > original LOCK request, but my understanding is that the most recent > consensus > is that RFC-2518bis not make this change, and stay consistent with > RFC-2518 > and allow an UNLOCK request to be applied to any resource locked by the > lock. > Thus one of the two questions that Lisa states should be answered by > the > BIND spec is an issue being explicitly discussed in the context of > RFC-2518, > which illustrates why these issues need to be handled by RFC-2518bis > (or > preferably, > by a separate specification that is devoted to locking). > > Cheers, > Geoff > > Julian wrote on 01/14/2005 04:15:08 AM: > >> >> Lisa Dusseault wrote: >>> I keep re-opening this issue because the spec still doesn't say what > the >>> server MUST do or what the client must be prepared to handle. I >>> don't > >>> care how you answer it on the list or in bugzilla; I am not even > arguing >>> for any specific answer. I am arguing for some *specification* here. >> >> Lisa, >> >> it would be helpful if you would indeed *read* my replies. See >> ..: >> >> "General statement: it's not the BIND spec's job to resolve open >> issues >> with RFC2518's defintion of locking. RFC2518 explicitly allows >> multiple >> URIs to be mapped to the same resource (see for instance section 5.1), >> thus if there's some doubt about lock semantics, it needs to be >> clarified in RFC2518bis. >> >> That being said, both questions can be answered by looking in RFC2518: >> >> - the value of the DAV:lockdiscovery property will be the same, as >> both >> bindings refer to the same resource, and the lock is on the resource >> (RFC2518, section 13.8) >> >> - UNLOCK removes the lock identified by the lock token from the >> resource >> identified by the request-URI (and all other resources included in the >> lock), so again, it doesn't matter to which binding the UNLOCK is >> applied (section 8.11)" >> >> So I *both* answered the actual questions *and* explained how it is >> indeed specified through RFC2518 and BIND. So in order to have a >> constructive discussion, you'd need to challenge these statements. >> >>> These answers may follow from RFC2518 in your interpretation, but > there >>> have been and will be other interpretations. Without clear guidance, >>> some clients will assume that the URL that they query (the target of >>> PROPFIND) is the one that MUST appear in the lockdiscovery property > for >>> that URL, and that if another URL appears the server must be broken. >> >> I don't know what you're talking about. Where is the URI supposed to >> appear inside the DAV:lockdiscovery element at all? We're talking >> about >> RFC2518 + BIND, not RFC2518bis, right? (see >> > rfc2518.html#PROPERTY_lockdiscovery>) >> >>> Some clients will associate only one URL with each locktoken and be >>> confused if the same locktoken appears on some other URL. Some > clients >> >> Then they are buggy according to RFC2518 >> (). >> Can you name a client that has this problem? >> >>> will assume that if a URL that they query is locked (and they have >>> the > >>> lock token, etc) they can UNLOCK the same URL. If server > implementors >> >> They can. >> >>> aren't forced to make compatible choices, then we will have >>> interoperability problems surrounding bindings. We have > specifications >>> not just so we can explain the model, but also to make requirements >>> of > >>> implementors. >> >> Nobody argues with that. Can we please get back to the question *what* >> you think is underspecified? >> >> Finally, a general note on "what to UNLOCK". A properly written client >> will apply UNLOCK to the URI where it originally applied the LOCK >> request to. It's supposed to keep this information anyway. >> >> Questions about what to UNLOCK in case of "lock stealing" (removing a >> lock created by a different client (instance)) are interesting but >> really about an edge case that should not occur during normal >> operation. > >> It's fine to discuss this in the context of RFC2518bis (DAV:lockroot >> child element, for instance), but this has nothing to do whatsover >> with >> BIND. >> >> Best regards, Julian >> >> >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> From w3c-dist-auth-request@w3.org Fri Jan 14 12:43:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01001 for ; Fri, 14 Jan 2005 12:43:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpVSw-0002tN-2r for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 17:42:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpVSv-0002sZ-NR; Fri, 14 Jan 2005 17:42:29 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpVSm-0004wQ-3U; Fri, 14 Jan 2005 17:42:20 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0EHfwJX021767; Fri, 14 Jan 2005 12:41:58 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0EHfw1o177862; Fri, 14 Jan 2005 12:41:58 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0EHfwKJ006767; Fri, 14 Jan 2005 12:41:58 -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 j0EHfwYD006759; Fri, 14 Jan 2005 12:41:58 -0500 In-Reply-To: <41E7EEB3.5020209@gmx.de> To: Julian Reschke Cc: "'WebDAV'" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 14 Jan 2005 12:42:05 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/14/2005 12:41:57, Serialize complete at 01/14/2005 12:41:57 Content-Type: multipart/alternative; boundary="=_alternative 0061394885256F89_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.1_uuids (action item) X-Archived-At: http://www.w3.org/mid/OFEE43A949.1DA1EA1C-ON85256F89.006131A7-85256F89.0061394A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9257 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 17:42:30 +0000 This is a multipart message in MIME format. --=_alternative 0061394885256F89_= Content-Type: text/plain; charset="US-ASCII" Sounds good to me. Cheers, Geoff Julian wrote on 01/14/2005 11:09:23 AM: > > Hi, > > see > html#rfc.issue.3.1_uuids>: > > "Action item: if draft-mealling-uuid-urn gets accepted in time, consider > referencing it and using urn:uuid URIs instead of opaquelocktoken URIs. > See IETF I-D Tracker." > > In fact, the draft *has* been approved (see > >) > and now is in the RFC Editor's publication queue: > . > > Thus, I'd propose to > > a) to mention urn:uuid URIs in the description of DAV:resource-id, > b) to use them in examples and > c) add an informative reference to draft-mealling-uuid-urn > > Feedback appreciated, Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0061394885256F89_= Content-Type: text/html; charset="US-ASCII"
Sounds good to me.

Cheers,
Geoff

Julian wrote on 01/14/2005 11:09:23 AM:

>
> Hi,
>
> see
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#rfc.issue.3.1_uuids>:
>
> "Action item: if draft-mealling-uuid-urn gets accepted in time, consider
> referencing it and using urn:uuid URIs instead of opaquelocktoken URIs.
> See IETF I-D Tracker."
>
> In fact, the draft *has* been approved (see
> <https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9352
> >)
> and now is in the RFC Editor's publication queue:
> <http://rfc-editor.org/queue.html#mealling-uuid-urn>.
>
> Thus, I'd propose to
>
> a) to mention urn:uuid URIs in the description of DAV:resource-id,
> b) to use them in examples and
> c) add an informative reference to draft-mealling-uuid-urn
>
> Feedback appreciated, Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0061394885256F89_=-- From w3c-dist-auth-request@w3.org Fri Jan 14 12:59:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01756 for ; Fri, 14 Jan 2005 12:59:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpVik-0000Ar-Vv for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 17:58:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpVik-0000AH-Oc for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 17:58:50 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CpVia-0000Qy-VQ for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 17:58:41 +0000 Received: (qmail invoked by alias); 14 Jan 2005 17:58:17 -0000 Received: from p50825E45.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.69) by mail.gmx.net (mp003) with SMTP; 14 Jan 2005 18:58:17 +0100 X-Authenticated: #1915285 Message-ID: <41E80833.9080404@gmx.de> Date: Fri, 14 Jan 2005 18:58:11 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <09C5CB6B-6653-11D9-BFDD-000A95B2BB72@osafoundation.org> In-Reply-To: <09C5CB6B-6653-11D9-BFDD-000A95B2BB72@osafoundation.org> 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-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41E80833.9080404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9258 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 17:58:50 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Does this mean that we agree that some specification must describe > binding/locking interaction? As long as some document says something Yes. I think we only disagree about which spec, and whether the current language in RFC2518 is sufficient for now (which I think). > like "The server MUST allow UNLOCK to work on any binding to a locked > resource, given an otherwise well-formed and permissioned request" > (some standards-track document, not an email list or bug db), the > requirements for interoperability have minimally been met. But that's what RFC2518 already says (): "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail." Also note that this has an entry on RFC2518's official issue list ( Now let's discuss which specification should say these kinds of things. > > 1) Bindings spec should say it. This works great -- it's a small > clarification to add to a document which already describes bindings, > and since it depends on RFC2518 it's perfectly easy to add text to > describe how bindings works with the features described in RFC2518. > Then Bindings can go to RFC, depending only on other RFCs. Easy, done. Drawbacks: - makes the spec more complex - adds normative language about a feature which is *completely* orthogonal to BIND - risks conflicting specification in RFC2518bis > 2) RFC2518 should say it. Oops, too late. As you point out, RFC2518 > didn't fully specify bindings -- it only described that they might > exist. As did RFC2616. This is pretty typical, similar to the way Yes, but again, the language in RFC2518 is absolutely sufficient here. We're not talking about an IETF document going to "Full Standard", we're talking about "Proposed". > variants are described as being possible in RFC2616 but it doesn't > fully describe how they work (e.g. with PUT). Without a full > specification, such a feature (bindings without the Bindings draft, and > variants today) is not fully interoperable -- bindings and variants may > exist, but servers may handle them differently, and clients have no > reliable way of authoring them. That's why we write a bindings spec, > to fully specify how bindings work. In particular, we write the spec in a way that bindings fit well into the model established by HTTP and WebDAV, and thus *don't need* to specify their particular interaction with some optional (!) WebDAV features. > 3) RFC2518bis should say it. Well that's not an RFC yet, so this is Speaking of which, what is it's status? > problematic. How can the Bindings draft go to RFC if it depends on > something that's still a draft? And why would you *want* to block It wouldn't be able, but it doesn't, so this isn't an issue. > Bindings behind a draft to revise WebDAV? It's not necessary. Why > would you want to create this dependency? Nobody has suggested that (as far as I can tell). > 4) Write some other document on "Interactions between Bindings and > Locking". This would be a companion to both the bindings specification > and the locking specification but separate from both. If implementors > remember to consult this, it's a fine place to put information which > discusses the interaction between two features. Now Bindings has a > dependency on another Internet-Draft, but this is a small one and > should be easy to progress. Doesn't seem to be different from 1, except that it's an additional document. BTW: you forgot to mention option #5, which is to split out locking from RFC2518bis and try to get that published as "Proposed Standard" ASAP. Most of the work has already been done in . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 15:02:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09989 for ; Fri, 14 Jan 2005 15:02:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpXct-0004DP-HS for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 20:00:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpXcs-0004Cv-Uh for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 20:00:54 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by lisa.w3.org with esmtp (Exim 4.34) id 1CpXcj-0003Xp-8B for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 20:00:45 +0000 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jan 2005 12:54:03 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C14800E2C72B2@corp.webb.net> From: Joe Hildebrand Cc: webdav Date: Fri, 14 Jan 2005 12:54:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Received-SPF: none (lisa.w3.org: domain of JHildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/8D96EDA0AC04D31197B400A0C96C14800E2C72B2@corp.webb.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 20:00:55 +0000 > > like "The server MUST allow UNLOCK to work on any binding > to a locked > > resource, given an otherwise well-formed and permissioned request" > > (some standards-track document, not an email list or bug db), the > > requirements for interoperability have minimally been met. > > But that's what RFC2518 already says > (): > > "The UNLOCK method removes the lock identified by the lock > token in the Lock-Token request header from the Request-URI, > and all other resources included in the lock. If all > resources which have been locked under the submitted lock > token can not be unlocked then the UNLOCK request MUST fail." How about this. Section 2.3 of BIND has this language:
It might be thought that a COPY request with "Depth: 0" on a collection would duplicate its bindings, since bindings are part of the collection's state. This is not the case, however. The definition of Depth in [RFC2518] makes it clear that a "Depth: 0" request does not apply to a collection's members. Consequently, a COPY with "Depth: 0" does not duplicate the bindings contained by the collection.
And 1.2 has this:
The authors of this specification anticipate and recommend that future revisions of [RFC2518] will update the definition of the state of a collection to correspond to the definition in this document.
If there was an extra paragraph in BIND that pulled from the spirit of these two existing statements, could we move forward? Something like:
It might be thought that an UNLOCK request to a locked resource might unlock just that binding. This is not the case, however. The definition of UNLOCK in [RFC2518] makes it clear that the server MUST allow UNLOCK to work on any binding to a locked resource, given an otherwise well-formed and permissioned request. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior.
This doesn't change 2518. It doesn't over-specify. It provides guidance for implementors, and makes clear the relationship with 2518bis. -- Joe Hildebrand From w3c-dist-auth-request@w3.org Fri Jan 14 15:41:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15182 for ; Fri, 14 Jan 2005 15:41:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpYF4-0005pW-VV for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 20:40:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpYF4-0005p1-HV for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 20:40:22 +0000 Received: from [198.3.8.2] (helo=hq-ex2kgw2.filenet.fn.com) by lisa.w3.org with smtp (Exim 4.34) id 1CpYEu-0001C4-LD for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 20:40:12 +0000 Received: from hq-ex2kpo1.filenet.fn.com ([10.1.0.165]) by hq-ex2kgw2.filenet.fn.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Jan 2005 12:39:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Date: Fri, 14 Jan 2005 12:39:42 -0800 Message-ID: Thread-Topic: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. Thread-Index: AcT6c+WMgRkTjYVBRaiM1umU+NtEZgAASrUw From: "Fay, Chuck" To: "webdav" Cc: "Joe Hildebrand" X-OriginalArrivalTime: 14 Jan 2005 20:39:43.0351 (UTC) FILETIME=[2D6FE070:01C4FA79] Received-SPF: none (lisa.w3.org: domain of CFay@filenet.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/FBEB6CC95F05FC49A9446D797F7ADE5704186677@hq-ex2kpo1.filenet.fn.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9260 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 20:40:22 +0000 I like Joe's suggestion, but I would word it differently, because part of 2518's description of UNLOCK is flawed and misleading. Note that it says "The UNLOCK method removes the lock... from the Request-URI", not from the *resource* identified by the Request-URI. It is clearly stated elsewhere in 2518 that "locks apply to resources, not URIs," and the sentence on UNLOCK goes on to talk about "all other resources included in the lock." So the sentence is internally inconsistent. If one relied just on this misleading portion of the description of UNLOCK from 2518, one could mistakenly conclude that locks are on URIs, not resources, and hence an UNLOCK on a URI other than the one used in the original LOCK operation would fail. I think this is at the heart of Lisa's concern. So I would rework Joe's suggestion this way, so that it doesn't rely on the flawed definition of UNLOCK:
It might be thought that an UNLOCK request to a locked resource would unlock just the binding of the Request-URI. This is not the case, however. [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource, given an otherwise well-formed and permissioned request. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior.
--Chuck Fay, FileNet Corporation, Costa Mesa, CA phone: (714) 327-3513, fax: (714) 327-5076, email: cfay@filenet.com ----- Joe Hildebrand wrote: > > > like "The server MUST allow UNLOCK to work on any binding > > to a locked > > > resource, given an otherwise well-formed and permissioned request" > > > (some standards-track document, not an email list or bug db), the > > > requirements for interoperability have minimally been met. > > > > But that's what RFC2518 already says > > (): > > > > "The UNLOCK method removes the lock identified by the lock token in > > the Lock-Token request header from the Request-URI, and all other > > resources included in the lock. If all resources which have been > > locked under the submitted lock token can not be unlocked then the > > UNLOCK request MUST fail." > > > How about this. Section 2.3 of BIND has this language: > >
> It might be thought that a COPY request with "Depth: 0" on a > collection would duplicate its bindings, since bindings are part of > the collection's state. This is not the case, however. The > definition of Depth in [RFC2518] makes it clear that a "Depth: 0" > request does not apply to a collection's members. Consequently, a > COPY with "Depth: 0" does not duplicate the bindings > contained by the > collection. >
> > And 1.2 has this: > >
> The authors of this specification anticipate and > recommend that future revisions of [RFC2518] will update the > definition of the state of a collection to correspond to the > definition in this document. >
> > If there was an extra paragraph in BIND that pulled from the > spirit of these two existing statements, could we move > forward? Something like: > >
> It might be thought that an UNLOCK request to a locked resource > might unlock just that binding. This is not the case, > however. The > definition of UNLOCK in [RFC2518] makes it clear that the > server MUST > allow UNLOCK to work on any binding to a locked resource, given an > otherwise well-formed and permissioned request. The > authors of this > specification anticipate and recommend that future revisions of > [RFC2518] maintain this behavior. >
> > This doesn't change 2518. It doesn't over-specify. It > provides guidance for implementors, and makes clear the > relationship with 2518bis. > > -- > Joe Hildebrand From w3c-dist-auth-request@w3.org Fri Jan 14 15:45:55 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15507 for ; Fri, 14 Jan 2005 15:45:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpYJn-0007UN-Vr for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 20:45:15 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpYJn-0007Td-O7 for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 20:45:15 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CpYJn-00018j-CI for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 20:45:15 +0000 Received: (qmail invoked by alias); 14 Jan 2005 20:44:42 -0000 Received: from pD95357DC.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.87.220) by mail.gmx.net (mp003) with SMTP; 14 Jan 2005 21:44:42 +0100 X-Authenticated: #1915285 Message-ID: <41E82F32.6090308@gmx.de> Date: Fri, 14 Jan 2005 21:44:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "'WebDAV'" , w3c-dist-auth-request@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND issue 3.1_uuids (action item) X-Archived-At: http://www.w3.org/mid/41E82F32.6090308@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9261 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 20:45:15 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > Sounds good to me. > > Cheers, > Geoff OK, done in . As we're in WG-Last-Call: note that this change does not affect any normative language in the spec; it just adds the "uuid" URN namespace to the list of URI schemes suitable for usage in DAV:resource-ids (and it also uses it in the one example where the DAV:resource-id property appears). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 15:53:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15952 for ; Fri, 14 Jan 2005 15:53:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpYRY-0000uj-5W for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 20:53:16 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CpYRX-0000uA-Qs for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 20:53:15 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CpYRX-0002p9-F6 for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 20:53:15 +0000 Received: (qmail invoked by alias); 14 Jan 2005 20:52:43 -0000 Received: from pD95357DC.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.87.220) by mail.gmx.net (mp008) with SMTP; 14 Jan 2005 21:52:43 +0100 X-Authenticated: #1915285 Message-ID: <41E83113.6030607@gmx.de> Date: Fri, 14 Jan 2005 21:52:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fay, Chuck" CC: webdav , Joe Hildebrand 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/41E83113.6030607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9262 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 20:53:16 +0000 Content-Transfer-Encoding: 7bit Fay, Chuck wrote: > I like Joe's suggestion, but I would word it differently, because part > of 2518's description of UNLOCK is flawed and misleading. Note that it > says "The UNLOCK method removes the lock... from the Request-URI", not > from the *resource* identified by the Request-URI. It is clearly stated > elsewhere in 2518 that "locks apply to resources, not URIs," and the > sentence on UNLOCK goes on to talk about "all other resources included > in the lock." So the sentence is internally inconsistent. If one > relied just on this misleading portion of the description of UNLOCK from > 2518, one could mistakenly conclude that locks are on URIs, not > resources, and hence an UNLOCK on a URI other than the one used in the > original LOCK operation would fail. I think this is at the heart of > Lisa's concern. > > So I would rework Joe's suggestion this way, so that it doesn't rely on > the flawed definition of UNLOCK: > >
> It might be thought that an UNLOCK request to a locked resource > would unlock just the binding of the Request-URI. This is not > the case, however. [RFC2518] clearly states that locks are on > resources, not URIs, so the server MUST allow UNLOCK to be used > to unlock a locked resource through any binding to that resource, > given an otherwise well-formed and permissioned request. The > authors of this specification anticipate and recommend that future > revisions of [RFC2518] maintain this behavior. >
I like this better, as it actually attempts to give a reason *why* somebody would think that. Thinking of it, the language could be even more precise here. I'd also prefer to lose the part about "given an otherwise well-formed and permissioned request" because that IMHO is just fluff and distracting (of course a LOCK will fail when there's something else wrong with the request or the state of the resource). Proposal: "Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the binding of the Request-URI. This is not the case, however. Section 6 of [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior." Best regards, Julian PS: great to see you back on the mailing list, Chuck. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 14 16:54:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28041 for ; Fri, 14 Jan 2005 16:54:20 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpZN7-0003gQ-T9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 21:52:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpZN7-0003fm-Do for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 21:52:45 +0000 Received: from mn.gcsu.edu ([168.16.211.63] helo=websh1.gcsu.edu) by lisa.w3.org with esmtp (Exim 4.34) id 1CpZMx-0005YA-Mq for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 21:52:35 +0000 Received: from mn.gcsu.edu(168.16.211.63) by websh1.gcsu.edu via csmap id c8ff195a_6678_11d9_95c0_00304811f47f_19899; Fri, 14 Jan 2005 17:08:14 -0500 (EST) Received: from websh1.gcsu.edu (sleepy.gcsu.edu [168.16.213.98]) by mn.gcsu.edu (Switch-3.1.0/Switch-3.1.0) with ESMTP id j0ELqC9c015333 for ; Fri, 14 Jan 2005 16:52:13 -0500 Received: from sleepy.gcsu.edu(168.16.213.98) by websh1.gcsu.edu via csmap id b6635a22_6678_11d9_8d42_00304811f47f_2117; Fri, 14 Jan 2005 17:07:43 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Fri, 14 Jan 2005 16:52:09 -0500 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/html; charset="us-ascii" Received-SPF: none (lisa.w3.org: domain of frank.lowney@gcsu.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Goliath, MacOS X Client and WebCT Vista X-Archived-At: http://www.w3.org/mid/p0620071dbe0dee411d73@%5B168.16.213.98%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9263 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 21:52:45 +0000 Goliath, MacOS X Client and WebCT Vista
I tried to put this question directly to tbednarz@webdav.org (this address comes from the mailto: tag on the bottom of the page at: http://www.webdav.org/goliath/) but the message was bounced.  If anyone here can forward this to Thomas, I would appreciate it.

As well, if anyone here can reply to any of all of this query, that would be appreciated too.

Thanks in advance for any help on this.

-------------------------- msg to forward -------------------------

Hello,

In our university system (Georgia), we use an enterprise level Learning Management System called "WebCT Vista" which supports WebDAV in addition to traditional/classic HTTP upload methods (see http://www.webct.com/vista).

I'm one of the few Vista Institutional Admins who are also Mac users so have been asked to look into problems that have been reported by Mac users of the system and investigated by WebCT technical support personnel (see report quoted below). 

Goliath was identified as a solution to a problem with the MacOS X client having to do with its behavior in updating files that have been modified (e.g. edited).  Apparently, the MacOS X client deletes and recreates the file which destroys important metadata on the server (IMS ContentID) and Goliath (as well as many other WebDAV clients) does not.

Unfortunately, we cannot use Goliath instead of the MacOS X client because port 21 is not available to our students (fire wall) and is needed by Goliath.  This claim seemed strange to me because I had thought that all WebDAV clients used HTTP port 80 alone.  Is this not the case?

WebCT Vista operates a bit differently than most other WebDAV-enabled servers in that it generates the URI that client apps need.  Here's an actual example:

http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-3283261001.flowney/University+System+of+Georgia/Georgia+College+and+State+University/EIS+Testing/QuickTime+Test+Site/QuickTime+Streaming+(Sect.+01)/Section+Content

Obviously, the length and complexity of these URIs makes such a practice necessary.

Now for my question.

As far as you know, are the statements below accurate?  Whatever insights you'd care to share will be greatly appreciated. 

------------------- from WebCT Support --------------------

Mac Finder's functionality causes it to delete and recreate a file when
uploading an updated version. As a result, the Content ID of the file
will change, and all links to that file will be broken. This is an
issue with Mac Finder.

Goliath, a WebDAV client for Macintosh, does not have this issue, and
was recommended to be used instead of Mac Finder. However, Goliath does
not function correctly with Georgia's Vista instance because it needs to
work through port 21, which is blocked at the firewall.

Mac Finder's WebDAV behaviour does not match
that of any other WebDAV client we have tested with.  Finder is the only
one I know of so far that deletes and recreates a brand new file when uploading
an updated version of a file.  All other tested WebDAV clients open the
existing file on the server and replace the contents.  Given that we don't
have Partner, or Higher Escalation status with Apple, a possible solution is to
have both USG and WebCT log a ticket with Apple Customer Support on this
issue.  Depending on how much hardware and software that is purchased and
deployed on the Georgia campuses, USG may have more influence than WebCT on
Apple.
--
=====================================================================
Dr. Frank Lowney  frank.lowney@gcsu.edu
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology,
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
NOTICE: Please be advised that I am hearing impaired and communicate most effectively via e-mail.  Follow-up summaries of telephone conversations by e-mail are most appreciated.
=====================================================================
We don't make instruction effective, we make effective instruction more accessible.
From w3c-dist-auth-request@w3.org Fri Jan 14 18:21:58 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06281 for ; Fri, 14 Jan 2005 18:21:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cpak3-0002K5-59 for w3c-dist-auth-dist@listhub.w3.org; Fri, 14 Jan 2005 23:20:31 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cpak2-0002JH-D9 for w3c-dist-auth@listhub.w3.org; Fri, 14 Jan 2005 23:20:30 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Cpajs-0003w0-Kw for w3c-dist-auth@w3.org; Fri, 14 Jan 2005 23:20:20 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Jan 2005 15:19:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Fri, 14 Jan 2005 15:19:57 -0800 To: Frank Lowney X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 14 Jan 2005 23:19:58.0134 (UTC) FILETIME=[904B5560:01C4FA8F] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Goliath, MacOS X Client and WebCT Vista X-Archived-At: http://www.w3.org/mid/CE45F94C-6682-11D9-8831-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9264 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jan 2005 23:20:31 +0000 Content-Transfer-Encoding: quoted-printable Goliath is not limited to port 21. In fact, port 21 is generally used =20= for FTP, so it is unlikely that it would be used for DAV (or HTTP). I think =20 there's a Windows FTP client called Goliath, so maybe that's the source of the confusion. -brian briank@xythos.com On Jan 14, 2005, at 1:52 PM, Frank Lowney wrote: > I tried to put this question directly to tbednarz@webdav.org (this =20 > address comes from the mailto: tag on the bottom of the page at: =20 > http://www.webdav.org/goliath/) but the message was bounced.=A0 If =20 > anyone here can forward this to Thomas, I would appreciate it. > > As well, if anyone here can reply to any of all of this query, that =20= > would be appreciated too. > > Thanks in advance for any help on this. > > -------------------------- msg to forward ------------------------- > > Hello, > > In our university system (Georgia), we use an enterprise level =20 > Learning Management System called "WebCT Vista" which supports WebDAV =20= > in addition to traditional/classic HTTP upload methods (see =20 > http://www.webct.com/vista). > > I'm one of the few Vista Institutional Admins who are also Mac users =20= > so have been asked to look into problems that have been reported by =20= > Mac users of the system and investigated by WebCT technical support =20= > personnel (see report quoted below).=A0 > > Goliath was identified as a solution to a problem with the MacOS X =20 > client having to do with its behavior in updating files that have been = =20 > modified (e.g. edited).=A0 Apparently, the MacOS X client deletes and =20= > recreates the file which destroys important metadata on the server =20 > (IMS ContentID) and Goliath (as well as many other WebDAV clients) =20 > does not. > > Unfortunately, we cannot use Goliath instead of the MacOS X client =20 > because port 21 is not available to our students (fire wall) and is =20= > needed by Goliath.=A0 This claim seemed strange to me because I had =20= > thought that all WebDAV clients used HTTP port 80 alone.=A0 Is this = not =20 > the case? > > WebCT Vista operates a bit differently than most other WebDAV-enabled =20= > servers in that it generates the URI that client apps need.=A0 Here's = an =20 > actual example: > > http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055=20 > -3283261001.flowney/University+System+of+Georgia/=20 > Georgia+College+and+State+University/EIS+Testing/QuickTime+Test+Site/=20= > QuickTime+Streaming+(Sect.+01)/Section+Content > > Obviously, the length and complexity of these URIs makes such a =20 > practice necessary. > > Now for my question. > > As far as you know, are the statements below accurate?=A0 Whatever =20 > insights you'd care to share will be greatly appreciated.=A0 > > ------------------- from WebCT Support -------------------- > > Mac Finder's functionality causes it to delete and recreate a file = when > uploading an updated version. As a result, the Content ID of the file > will change, and all links to that file will be broken. This is an > issue with Mac Finder. > > Goliath, a WebDAV client for Macintosh, does not have this issue, and > was recommended to be used instead of Mac Finder. However, Goliath =20= > does > not function correctly with Georgia's Vista instance because it needs = =20 > to > work through port 21, which is blocked at the firewall. > > Mac Finder's WebDAV behaviour does not match > that of any other WebDAV client we have tested with.=A0 Finder is the = =20 > only > one I know of so far that deletes and recreates a brand new file when = =20 > uploading > an updated version of a file.=A0 All other tested WebDAV clients open = =20 > the > existing file on the server and replace the contents.=A0 Given that = we =20 > don't > have Partner, or Higher Escalation status with Apple, a possible =20 > solution is to > have both USG and WebCT log a ticket with Apple Customer Support on =20= > this > issue.=A0 Depending on how much hardware and software that is = purchased =20 > and > deployed on the Georgia campuses, USG may have more influence than =20= > WebCT on > Apple. > --=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Frank Lowney=A0 frank.lowney@gcsu.edu > =A0=A0=A0 Director, Electronic Instructional Services, a unit of the > =A0=A0=A0 Office of Information and Instructional Technology, > =A0=A0=A0 Professional Pages: http://www.gcsu.edu/oiit/eis/ > =A0=A0=A0 Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > NOTICE: Please be advised that I am hearing impaired and communicate =20= > most effectively via e-mail.=A0 Follow-up summaries of telephone =20 > conversations by e-mail are most appreciated. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > We don't make instruction effective, we make effective instruction =20= > more accessible. > > From w3c-dist-auth-request@w3.org Fri Jan 14 23:06:42 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24002 for ; Fri, 14 Jan 2005 23:06:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CpfBR-0000I9-6k for w3c-dist-auth-dist@listhub.w3.org; Sat, 15 Jan 2005 04:05:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CpfBQ-0000HP-I0 for w3c-dist-auth@listhub.w3.org; Sat, 15 Jan 2005 04:05:04 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1CpfBG-0001Dg-HQ for w3c-dist-auth@w3.org; Sat, 15 Jan 2005 04:04:54 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0F44XJX013160 for ; Fri, 14 Jan 2005 23:04:33 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0F44X1o288004 for ; Fri, 14 Jan 2005 23:04:33 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0F44WbX015531 for ; Fri, 14 Jan 2005 23:04:33 -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 j0F44WUn015528 for ; Fri, 14 Jan 2005 23:04:32 -0500 In-Reply-To: <41E83113.6030607@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 14 Jan 2005 23:04:30 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/14/2005 23:04:32, Serialize complete at 01/14/2005 23:04:32 Content-Type: multipart/alternative; boundary="=_alternative 0016622085256F8A_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/OF5206F600.798B361A-ON85256F8A.0015EE0C-85256F8A.00166222@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9265 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Jan 2005 04:05:05 +0000 This is a multipart message in MIME format. --=_alternative 0016622085256F8A_= Content-Type: text/plain; charset="US-ASCII" I agree that it would be desireable to add the statement Joe suggests to the binding specification, and I like the editorial changes suggested by Chuck and Julian. Cheers, Geoff Julian wrote on 01/14/2005 03:52:35 PM: > > Fay, Chuck wrote: > > I like Joe's suggestion, but I would word it differently, because part > > of 2518's description of UNLOCK is flawed and misleading. Note that it > > says "The UNLOCK method removes the lock... from the Request-URI", not > > from the *resource* identified by the Request-URI. It is clearly stated > > elsewhere in 2518 that "locks apply to resources, not URIs," and the > > sentence on UNLOCK goes on to talk about "all other resources included > > in the lock." So the sentence is internally inconsistent. If one > > relied just on this misleading portion of the description of UNLOCK from > > 2518, one could mistakenly conclude that locks are on URIs, not > > resources, and hence an UNLOCK on a URI other than the one used in the > > original LOCK operation would fail. I think this is at the heart of > > Lisa's concern. > > > > So I would rework Joe's suggestion this way, so that it doesn't rely on > > the flawed definition of UNLOCK: > > > >
> > It might be thought that an UNLOCK request to a locked resource > > would unlock just the binding of the Request-URI. This is not > > the case, however. [RFC2518] clearly states that locks are on > > resources, not URIs, so the server MUST allow UNLOCK to be used > > to unlock a locked resource through any binding to that resource, > > given an otherwise well-formed and permissioned request. The > > authors of this specification anticipate and recommend that future > > revisions of [RFC2518] maintain this behavior. > >
> > I like this better, as it actually attempts to give a reason *why* > somebody would think that. Thinking of it, the language could be even > more precise here. I'd also prefer to lose the part about "given an > otherwise well-formed and permissioned request" because that IMHO is > just fluff and distracting (of course a LOCK will fail when there's > something else wrong with the request or the state of the resource). > > Proposal: > > "Due to the specific language used in section 8.11 of [RFC2518], it > might be thought that an UNLOCK request to a locked resource would > unlock just the binding of the Request-URI. This is not the case, > however. Section 6 of [RFC2518] clearly states that locks are on > resources, not URIs, so the server MUST allow UNLOCK to be used > to unlock a locked resource through any binding to that resource. The > authors of this specification anticipate and recommend that future > revisions of [RFC2518] maintain this behavior." > > Best regards, Julian > > PS: great to see you back on the mailing list, Chuck. > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0016622085256F8A_= Content-Type: text/html; charset="US-ASCII"
I agree that it would be desireable to add the statement Joe suggests
to the binding specification, and I like the editorial changes suggested
by Chuck and Julian.

Cheers,
Geoff

Julian wrote on 01/14/2005 03:52:35 PM:

>
> Fay, Chuck wrote:
> > I like Joe's suggestion, but I would word it differently, because part
> > of 2518's description of UNLOCK is flawed and misleading.  Note that it
> > says "The UNLOCK method removes the lock... from the Request-URI", not
> > from the *resource* identified by the Request-URI.  It is clearly stated
> > elsewhere in 2518 that "locks apply to resources, not URIs," and the
> > sentence on UNLOCK goes on to talk about "all other resources included
> > in the lock."  So the sentence is internally inconsistent.  If one
> > relied just on this misleading portion of the description of UNLOCK from
> > 2518, one could mistakenly conclude that locks are on URIs, not
> > resources, and hence an UNLOCK on a URI other than the one used in the
> > original LOCK operation would fail.  I think this is at the heart of
> > Lisa's concern.
> >
> > So I would rework Joe's suggestion this way, so that it doesn't rely on
> > the flawed definition of UNLOCK:
> >
> > <blockquote>
> >    It might be thought that an UNLOCK request to a locked resource
> >    would unlock just the binding of the Request-URI.  This is not
> >    the case, however. [RFC2518] clearly states that locks are on
> >    resources, not URIs, so the server MUST allow UNLOCK to be used
> >    to unlock a locked resource through any binding to that resource,
> >    given an otherwise well-formed and permissioned request.  The
> >    authors of this specification anticipate and recommend that future
> >    revisions of [RFC2518] maintain this behavior.
> > </blockquote>
>
> I like this better, as it actually attempts to give a reason *why*
> somebody would think that. Thinking of it, the language could be even
> more precise here. I'd also prefer to lose the part about "given an
> otherwise well-formed and permissioned request" because that IMHO is
> just fluff and distracting (of course a LOCK will fail when there's
> something else wrong with the request or the state of the resource).
>
> Proposal:
>
> "Due to the specific language used in section 8.11 of [RFC2518], it
> might be thought that an UNLOCK request to a locked resource would
> unlock just the binding of the Request-URI.  This is not the case,
> however.  Section 6 of [RFC2518] clearly states that locks are on
> resources, not URIs, so the server MUST allow UNLOCK to be used
> to unlock a locked resource through any binding to that resource.  The
> authors of this specification anticipate and recommend that future
> revisions of [RFC2518] maintain this behavior."
>
> Best regards, Julian
>
> PS: great to see you back on the mailing list, Chuck.
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0016622085256F8A_=-- From w3c-dist-auth-request@w3.org Tue Jan 18 14:41:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23578 for ; Tue, 18 Jan 2005 14:41:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CqzAt-0000dh-Gq for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 19:37:59 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CqzAs-0000dC-Rx for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 19:37:58 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CqzAs-0004pW-H0 for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 19:37:58 +0000 Received: (qmail invoked by alias); 18 Jan 2005 19:37:23 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp015) with SMTP; 18 Jan 2005 20:37:23 +0100 X-Authenticated: #1915285 Message-ID: <41ED656B.4090801@gmx.de> Date: Tue, 18 Jan 2005 20:37:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/41ED656B.4090801@gmx.de To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9266 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 19:37:59 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I agree that it would be desireable to add the statement Joe suggests > to the binding specification, and I like the editorial changes suggested > by Chuck and Julian. > > Cheers, > Geoff Ok, so do we have consensus to add the following subsection to section 2 ()? 2.x UNLOCK and Bindings Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the binding of the Request-URI. This is not the case, however. Section 6 of [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 15:02:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25260 for ; Tue, 18 Jan 2005 15:02:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CqzXk-0001wH-41 for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 20:01:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CqzXj-0001vn-HQ for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 20:01:35 +0000 Received: from gate.arc.nasa.gov ([128.102.102.51]) by bart.w3.org with esmtp (Exim 4.34) id 1CqzXj-0003Es-7h for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 20:01:35 +0000 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0IK1TP02816 for ; Tue, 18 Jan 2005 12:01:29 -0800 (PST) Message-ID: <41ED6B18.9080500@cse.ucsc.edu> Date: Tue, 18 Jan 2005 12:01:28 -0800 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <41ED656B.4090801@gmx.de> In-Reply-To: <41ED656B.4090801@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41ED6B18.9080500@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9267 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 20:01:36 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Ok, so do we have consensus to add the following [...]? I've been considering the various options suggested to address this issue since it was raised, along with the various implications. For the record, I don't have any problem with the suggested language (below) being added to the BIND specification as it seems to address Lisas' concerns, while leaving the actual locking behavior specified in the core WebDAV specification. For future reference, I would also like to see similar clarification / specification of locking behavior in the presence of multiple bindings to a resource appear in either 2518bis or a separate locking specification. My preference, once again, is for locking to be broken out into a separate specification, as suggested and discussed previously on this list. I believe that there was /rough concensus/ on that approach the last time it came up. Cheers, Elias _________________________ > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of [RFC2518], it > might be thought that an UNLOCK request to a locked resource would > unlock just the binding of the Request-URI. This is not the case, > however. Section 6 of [RFC2518] clearly states that locks are on > resources, not URIs, so the server MUST allow UNLOCK to be used to > unlock a locked resource through any binding to that resource. The > authors of this specification anticipate and recommend that future > revisions of [RFC2518] maintain this behavior. From w3c-dist-auth-request@w3.org Tue Jan 18 15:10:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26471 for ; Tue, 18 Jan 2005 15:10:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CqzfH-0003dq-Cs for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 20:09:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CqzfG-0003cj-Uv for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 20:09:22 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CqzfG-0004Xf-JX for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 20:09:22 +0000 Received: (qmail invoked by alias); 18 Jan 2005 20:08:50 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp015) with SMTP; 18 Jan 2005 21:08:50 +0100 X-Authenticated: #1915285 Message-ID: <41ED6CCB.8070703@gmx.de> Date: Tue, 18 Jan 2005 21:08:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <41ED656B.4090801@gmx.de> <41ED6B18.9080500@cse.ucsc.edu> In-Reply-To: <41ED6B18.9080500@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41ED6CCB.8070703@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9268 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 20:09:23 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > I've been considering the various options suggested to address this > issue since it was raised, along with the various implications. For the > record, I don't have any problem with the suggested language (below) > being added to the BIND specification as it seems to address Lisas' > concerns, while leaving the actual locking behavior specified in the > core WebDAV specification. Thanks. > For future reference, I would also like to see similar clarification / > specification of locking behavior in the presence of multiple bindings > to a resource appear in either 2518bis or a separate locking > specification. My preference, once again, is for locking to be broken > out into a separate specification, as suggested and discussed previously > on this list. I believe that there was /rough concensus/ on that > approach the last time it came up. There was definitively a lot of support, but I'm not sure I'd call it "rough consensus". Anyway, as RFC2518bis seems to be stuck (little progress in the last year and no progress at all in the last six months), it makes a lot of sense to put that option back on the table. On the other hand, I don't want to distract from the BIND last-call, so maybe we should discuss this in a few weeks. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 16:50:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10926 for ; Tue, 18 Jan 2005 16:50:22 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr1DW-0003g1-FQ for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 21:48:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr1DV-0003fX-Vv for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 21:48:49 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr1DM-0006yK-3h for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 21:48:40 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 13:48:15 -0800 In-Reply-To: <41ED656B.4090801@gmx.de> References: <41ED656B.4090801@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: Brian Korver Date: Tue, 18 Jan 2005 13:48:15 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 18 Jan 2005 21:48:15.0602 (UTC) FILETIME=[6A2E9520:01C4FDA7] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/A86D8B38-699A-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9269 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 21:48:50 +0000 Content-Transfer-Encoding: 7bit Seems like good text to add. -brian briank@xythos.com On Jan 18, 2005, at 11:37 AM, Julian Reschke wrote: > Ok, > > so do we have consensus to add the following subsection to section 2 > ( latest.html#overview.of.bindings>)? > > > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of [RFC2518], it > might be thought that an UNLOCK request to a locked resource would > unlock just the binding of the Request-URI. This is not the case, > however. Section 6 of [RFC2518] clearly states that locks are on > resources, not URIs, so the server MUST allow UNLOCK to be used to > unlock a locked resource through any binding to that resource. The > authors of this specification anticipate and recommend that future > revisions of [RFC2518] maintain this behavior. > > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Tue Jan 18 17:19:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12730 for ; Tue, 18 Jan 2005 17:19:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr1gd-0005Nt-Ro for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 22:18:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr1gd-0005NP-BG for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 22:18:55 +0000 Received: from filenet-gw.filenet.com ([198.3.8.1] helo=hq-ex2kgw2.filenet.fn.com) by bart.w3.org with smtp (Exim 4.34) id 1Cr1gd-0000TD-4w for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 22:18:55 +0000 Received: from hq-ex2kpo1.filenet.fn.com ([10.1.0.165]) by hq-ex2kgw2.filenet.fn.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 14:18:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Date: Tue, 18 Jan 2005 14:18:23 -0800 Message-ID: Thread-Topic: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. Thread-Index: AcT9lZd72AQCGul+TYyWsc/yTZ52HgAFOmzw From: "Fay, Chuck" To: "Julian Reschke" , X-OriginalArrivalTime: 18 Jan 2005 22:18:23.0774 (UTC) FILETIME=[9FEFBBE0:01C4FDAB] Received-SPF: none (bart.w3.org: domain of CFay@filenet.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/FBEB6CC95F05FC49A9446D797F7ADE5704186A99@hq-ex2kpo1.filenet.fn.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9270 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 22:18:55 +0000 I would like to revise and expand on some wording that I introduced in the first sentence, to make it clearer: 2.x UNLOCK and Bindings Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the particular binding expressed by the Request-URI, rather than the resource identified by that URI. This is not the case, however. Section 6 of [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior. Julian Reschke wrote: > Ok, > > so do we have consensus to add the following subsection to > section 2 > ( st.html#overview.of.bindings>)? > > > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of > [RFC2518], it might > be thought that an UNLOCK request to a locked resource would > unlock just > the binding of the Request-URI. This is not the case, > however. Section > 6 of [RFC2518] clearly states that locks are on resources, > not URIs, so > the server MUST allow UNLOCK to be used to unlock a locked resource > through any binding to that resource. The authors of this > specification > anticipate and recommend that future revisions of [RFC2518] maintain > this behavior. From w3c-dist-auth-request@w3.org Tue Jan 18 17:21:25 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12871 for ; Tue, 18 Jan 2005 17:21:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr1iN-0006GF-Mo for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 22:20:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cqzem-0003NM-WC for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 20:08:53 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CqzcY-0001jD-WC for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 20:06:35 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0IK6haa016338 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 18 Jan 2005 12:06:43 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41ED6B18.9080500@cse.ucsc.edu> References: <41ED656B.4090801@gmx.de> <41ED6B18.9080500@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 18 Jan 2005 12:06:37 -0800 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9271 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 22:20:43 +0000 Content-Transfer-Encoding: 7bit Removing locking from base WebDAV is a major step. Before we take it, I'd specifically like to hear from client implementors, some of whom (Adobe) rely on locking being implemented in the server. Client implementors, please identify yourselves and speak up! Lisa On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote: > > Julian Reschke wrote: > >> Ok, so do we have consensus to add the following [...]? > > I've been considering the various options suggested to address this > issue since it was raised, along with the various implications. For > the record, I don't have any problem with the suggested language > (below) being added to the BIND specification as it seems to address > Lisas' concerns, while leaving the actual locking behavior specified > in the core WebDAV specification. > > For future reference, I would also like to see similar clarification / > specification of locking behavior in the presence of multiple bindings > to a resource appear in either 2518bis or a separate locking > specification. My preference, once again, is for locking to be broken > out into a separate specification, as suggested and discussed > previously on this list. I believe that there was /rough concensus/ on > that approach the last time it came up. > > > Cheers, > Elias > _________________________ > >> 2.x UNLOCK and Bindings >> >> Due to the specific language used in section 8.11 of [RFC2518], it >> might be thought that an UNLOCK request to a locked resource would >> unlock just the binding of the Request-URI. This is not the case, >> however. Section 6 of [RFC2518] clearly states that locks are on >> resources, not URIs, so the server MUST allow UNLOCK to be used to >> unlock a locked resource through any binding to that resource. The >> authors of this specification anticipate and recommend that future >> revisions of [RFC2518] maintain this behavior. > > > From w3c-dist-auth-request@w3.org Tue Jan 18 18:46:50 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19406 for ; Tue, 18 Jan 2005 18:46:49 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr32M-0000rG-QC for w3c-dist-auth-dist@listhub.w3.org; Tue, 18 Jan 2005 23:45:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr32M-0000qh-7y for w3c-dist-auth@listhub.w3.org; Tue, 18 Jan 2005 23:45:26 +0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr32C-0007ZZ-Bh for w3c-dist-auth@w3.org; Tue, 18 Jan 2005 23:45:16 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0INirRK019211 for ; Tue, 18 Jan 2005 18:44:53 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0INirg9269710 for ; Tue, 18 Jan 2005 18:44:53 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0INir4K029395 for ; Tue, 18 Jan 2005 18:44:53 -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 j0INirBc029392 for ; Tue, 18 Jan 2005 18:44:53 -0500 In-Reply-To: <757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 18 Jan 2005 18:44:49 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/18/2005 18:44:52, Serialize complete at 01/18/2005 18:44:52 Content-Type: multipart/alternative; boundary="=_alternative 008273B585256F8D_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.141 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Creating a separate Locking-bis protocol specification X-Archived-At: http://www.w3.org/mid/OF3C78897A.1E06D6B5-ON85256F8D.0080D1D6-85256F8D.008273B6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9272 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 18 Jan 2005 23:45:26 +0000 This is a multipart message in MIME format. --=_alternative 008273B585256F8D_= Content-Type: text/plain; charset="US-ASCII" Locking support (level 2 WebDAV) is explicitly optional in RFC-2518. So I fail to see how defining it in a separate specification has anything substantive to do with whether or not a client implementor can rely on it being implemented in a server. So I would phrase the question somewhat differently, e.g.: "Separating out the optional locking semantics from RFC-2518bis and placing it in its own separate specification allows us to resolve the locking issues in RFC-2518 in a more expeditious manner. I'd specifically like to hear from client implementors, some of whom (Adobe) rely on locking, as to whether they agree that it is important to resolve the locking issues more rapidly, by de-coupling them from the rest of the issues in RFC-2518bis." Cheers, Geoff Lisa wrote on 01/18/2005 03:06:37 PM: > > Removing locking from base WebDAV is a major step. Before we take it, > I'd specifically like to hear from client implementors, some of whom > (Adobe) rely on locking being implemented in the server. > > Client implementors, please identify yourselves and speak up! > > Lisa > > On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote: > > > > > Julian Reschke wrote: > > > >> Ok, so do we have consensus to add the following [...]? > > > > I've been considering the various options suggested to address this > > issue since it was raised, along with the various implications. For > > the record, I don't have any problem with the suggested language > > (below) being added to the BIND specification as it seems to address > > Lisas' concerns, while leaving the actual locking behavior specified > > in the core WebDAV specification. > > > > For future reference, I would also like to see similar clarification / > > specification of locking behavior in the presence of multiple bindings > > to a resource appear in either 2518bis or a separate locking > > specification. My preference, once again, is for locking to be broken > > out into a separate specification, as suggested and discussed > > previously on this list. I believe that there was /rough concensus/ on > > that approach the last time it came up. > > > > > > Cheers, > > Elias > > _________________________ > > > >> 2.x UNLOCK and Bindings > >> > >> Due to the specific language used in section 8.11 of [RFC2518], it > >> might be thought that an UNLOCK request to a locked resource would > >> unlock just the binding of the Request-URI. This is not the case, > >> however. Section 6 of [RFC2518] clearly states that locks are on > >> resources, not URIs, so the server MUST allow UNLOCK to be used to > >> unlock a locked resource through any binding to that resource. The > >> authors of this specification anticipate and recommend that future > >> revisions of [RFC2518] maintain this behavior. > > > > > > > > --=_alternative 008273B585256F8D_= Content-Type: text/html; charset="US-ASCII"
Locking support (level 2 WebDAV) is explicitly optional in RFC-2518.
So I fail to see how defining it in a separate specification has anything
substantive to do with whether or not a client implementor can rely
on it being implemented in a server.

So I would phrase the question somewhat differently, e.g.:

"Separating out the optional locking semantics from RFC-2518bis and
placing it in its own separate specification allows us to resolve the locking issues
in RFC-2518 in a more expeditious manner.  I'd specifically like to
hear from client implementors, some of whom (Adobe) rely on locking, as
to whether they agree that it is important to resolve the locking issues
more rapidly, by de-coupling them from the rest of the issues in RFC-2518bis."

Cheers,
Geoff

Lisa wrote on 01/18/2005 03:06:37 PM:

>
> Removing locking from base WebDAV is a major step.  Before we take it,
> I'd specifically like to hear from client implementors, some of whom
> (Adobe) rely on locking being implemented in the server.
>
> Client implementors, please identify yourselves and speak up!
>
> Lisa
>
> On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote:
>
> >
> > Julian Reschke wrote:
> >
> >> Ok,  so do we have consensus to add the following [...]?
> >
> > I've been considering the various options suggested to address this
> > issue since it was raised, along with the various implications. For
> > the record, I don't have any problem with the suggested language
> > (below) being added to the BIND specification as it seems to address
> > Lisas' concerns, while leaving the actual locking behavior specified
> > in the core WebDAV specification.
> >
> > For future reference, I would also like to see similar clarification /
> > specification of locking behavior in the presence of multiple bindings
> > to a resource appear in either 2518bis or a separate locking
> > specification. My preference, once again, is for locking to be broken
> > out into a separate specification, as suggested and discussed
> > previously on this list. I believe that there was /rough concensus/ on
> > that approach the last time it came up.
> >
> >
> > Cheers,
> > Elias
> > _________________________
> >
> >> 2.x UNLOCK and Bindings
> >>
> >> Due to the specific language used in section 8.11 of [RFC2518], it
> >> might be thought that an UNLOCK request to a locked resource would
> >> unlock just the binding of the Request-URI.  This is not the case,
> >> however.  Section 6 of [RFC2518] clearly states that locks are on
> >> resources, not URIs, so the server MUST allow UNLOCK to be used to
> >> unlock a locked resource through any binding to that resource.  The
> >> authors of this specification anticipate and recommend that future
> >> revisions of [RFC2518] maintain this behavior.
> >
> >
> >
>
>
--=_alternative 008273B585256F8D_=-- From w3c-dist-auth-request@w3.org Tue Jan 18 19:09:36 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21150 for ; Tue, 18 Jan 2005 19:09:36 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr3Oo-0008Fb-Q3 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:08:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr3Oo-0008F7-Gy for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:08:38 +0000 Received: from ithilien.qualcomm.com ([129.46.51.59]) by bart.w3.org with esmtp (Exim 4.34) id 1Cr3Oo-0002m7-7x for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:08:38 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0J083eD021798; Tue, 18 Jan 2005 16:08:03 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0J07xfs013620; Tue, 18 Jan 2005 16:08:01 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 18 Jan 2005 16:08:00 -0800 To: Geoffrey M Clemm , " webdav" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.7.0.111621 Received-SPF: none (bart.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Creating a separate Locking-bis protocol specification X-Archived-At: http://www.w3.org/mid/p06200707be135456f791@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9273 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:08:38 +0000 A working group has the opportunity when revising a standard to declare a previously optional aspect of the original spec to be mandatory. It happens quite frequently in security documents (where there is almost a track of new algorithms starting as optional, becoming mandatory, then being deprecated), and it happens often enough in APPs contexts that no one would be surprised if a locking draft that succeeded RFC-2518's description of locking declared it mandatory. I am not saying that this *should* happen, but the discussion of a successor document should take into account that this would be in scope for such a document. regards, Ted Hardie At 6:44 PM -0500 1/18/05, Geoffrey M Clemm wrote: >Locking support (level 2 WebDAV) is explicitly optional in RFC-2518. >So I fail to see how defining it in a separate specification has anything >substantive to do with whether or not a client implementor can rely >on it being implemented in a server. > >So I would phrase the question somewhat differently, e.g.: > >"Separating out the optional locking semantics from RFC-2518bis and >placing it in its own separate specification allows us to resolve >the locking issues >in RFC-2518 in a more expeditious manner. I'd specifically like to >hear from client implementors, some of whom (Adobe) rely on locking, as >to whether they agree that it is important to resolve the locking issues >more rapidly, by de-coupling them from the rest of the issues in RFC-2518bis." > >Cheers, >Geoff > >Lisa wrote on 01/18/2005 03:06:37 PM: > >> >> Removing locking from base WebDAV is a major step. Before we take it, >> I'd specifically like to hear from client implementors, some of whom >> (Adobe) rely on locking being implemented in the server. >> >> Client implementors, please identify yourselves and speak up! >> >> Lisa >> >> On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote: >> >> > >> > Julian Reschke wrote: >> > >> >> Ok, so do we have consensus to add the following [...]? >> > >> > I've been considering the various options suggested to address this >> > issue since it was raised, along with the various implications. For >> > the record, I don't have any problem with the suggested language >> > (below) being added to the BIND specification as it seems to address >> > Lisas' concerns, while leaving the actual locking behavior specified >> > in the core WebDAV specification. >> > >> > For future reference, I would also like to see similar clarification / >> > specification of locking behavior in the presence of multiple bindings >> > to a resource appear in either 2518bis or a separate locking >> > specification. My preference, once again, is for locking to be broken >> > out into a separate specification, as suggested and discussed >> > previously on this list. I believe that there was /rough concensus/ on >> > that approach the last time it came up. >> > >> > >> > Cheers, >> > Elias >> > _________________________ >> > >> >> 2.x UNLOCK and Bindings >> >> >> >> Due to the specific language used in section 8.11 of [RFC2518], it >> >> might be thought that an UNLOCK request to a locked resource would >> >> unlock just the binding of the Request-URI. This is not the case, >> >> however. Section 6 of [RFC2518] clearly states that locks are on >> >> resources, not URIs, so the server MUST allow UNLOCK to be used to >> >> unlock a locked resource through any binding to that resource. The >> >> authors of this specification anticipate and recommend that future >> >> revisions of [RFC2518] maintain this behavior. >> > >> > >> > >> >> From w3c-dist-auth-request@w3.org Tue Jan 18 19:32:00 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22649 for ; Tue, 18 Jan 2005 19:32:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr3kX-0007gj-G6 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:31:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr3kX-0007fx-1w for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:31:05 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1Cr3kW-0006QP-Se for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:31:04 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 16:30:30 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit From: Brian Korver Date: Tue, 18 Jan 2005 16:30:30 -0800 To: WebDAV X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 19 Jan 2005 00:30:30.0924 (UTC) FILETIME=[14E2D4C0:01C4FDBE] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: ETags? (was: WG Last call for BIND) X-Archived-At: http://www.w3.org/mid/53146294-69B1-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9274 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:31:05 +0000 Content-Transfer-Encoding: 7bit The BIND spec doesn't mention ETags at all, but buried in section 3.11 of RFC 2616 is the following text: An entity tag MUST be unique across all versions of all entities associated with a particular resource. A given entity tag value MAY be used for entities obtained by requests on different URIs. The use of the same entity tag value in conjunction with entities obtained by requests on different URIs does not imply the equivalence of those entities. which (at least to me) seems counter-intuitive in the face of multiple bindings -- I would have guessed that the ETag would remain constant. Any chance we could squeeze some text into the draft, similar to that dealing with locking? Something approximately like: Entity Tags and Bindings It might be thought that ETags would be associated with resources, not URIs, and as such two different URIs with identical ETags would imply that the URIs are bindings to the same resource. This is not the case, however. Section 3.11 of [RFC2616] states that ETags are on URIs, not resources. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Jan 18 19:37:04 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23024 for ; Tue, 18 Jan 2005 19:37:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr3pl-0001EF-8t for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:36:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr3pl-0001Dl-1K for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:36:29 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cr3pk-0007Ei-Lr for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:36:28 +0000 Received: (qmail invoked by alias); 19 Jan 2005 00:35:55 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp003) with SMTP; 19 Jan 2005 01:35:55 +0100 X-Authenticated: #1915285 Message-ID: <41EDAB62.1010501@gmx.de> Date: Wed, 19 Jan 2005 01:35:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: w3c-dist-auth@w3.org References: <41ED656B.4090801@gmx.de> <41ED6B18.9080500@cse.ucsc.edu> <757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org> In-Reply-To: <757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41EDAB62.1010501@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9275 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:36:29 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > Removing locking from base WebDAV is a major step. Before we take it, We remove it from the *document* and move into a different document. Locking was optional in RFC2518, and things will be the same afterwards. > I'd specifically like to hear from client implementors, some of whom > (Adobe) rely on locking being implemented in the server. So does Apple. I'm not sure how this is relevant? Please be more specific. > Client implementors, please identify yourselves and speak up! Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 19:44:04 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23442 for ; Tue, 18 Jan 2005 19:44:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr3wK-0005iu-B0 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:43:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr3wK-0005iP-3j for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:43:16 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cr3wA-0007NC-2R for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:43:06 +0000 Received: (qmail invoked by alias); 19 Jan 2005 00:42:41 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp007) with SMTP; 19 Jan 2005 01:42:41 +0100 X-Authenticated: #1915285 Message-ID: <41EDACF7.1070209@gmx.de> Date: Wed, 19 Jan 2005 01:42:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie 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 (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Creating a separate Locking-bis protocol specification X-Archived-At: http://www.w3.org/mid/41EDACF7.1070209@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9276 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:43:16 +0000 Content-Transfer-Encoding: 7bit Ted Hardie wrote: > > A working group has the opportunity when revising a standard > to declare a previously optional aspect of the original spec to be > mandatory. It happens quite frequently in security documents > (where there is almost a track of new algorithms starting as > optional, becoming mandatory, then being deprecated), and > it happens often enough in APPs contexts that no one would > be surprised if a locking draft that succeeded RFC-2518's > description of locking declared it mandatory. > > I am not saying that this *should* happen, but the discussion > of a successor document should take into account that this > would be in scope for such a document. Thanks for the clarification, Ted. Personally, I think this would be a step into the wrong direction. There are scenarios out there today that work perfectly fine without locking, and there are servers that do not support locking at all, or do not support it for specific resources. Making locking mandatory in future specs will not affect these servers (nor the clients that work with them). In the best (or worst?) case they will be upgraded to include other -bis features, claim compliance but still will not support locking. On the other hand, clarifying that locking *is* optional, and publishing a much simpler base WebDAV spec (sans locking) my actually convince potential server implementers to implement those parts of RFC2518 (namespace operations + metadata) and therefore increase WebDAV's acceptance. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 19:46:04 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23585 for ; Tue, 18 Jan 2005 19:46:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr3yT-0007Di-AO for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:45:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr3yT-0007DC-0v for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:45:29 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1Cr3yI-0007dc-VQ for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:45:19 +0000 Received: (qmail invoked by alias); 19 Jan 2005 00:44:56 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp002) with SMTP; 19 Jan 2005 01:44:56 +0100 X-Authenticated: #1915285 Message-ID: <41EDAD7F.4000408@gmx.de> Date: Wed, 19 Jan 2005 01:44:47 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fay, Chuck" 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 (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings in teract with locks. X-Archived-At: http://www.w3.org/mid/41EDAD7F.4000408@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9277 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:45:29 +0000 Content-Transfer-Encoding: 7bit Fay, Chuck wrote: > I would like to revise and expand on some wording that I introduced in > the first sentence, to make it clearer: > > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of [RFC2518], it might > be thought that an UNLOCK request to a locked resource would unlock just > the particular binding expressed by the Request-URI, rather than the > resource identified by that URI. This is not the case, however. > Section 6 of [RFC2518] clearly states that locks are on resources, not > URIs, so the server MUST allow UNLOCK to be used to unlock a locked > resource through any binding to that resource. The authors of this > specification anticipate and recommend that future revisions of > [RFC2518] maintain this behavior. It keeps improving :-). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 19:54:13 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24163 for ; Tue, 18 Jan 2005 19:54:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr464-0002BR-Ff for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 00:53:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr464-0002Ar-8d for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 00:53:20 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cr45u-0000dD-7m for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 00:53:10 +0000 Received: (qmail invoked by alias); 19 Jan 2005 00:52:47 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp012) with SMTP; 19 Jan 2005 01:52:47 +0100 X-Authenticated: #1915285 Message-ID: <41EDAF57.3070206@gmx.de> Date: Wed, 19 Jan 2005 01:52:39 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> In-Reply-To: <53146294-69B1-11D9-A835-000A95AACED2@xythos.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EDAF57.3070206@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9278 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 00:53:20 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > > The BIND spec doesn't mention ETags at all, but buried in section > 3.11 of RFC 2616 is the following text: > > An entity tag MUST be unique across all versions of all entities > associated with a particular resource. A given entity tag value MAY > be used for entities obtained by requests on different URIs. The use > of the same entity tag value in conjunction with entities obtained by > requests on different URIs does not imply the equivalence of those > entities. > > which (at least to me) seems counter-intuitive in the face of multiple > bindings -- I would have guessed that the ETag would remain constant. I think all this says is that if you get the same Etag for "/a" and "/b", you can't assume that it's the same entity. > Any chance we could squeeze some text into the draft, similar to that > dealing with locking? Something approximately like: > > Entity Tags and Bindings > > It might be thought that ETags would be associated with resources, > not URIs, and as such two different URIs with identical ETags > would imply that the URIs are bindings to the same resource. > This is not the case, however. Section 3.11 of [RFC2616] > states that ETags are on URIs, not resources. I agree with the conclusion, but I think the motivation for saying this is a bit weak. Could you please re-read 3.11 and consider my explanation above? That being said here's something for RFC2518bis to clarify: RFC2616's definition of ETag semantics doesn't work well with namespace operations. In practice, within the same URL namespace ETags will only work well when they are indeed unique not only for all versions for a single URI, but for the whole namespace (otherwise a server will have to do post-processing after MOVE operations to ensure that ETag semantics are preserved, possibly assigning new ETags just because a namespace operation occured). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 20:08:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25168 for ; Tue, 18 Jan 2005 20:08:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4KZ-0007xk-EH for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:08:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4KR-0007w5-7S for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:08:11 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr4KH-0002yv-8n for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:08:01 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0J189VD025174 for ; Tue, 18 Jan 2005 17:08:09 -0800 (PST) Message-Id: <200501190108.j0J189VD025174@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Tue, 18 Jan 2005 17:08:00 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT9t+lobFmiQz6sSwGtTmVKTcLbKAACRT+w Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: Creating a separate Locking-bis protocol specification X-Archived-At: http://www.w3.org/mid/200501190108.j0J189VD025174@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9280 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:08:19 +0000 Content-Transfer-Encoding: 7bit Moving locking issues into another draft doesn't reduce the complexity of the locking issues; it just moves text. If an issue is contentious in 2518bis, it will still be contentious in 2518bis-lock. Moving locking to a separate document won't speed the overall process, because approval of this document will still be gated on completion of the rest of the 2518bis edits, to ensure there aren't inconsistencies. Locking should not be split out from the rest of 2518bis. - Jim From w3c-dist-auth-request@w3.org Tue Jan 18 20:08:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25169 for ; Tue, 18 Jan 2005 20:08:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4KR-0007wz-Eb for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:08:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4KR-0007w6-7T for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:08:11 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr4KH-0002yu-8l for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:08:01 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0J189VC025174; Tue, 18 Jan 2005 17:08:09 -0800 (PST) Message-Id: <200501190108.j0J189VC025174@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Brian Korver'" , "'WebDAV'" Date: Tue, 18 Jan 2005 17:08:00 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT9vjlKQbnVahD2TciioeoVex2wzAABAMVg Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? (was: WG Last call for BIND) X-Archived-At: http://www.w3.org/mid/200501190108.j0J189VC025174@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9279 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:08:11 +0000 Content-Transfer-Encoding: 7bit > A given entity tag value MAY be used for entities obtained > by requests on different URIs. The use of the same entity > tag value in conjunction with entities obtained by > requests on different URIs does not imply the equivalence of those > entities. My recollection is that a server might decide to implement Etags as a simple integer that is updated on every state modification. In this case, all of the resources on a server would start out with the same Etag value of "1". In this case, the fact of all Etags being "1" certainly doesn't imply that all URIs are mapped to the same resource. The fact that all Etags have the value "1" is still consistence with Etags being defined on resources. > Entity Tags and Bindings > > It might be thought that ETags would be associated with resources, > not URIs, and as such two different URIs with identical ETags > would imply that the URIs are bindings to the same resource. > This is not the case, however. Section 3.11 of [RFC2616] > states that ETags are on URIs, not resources. So, if we were to put in language, I'd add something like: Implementors note: Etag values are only required to be unique across all versions of a particular resource, not unique across all versions and all resources. As a result, two separate resources may have the same Etag value, and hence Etag values cannot reliably be used to establish the identity of a resource accessible via multiple URIs. - Jim PS - How is the quota specification coming along? From w3c-dist-auth-request@w3.org Tue Jan 18 20:15:52 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27458 for ; Tue, 18 Jan 2005 20:15:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4R6-0002S7-36 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:15:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4R5-0002QG-QL for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:15:03 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cr4R5-0006vP-Ga for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:15:03 +0000 Received: (qmail invoked by alias); 19 Jan 2005 01:14:31 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp013) with SMTP; 19 Jan 2005 02:14:31 +0100 X-Authenticated: #1915285 Message-ID: <41EDB471.3090000@gmx.de> Date: Wed, 19 Jan 2005 02:14:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@soe.ucsc.edu CC: "'Brian Korver'" , "'WebDAV'" References: <200501190108.j0J189VC025174@services.cse.ucsc.edu> In-Reply-To: <200501190108.j0J189VC025174@services.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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? (was: WG Last call for BIND) X-Archived-At: http://www.w3.org/mid/41EDB471.3090000@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9281 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:15:04 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > >> A given entity tag value MAY be used for entities obtained >> by requests on different URIs. The use of the same entity >> tag value in conjunction with entities obtained by >> requests on different URIs does not imply the equivalence of those >> entities. > > > My recollection is that a server might decide to implement Etags as a simple > integer that is updated on every state modification. In this case, all of > the resources on a server would start out with the same Etag value of "1". > In this case, the fact of all Etags being "1" certainly doesn't imply that > all URIs are mapped to the same resource. The fact that all Etags have the > value "1" is still consistence with Etags being defined on resources. Correct. For instance, subversion could use it's global version counter as Etag. >> Entity Tags and Bindings >> >> It might be thought that ETags would be associated with resources, >> not URIs, and as such two different URIs with identical ETags >> would imply that the URIs are bindings to the same resource. >> This is not the case, however. Section 3.11 of [RFC2616] >> states that ETags are on URIs, not resources. > > > So, if we were to put in language, I'd add something like: > > Implementors note: Etag values are only required to be unique across all > versions of a particular resource, not unique across all versions and > all resources. As a result, two separate resources may have the same > Etag value, and hence Etag values cannot reliably be used to establish > the identity of a resource accessible via multiple URIs. That's correct, but I really have a hard time understanding why anybody would *think* that ETags can be used that way. If they could, we wouldn't need DAV:resource-id... > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 20:19:13 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27780 for ; Tue, 18 Jan 2005 20:19:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4UQ-0003fa-QZ for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:18:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4UQ-0003f1-KU for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:18:30 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr4UG-0004kr-O8 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:18:20 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 17:17:59 -0800 In-Reply-To: <41EDAF57.3070206@gmx.de> References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: WebDAV From: Brian Korver Date: Tue, 18 Jan 2005 17:17:59 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 19 Jan 2005 01:17:59.0165 (UTC) FILETIME=[B691EAD0:01C4FDC4] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/F4CF73EF-69B7-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9282 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:18:30 +0000 Content-Transfer-Encoding: 7bit On Jan 18, 2005, at 4:52 PM, Julian Reschke wrote: > Brian Korver wrote: >> The BIND spec doesn't mention ETags at all, but buried in section >> 3.11 of RFC 2616 is the following text: >> An entity tag MUST be unique across all versions of all entities >> associated with a particular resource. A given entity tag value MAY >> be used for entities obtained by requests on different URIs. The >> use >> of the same entity tag value in conjunction with entities obtained >> by >> requests on different URIs does not imply the equivalence of those >> entities. >> which (at least to me) seems counter-intuitive in the face of multiple >> bindings -- I would have guessed that the ETag would remain constant. > > I think all this says is that if you get the same Etag for "/a" and > "/b", you can't assume that it's the same entity. Right, that's what I believe it says too, but I think that may be counter-intuitive for some implementers -- who may in fact miss this text in 3.11 and to implement expecting that they can assume it's the same entity. > >> Any chance we could squeeze some text into the draft, similar to that >> dealing with locking? Something approximately like: >> Entity Tags and Bindings >> It might be thought that ETags would be associated with resources, >> not URIs, and as such two different URIs with identical ETags >> would imply that the URIs are bindings to the same resource. >> This is not the case, however. Section 3.11 of [RFC2616] >> states that ETags are on URIs, not resources. > > I agree with the conclusion, but I think the motivation for saying > this is a bit weak. Could you please re-read 3.11 and consider my > explanation above? > > That being said here's something for RFC2518bis to clarify: RFC2616's > definition of ETag semantics doesn't work well with namespace > operations. In practice, within the same URL namespace ETags will only > work well when they are indeed unique not only for all versions for a > single URI, but for the whole namespace (otherwise a server will have > to do post-processing after MOVE operations to ensure that ETag > semantics are preserved, possibly assigning new ETags just because a > namespace operation occured). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Jan 18 20:20:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28119 for ; Tue, 18 Jan 2005 20:20:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4WB-0004Uw-9y for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:20:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4WB-0004US-3x for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:20:19 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr4W1-0004xv-7G for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:20:09 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 17:19:48 -0800 In-Reply-To: <200501190108.j0J189VC025174@services.cse.ucsc.edu> References: <200501190108.j0J189VC025174@services.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35CB8322-69B8-11D9-A835-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: "'WebDAV'" From: Brian Korver Date: Tue, 18 Jan 2005 17:19:48 -0800 To: X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 19 Jan 2005 01:19:48.0040 (UTC) FILETIME=[F776EC80:01C4FDC4] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? (was: WG Last call for BIND) X-Archived-At: http://www.w3.org/mid/35CB8322-69B8-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9283 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:20:19 +0000 Content-Transfer-Encoding: 7bit On Jan 18, 2005, at 5:08 PM, Jim Whitehead wrote: [snip] > PS - How is the quota specification coming along? I'm working on it right now and plan to have it out in the next few days. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Jan 18 20:25:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28553 for ; Tue, 18 Jan 2005 20:25:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4ag-00087d-QV for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:24:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4ag-000874-KI for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:24:58 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cr4af-0000U3-T9 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:24:58 +0000 Received: (qmail invoked by alias); 19 Jan 2005 01:24:25 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp010) with SMTP; 19 Jan 2005 02:24:25 +0100 X-Authenticated: #1915285 Message-ID: <41EDB6C3.1060607@gmx.de> Date: Wed, 19 Jan 2005 02:24:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ejw@soe.ucsc.edu CC: "'webdav'" References: <200501190108.j0J189VD025174@services.cse.ucsc.edu> In-Reply-To: <200501190108.j0J189VD025174@services.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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Creating a separate Locking-bis protocol specification X-Archived-At: http://www.w3.org/mid/41EDB6C3.1060607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9284 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:24:58 +0000 Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Moving locking issues into another draft doesn't reduce the complexity of > the locking issues; it just moves text. If an issue is contentious in > 2518bis, it will still be contentious in 2518bis-lock. It reduces the amount of work for the editors of RFC2518bis (who seem to have trouble spending time on it). Also, as far as I can tell, almost all of the issues with locking have been resolved on the mailing list (see ). > Moving locking to a separate document won't speed the overall process, > because approval of this document will still be gated on completion of the > rest of the 2518bis edits, to ensure there aren't inconsistencies. That would be only true if the intent would be to submit both of them as "Draft". *My* intent (when I made that proposal initially and while working on it) was to submit it as "Proposed", so RFC2518bis (base) and the locking spec can really become independent of each. So the timeline would be something like: #1: finish the separated locking spec, updating RFC2518, publish as "proposed" #2: finish RFC2518bis minus locking, publish as "draft" #3: advance the locking spec to draft as well (another competing spec to go to "draft" would be DeltaV). As far as I can tell, once the WG agrees on that plan we could be done with #1 this spring. > Locking should not be split out from the rest of 2518bis. I'd be tempted to agree if I had any idea about when work will continue on RFC2518bis. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 20:31:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28881 for ; Tue, 18 Jan 2005 20:31:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4gG-00035y-6P for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:30:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4gF-00035S-Vs for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:30:43 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cr4gF-00023P-Kl for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:30:43 +0000 Received: (qmail invoked by alias); 19 Jan 2005 01:30:08 -0000 Received: from pD9E51C90.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.144) by mail.gmx.net (mp027) with SMTP; 19 Jan 2005 02:30:08 +0100 X-Authenticated: #1915285 Message-ID: <41EDB815.1020101@gmx.de> Date: Wed, 19 Jan 2005 02:29:57 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EDB815.1020101@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9285 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:30:44 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > Right, that's what I believe it says too, but I think that may be > counter-intuitive for some implementers -- who may in fact miss > this text in 3.11 and to implement expecting that they can assume > it's the same entity. > ... I'm not sure why implementers who are going to miss a specific section in RFC2616 aren't going to miss other important sections in RFC2616, RFC2518 or BIND as well -- so I don't buy that as reason to repeat something that another spec (normatively referenced) already says. Have you actually *seen* implementers make that mistake? In which case a request for clarification should be added to the RFC2616 errata list. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Jan 18 20:32:52 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28977 for ; Tue, 18 Jan 2005 20:32:52 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr4hl-0003SQ-EO for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 01:32:17 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr4hl-0003Rr-75 for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 01:32:17 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Cr4hb-0007de-4j for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 01:32:07 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j0J1WC306721; Wed, 19 Jan 2005 02:32:14 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005011902321163:8545 ; Wed, 19 Jan 2005 02:32:11 +0100 In-Reply-To: References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: Cc: WebDAV From: "Roy T. Fielding" Date: Tue, 18 Jan 2005 17:32:07 -0800 To: Brian Korver X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/19/2005 02:32:11 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/19/2005 02:32:14 AM, Serialize complete at 01/19/2005 02:32:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/EEAC9EBC-69B9-11D9-BBF5-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9286 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 01:32:17 +0000 Content-Transfer-Encoding: 7bit >> I think all this says is that if you get the same Etag for "/a" and >> "/b", you can't assume that it's the same entity. > > Right, that's what I believe it says too, but I think that may be > counter-intuitive for some implementers -- who may in fact miss > this text in 3.11 and to implement expecting that they can assume > it's the same entity. I suggest we give them a sharp object and let evolution take its course. There is nothing in either specification that would lead to such an assumption and no evidence that implementers have made it (at least none that survived in the wild). ....Roy From w3c-dist-auth-request@w3.org Tue Jan 18 21:29:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01404 for ; Tue, 18 Jan 2005 21:29:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr5ZQ-0005j1-IW for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 02:27:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr5ZQ-0005iP-16 for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 02:27:44 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1Cr5ZP-0003wZ-Pv for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 02:27:43 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0J2Reaa005780 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Jan 2005 18:27:41 -0800 In-Reply-To: References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Brian Korver , WebDAV From: Lisa Dusseault Date: Tue, 18 Jan 2005 18:27:34 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/ADD20C2F-69C1-11D9-BEE8-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9287 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 02:27:44 +0000 Content-Transfer-Encoding: 7bit When I first considered ETags and bindings, I assumed that all bindings to the same resource MUST show the same ETag. That came from my understanding of what the ETag is used for, which is shaped by the implementations I've been involved in and what they do (authoring, sharing). Note that I'm not making the naive assumption that an ETag can be used to identify two bindings -- but I did make the assumption that a single ETag can be recorded in order to synchronize a set of bindings to a single resource. Then I saw Brian's email, where he put forward an excellent argument for why every binding MUST show its own unique ETag. I can entirely understand a server implementor reading these specs and making that decision. So if I wrote a synchronizing client (which I am), and Brian wrote an authoring server (which he does), if we were guided only by the specs and our interpretations, we would probably have interoperability problems. My client would probably be confused by synchronizing two URLs which it knew to be bindings to the same resource but which reported different ETags. Thus, I support adding text to bindings, either limiting the ways that servers can implement ETags and bindings, or explaining to clients the wide range of possible implementations they might have to deal with. Lisa On Jan 18, 2005, at 5:32 PM, Roy T. Fielding wrote: > >>> I think all this says is that if you get the same Etag for "/a" and >>> "/b", you can't assume that it's the same entity. >> >> Right, that's what I believe it says too, but I think that may be >> counter-intuitive for some implementers -- who may in fact miss >> this text in 3.11 and to implement expecting that they can assume >> it's the same entity. > > I suggest we give them a sharp object and let evolution take its > course. > > There is nothing in either specification that would lead to such an > assumption and no evidence that implementers have made it (at least > none that survived in the wild). > > ....Roy > > From w3c-dist-auth-request@w3.org Tue Jan 18 23:17:38 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08663 for ; Tue, 18 Jan 2005 23:17:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cr7GC-0006N8-A4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 04:16:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cr7GB-0006MZ-J2 for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 04:15:59 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.34) id 1Cr7GB-0007Wb-DI for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 04:15:59 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0J4FSSK022975 for ; Tue, 18 Jan 2005 23:15:28 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0J4FSg9032828 for ; Tue, 18 Jan 2005 23:15:28 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0J4FSs7012430 for ; Tue, 18 Jan 2005 23:15:28 -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 j0J4FSlu012426 for ; Tue, 18 Jan 2005 23:15:28 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 18 Jan 2005 23:15:32 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/18/2005 23:15:28, Serialize complete at 01/18/2005 23:15:28 Content-Type: multipart/alternative; boundary="=_alternative 0017635485256F8E_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OFD44736E8.DC594AC9-ON85256F8E.000FBDFB-85256F8E.00176355@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9288 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 04:16:00 +0000 This is a multipart message in MIME format. --=_alternative 0017635485256F8E_= Content-Type: text/plain; charset="US-ASCII" I think the heart of this issue is that the binding specification states that live properties SHOULD have the same value no matter what binding is used to access it. This would imply that the getetag property SHOULD have the same value no matter what binding is used to it. If we agree that a resource should have the same getetag property, no matter what binding is used to access it, then the specification is correct as currently written, but I'm OK with making that statement explicitly in the spec, since that is an etag constraint that is not stated in 2616, and so there probably are etag implementations that do not satisfy that constraint and that therefore should not be used with a binding implementation. Conversely, if we agree that a resource may have different getetag property values when it is accessed from different bindings, then we should modify section 2.6 to say "unless explicitly stated in the definition of the live property", and then state that getetag is a property whose value can differ when accessed from different bindings. Cheers, Geoff p.s. I did get a bit of a chuckle over the characterization of the statement about etags being "buried" in section 3.11 of RFC-2616, since the the title of section 3.11 is "Entity Tags", and that section is only 3 paragraphs long. Come on Roy, how did you expect folks to find that kind of stuff if you're going to hide it away like that (:-). Lisa wrote on 01/18/2005 09:27:34 PM: > > When I first considered ETags and bindings, I assumed that all bindings > to the same resource MUST show the same ETag. That came from my > understanding of what the ETag is used for, which is shaped by the > implementations I've been involved in and what they do (authoring, > sharing). Note that I'm not making the naive assumption that an ETag > can be used to identify two bindings -- but I did make the assumption > that a single ETag can be recorded in order to synchronize a set of > bindings to a single resource. > > Then I saw Brian's email, where he put forward an excellent argument > for why every binding MUST show its own unique ETag. I can entirely > understand a server implementor reading these specs and making that > decision. > > So if I wrote a synchronizing client (which I am), and Brian wrote an > authoring server (which he does), if we were guided only by the specs > and our interpretations, we would probably have interoperability > problems. My client would probably be confused by synchronizing two > URLs which it knew to be bindings to the same resource but which > reported different ETags. > > Thus, I support adding text to bindings, either limiting the ways that > servers can implement ETags and bindings, or explaining to clients the > wide range of possible implementations they might have to deal with. > > Lisa > > On Jan 18, 2005, at 5:32 PM, Roy T. Fielding wrote: > > > > >>> I think all this says is that if you get the same Etag for "/a" and > >>> "/b", you can't assume that it's the same entity. > >> > >> Right, that's what I believe it says too, but I think that may be > >> counter-intuitive for some implementers -- who may in fact miss > >> this text in 3.11 and to implement expecting that they can assume > >> it's the same entity. > > > > I suggest we give them a sharp object and let evolution take its > > course. > > > > There is nothing in either specification that would lead to such an > > assumption and no evidence that implementers have made it (at least > > none that survived in the wild). > > > > ....Roy > > > > > > --=_alternative 0017635485256F8E_= Content-Type: text/html; charset="US-ASCII"
I think the heart of this issue is that the binding
specification states that live properties SHOULD have the
same value no matter what binding is used to access it.
This would imply that the getetag property SHOULD have the
same value no matter what binding is used to it.

If we agree that a resource should have the same getetag
property, no matter what binding is used to access it, then
the specification is correct as currently written, but
I'm OK with making that statement explicitly in the spec,
since that is an etag constraint that is not stated in 2616, and
so there probably are etag implementations that do not satisfy
that constraint and that therefore should not be used with
a binding implementation.

Conversely, if we agree that a resource may have different
getetag property values when it is accessed from different
bindings, then we should modify section 2.6 to say "unless explicitly
stated in the definition of the live property", and then
state that getetag is a property whose value can differ when
accessed from different bindings.

Cheers,
Geoff

p.s. I did get a bit of a chuckle over the
characterization of the statement about etags
being "buried" in section 3.11 of RFC-2616, since the
the title of section 3.11 is "Entity Tags", and that
section is only 3 paragraphs long.
Come on Roy, how did you expect folks to find that kind
of stuff if you're going to hide it away like that (:-).


Lisa wrote on 01/18/2005 09:27:34 PM:
>
> When I first considered ETags and bindings, I assumed that all bindings
> to the same resource MUST show the same ETag.  That came from my
> understanding of what the ETag is used for, which is shaped by the
> implementations I've been involved in and what they do (authoring,
> sharing).  Note that I'm not making the naive assumption that an ETag
> can be used to identify two bindings -- but I did make the assumption
> that a single ETag can be recorded in order to synchronize a set of
> bindings to a single resource.
>
> Then I saw Brian's email, where he put forward an excellent argument
> for why every binding MUST show its own unique ETag.  I can entirely
> understand a server implementor reading these specs and making that
> decision.
>
> So if I wrote a synchronizing client (which I am), and Brian wrote an
> authoring server (which he does), if we were guided only by the specs
> and our interpretations, we would probably have interoperability
> problems.  My client would probably be confused by synchronizing two
> URLs which it knew to be bindings to the same resource but which
> reported different ETags.
>
> Thus, I support adding text to bindings, either limiting the ways that
> servers can implement ETags and bindings, or explaining to clients the
> wide range of possible implementations they might have to deal with.
>
> Lisa
>
> On Jan 18, 2005, at 5:32 PM, Roy T. Fielding wrote:
>
> >
> >>> I think all this says is that if you get the same Etag for "/a" and
> >>> "/b", you can't assume that it's the same entity.
> >>
> >> Right, that's what I believe it says too, but I think that may be
> >> counter-intuitive for some implementers -- who may in fact miss
> >> this text in 3.11 and to implement expecting that they can assume
> >> it's the same entity.
> >
> > I suggest we give them a sharp object and let evolution take its
> > course.
> >
> > There is nothing in either specification that would lead to such an
> > assumption and no evidence that implementers have made it (at least
> > none that survived in the wild).
> >
> > ....Roy
> >
> >
>
>
--=_alternative 0017635485256F8E_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 02:36:32 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17024 for ; Wed, 19 Jan 2005 02:36:31 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrAMw-0005MG-B2 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 07:35:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrAMv-0005Lj-Q4 for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 07:35:09 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrAMl-0002M7-R5 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 07:35:00 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0J7Z8p8005929; Tue, 18 Jan 2005 23:35:08 -0800 Date: Tue, 18 Jan 2005 23:35:08 -0800 Message-Id: <200501190735.j0J7Z8p8005929@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200501190735.j0J7Z8p8005929@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9289 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 07:35:10 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-18 23:35 ------- Suggested additional text bei Joe Hildebrand, Chuck Fay and Julian Reschke: 2.x UNLOCK and Bindings Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the particular binding expressed by the Request-URI, rather than the resource identified by that URI. This is not the case, however. Section 6 of [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Wed Jan 19 03:20:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20718 for ; Wed, 19 Jan 2005 03:20:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrB3e-00035S-MY for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 08:19:18 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrB3e-00034v-4C for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 08:19:18 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CrB3d-0001FY-QS for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 08:19:18 +0000 Received: (qmail invoked by alias); 19 Jan 2005 08:18:44 -0000 Received: from pD9535794.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.148) by mail.gmx.net (mp018) with SMTP; 19 Jan 2005 09:18:44 +0100 X-Authenticated: #1915285 Message-ID: <41EE17DE.8090108@gmx.de> Date: Wed, 19 Jan 2005 09:18:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: "Roy T. Fielding" , Brian Korver , WebDAV References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EE17DE.8090108@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9290 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 08:19:18 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > When I first considered ETags and bindings, I assumed that all bindings > to the same resource MUST show the same ETag. That came from my > understanding of what the ETag is used for, which is shaped by the > implementations I've been involved in and what they do (authoring, > sharing). Note that I'm not making the naive assumption that an ETag > can be used to identify two bindings -- but I did make the assumption ETags do not identify resources or bindings. ETags can be used *with* URIs (as pair (URI, etag)) to identify one specific entity body you may get when applying GET to that URI. > that a single ETag can be recorded in order to synchronize a set of > bindings to a single resource. If this would be the case, we wouldn't need DAV:resource-id. In particular, how would that work with changing content (= changing etags?). > Then I saw Brian's email, where he put forward an excellent argument for > why every binding MUST show its own unique ETag. I can entirely I haven't seen that argument. Please quote, link to or explain again. > understand a server implementor reading these specs and making that > decision. Well, I can't, but I'm interested. Where is that argument? > So if I wrote a synchronizing client (which I am), and Brian wrote an > authoring server (which he does), if we were guided only by the specs > and our interpretations, we would probably have interoperability > problems. My client would probably be confused by synchronizing two > URLs which it knew to be bindings to the same resource but which > reported different ETags. Well, that's an entirely different issue compared to: "Then I saw Brian's email, where he put forward an excellent argument for why every binding MUST show its own unique ETag." There are good reasons why Etags for the same entity body accessed through different URIs *should* be the same, and draft 10 already says () that the value of a live property -- and this includes DAV:getetag -- SHOULD be the same. I'm not sure we can go any further than that, because Entity Tags are defined by RFC2616, not us. Maybe Roy can give some guidance here. > Thus, I support adding text to bindings, either limiting the ways that > servers can implement ETags and bindings, or explaining to clients the > wide range of possible implementations they might have to deal with. That being said I do agree with the other comments Geoff made in -- I'm just not convinced that BIND needs to decide either way at this stage of the standards process. Sometimes, when something is initially submitted, being silent on a particular thing can be the right thing to do. In particular, this seems to be an issue that actually affects RFC2616 itself and possibly should be clarified there. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 19 07:16:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05507 for ; Wed, 19 Jan 2005 07:16:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrEjA-0006IQ-QQ for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 12:14:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrEjA-0006Hw-6L for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 12:14:24 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CrEjA-0002RM-15 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 12:14:24 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0JCDq7j005754 for ; Wed, 19 Jan 2005 07:13:52 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0JCDqGu266060 for ; Wed, 19 Jan 2005 07:13:52 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0JCDq5X024307 for ; Wed, 19 Jan 2005 07:13:52 -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 j0JCDqiX024302 for ; Wed, 19 Jan 2005 07:13:52 -0500 In-Reply-To: <41EE17DE.8090108@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 07:13:55 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 07:13:52, Serialize complete at 01/19/2005 07:13:52 Content-Type: multipart/alternative; boundary="=_alternative 00432F5685256F8E_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF00C9D956.C1A82592-ON85256F8E.0041FFE7-85256F8E.00432F59@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9291 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 12:14:24 +0000 This is a multipart message in MIME format. --=_alternative 00432F5685256F8E_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian. This is an existing RFC-2616 issue, not an issue introduced by the BIND specification, since: - RFC-2616 explicitly states that two URIs can be mapped to the same resource - RFC-2616 is where entity tags are defined Therefore whether or not two URIs that are mapped to the same resource have the same entity tag is an existing RFC-2616 issue. If there is current consensus on this question, then I'm OK with adding a sentence to the bind specification about it. But if there is not consensus (and I suspect there is not), then I believe it makes no sense to hold up the BIND specification because of an issue with the etag specification in RFC-2616. Cheers, Geoff Julian wrote on 01/19/2005 03:18:38 AM: [WRT whether or not the etag SHOULD/MUST be the same at different bindings]: > That being said I do agree with the other comments Geoff made in > > -- I'm just not convinced that BIND needs to decide either way at this > stage of the standards process. Sometimes, when something is initially > submitted, being silent on a particular thing can be the right thing to > do. In particular, this seems to be an issue that actually affects > RFC2616 itself and possibly should be clarified there. --=_alternative 00432F5685256F8E_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian.  This is an existing RFC-2616 issue,
not an issue introduced by the BIND specification, since:
- RFC-2616 explicitly states that two URIs can be mapped to the same resource
- RFC-2616 is where entity tags are defined
Therefore whether or not two URIs that are mapped to the same resource
have the same entity tag is an existing RFC-2616 issue.

If there is current consensus on this question, then I'm OK with
adding a sentence to the bind specification about it.  But if there is
not consensus (and I suspect there is not), then I believe it makes
no sense to hold up the BIND specification because of an issue with the
etag specification in RFC-2616.

Cheers,
Geoff

Julian wrote on 01/19/2005 03:18:38 AM:

[WRT whether or not the etag SHOULD/MUST be the same at different bindings]:

> That being said I do agree with the other comments Geoff made in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0060.html>
> -- I'm just not convinced that BIND needs to decide either way at this
> stage of the standards process. Sometimes, when something is initially
> submitted, being silent on a particular thing can be the right thing to
> do. In particular, this seems to be an issue that actually affects
> RFC2616 itself and possibly should be clarified there.

 --=_alternative 00432F5685256F8E_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 07:19:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05762 for ; Wed, 19 Jan 2005 07:19:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrEnS-000071-DN for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 12:18:50 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrEnS-0008WE-5j for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 12:18:50 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CrEn6-0003JT-Uw for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 12:18:29 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0JCIRV7006232; Wed, 19 Jan 2005 04:18:27 -0800 Date: Wed, 19 Jan 2005 04:18:27 -0800 Message-Id: <200501191218.j0JCIRV7006232@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/200501191218.j0JCIRV7006232@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9292 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 12:18:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-19 04:18 ------- See (resolved in -latest). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Wed Jan 19 12:17:53 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01051 for ; Wed, 19 Jan 2005 12:17:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrJRb-0000AZ-3D for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 17:16:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrJRa-00009r-HY for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 17:16:34 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrJRQ-0001VL-II for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 17:16:24 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0JHGNaa030363 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 19 Jan 2005 09:16:25 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: " webdav" From: Lisa Dusseault Date: Wed, 19 Jan 2005 09:16:16 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/D3C3381A-6A3D-11D9-BEE8-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9293 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 17:16:35 +0000 Content-Transfer-Encoding: 7bit The need for extra specification is introduced in binding, because the bindings draft provides a way to identify whether two bindings map to the same resource. That functionality could lead a client to take either valuable short-cuts or harmful short-cuts when caching ETags to synchronize resources. Lisa On Jan 19, 2005, at 4:13 AM, Geoffrey M Clemm wrote: > I agree with Julian. This is an existing RFC-2616 issue, > not an issue introduced by the BIND specification, since: > - RFC-2616 explicitly states that two URIs can be mapped to the same > resource > - RFC-2616 is where entity tags are defined > Therefore whether or not two URIs that are mapped to the same resource > have the same entity tag is an existing RFC-2616 issue. > > If there is current consensus on this question, then I'm OK with > adding a sentence to the bind specification about it. But if there is > not consensus (and I suspect there is not), then I believe it makes > no sense to hold up the BIND specification because of an issue with the > etag specification in RFC-2616. > > Cheers, > Geoff > > Julian wrote on 01/19/2005 03:18:38 AM: > > [WRT whether or not the etag SHOULD/MUST be the same at different > bindings]: > >> That being said I do agree with the other comments Geoff made in >> > 0060.html> > >> -- I'm just not convinced that BIND needs to decide either way at >> this >> stage of the standards process. Sometimes, when something is initially >> submitted, being silent on a particular thing can be the right thing >> to >> do. In particular, this seems to be an issue that actually affects >> RFC2616 itself and possibly should be clarified there. > From w3c-dist-auth-request@w3.org Wed Jan 19 12:23:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01485 for ; Wed, 19 Jan 2005 12:23:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrJXb-0002Ys-Gm for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 17:22:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrJXb-0002YK-BK for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 17:22:47 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by bart.w3.org with esmtp (Exim 4.34) id 1CrJXb-0003RZ-49 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 17:22:47 +0000 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jan 2005 10:15:48 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net> From: Joe Hildebrand To: webdav Date: Wed, 19 Jan 2005 10:15:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Received-SPF: none (bart.w3.org: domain of JHildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Discovering bindings in BIND X-Archived-At: http://www.w3.org/mid/8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9295 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 17:22:47 +0000 Assume I'm writing an authoring client, and want to show UI to the user with an enumeration of all of the bindings to a particular resource. Section 2.9 of BIND says I get the DAV:parent-set property. However, section 3.2 says (and the example in 3.2.1 confirms) that not all of the binding paths can be returned in that property. Is the idea that the client would walk up the tree looking for other paths to this resource? -- Joe Hildebrand Confidentiality Note: This email is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this email message is not the intended recipient, or the employee or agent responsible for delivery of the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this email in error, please notify Jabber, Inc. immediately by telephone at +303-308-3231. From w3c-dist-auth-request@w3.org Wed Jan 19 12:45:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05028 for ; Wed, 19 Jan 2005 12:45:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrJt1-0006Su-Vi for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 17:44:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrJt1-0006S8-GB for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 17:44:55 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CrJt1-0000dq-58 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 17:44:55 +0000 Received: (qmail invoked by alias); 19 Jan 2005 17:44:24 -0000 Received: from pD9FF0187.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (217.255.1.135) by mail.gmx.net (mp018) with SMTP; 19 Jan 2005 18:44:24 +0100 X-Authenticated: #1915285 Message-ID: <41EE9C6C.1000803@gmx.de> Date: Wed, 19 Jan 2005 18:44:12 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: webdav References: <8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Discovering bindings in BIND X-Archived-At: http://www.w3.org/mid/41EE9C6C.1000803@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9296 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 17:44:55 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Assume I'm writing an authoring client, and want to show UI to the user with > an enumeration of all of the bindings to a particular resource. Section 2.9 In general, you can't display *all* bindings to a resource. There may be an infinite number (if a parent collection has a bind loop). > of BIND says I get the DAV:parent-set property. However, section 3.2 says > (and the example in 3.2.1 confirms) that not all of the binding paths can be > returned in that property. It returns all bindings (each with a URI to the collection it's in). If you need to compute all *paths*, you'll need to redo that step recursively for these collections. > Is the idea that the client would walk up the tree looking for other paths > to this resource? Yes, if it needs to. It just has to keep in mind that doing it without special loop checks may result in an infinite loop. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 19 13:03:20 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01050 for ; Wed, 19 Jan 2005 12:17:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrJRb-0000Ax-8J for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 17:16:35 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrJRb-0000AC-0N for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 17:16:35 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1CrJRa-0002A5-PL for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 17:16:34 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0JHGXi0005709 for ; Wed, 19 Jan 2005 09:16:33 -0800 (PST) Message-Id: <200501191716.j0JHGXi0005709@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Wed, 19 Jan 2005 09:16:33 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcT+IJGykI3/svMXSJKXfTyc878C9wAKZ1ZA Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? X-Archived-At: http://www.w3.org/mid/200501191716.j0JHGXi0005709@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 17:16:35 +0000 Content-Transfer-Encoding: 7bit DAV:getetag appears to justify allowing live property values to vary with URI and/or binding used to access them, since it really describes the on-the-wire entity, and 2518 defines it as the Etag returned by a GET without accept headers. - Jim From w3c-dist-auth-request@w3.org Wed Jan 19 15:13:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17123 for ; Wed, 19 Jan 2005 15:13:50 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrMBz-0002g7-SX for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 20:12:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrMBz-0002fX-2A for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 20:12:39 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CrMBp-0005O6-3C for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 20:12:29 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jan 2005 12:12:04 -0800 In-Reply-To: <41EE9C6C.1000803@gmx.de> References: <8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net> <41EE9C6C.1000803@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6329B704-6A56-11D9-A835-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit Cc: webdav From: Brian Korver Date: Wed, 19 Jan 2005 12:12:04 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 19 Jan 2005 20:12:04.0669 (UTC) FILETIME=[24D9D6D0:01C4FE63] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Discovering bindings in BIND X-Archived-At: http://www.w3.org/mid/6329B704-6A56-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9297 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 20:12:39 +0000 Content-Transfer-Encoding: 7bit On Jan 19, 2005, at 9:44 AM, Julian Reschke wrote: > > Joe Hildebrand wrote: >> Assume I'm writing an authoring client, and want to show UI to the >> user with >> an enumeration of all of the bindings to a particular resource. >> Section 2.9 > > In general, you can't display *all* bindings to a resource. There may > be an infinite number (if a parent collection has a bind loop). Don't you mean, 'in general, you can...'? I always assumed that having an infinite number of parents is the exception. > >> of BIND says I get the DAV:parent-set property. However, section 3.2 >> says >> (and the example in 3.2.1 confirms) that not all of the binding paths >> can be >> returned in that property. > > It returns all bindings (each with a URI to the collection it's in). > If you need to compute all *paths*, you'll need to redo that step > recursively for these collections. > >> Is the idea that the client would walk up the tree looking for other >> paths >> to this resource? > > Yes, if it needs to. It just has to keep in mind that doing it without > special loop checks may result in an infinite loop. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Jan 19 17:11:07 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02510 for ; Wed, 19 Jan 2005 17:11:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrO0W-00065R-7d for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 22:08:56 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrO0V-00064p-CS for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 22:08:55 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CrO0L-0000dt-8I for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 22:08:45 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j0JM8p323051; Wed, 19 Jan 2005 23:08:51 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005011923084849:9773 ; Wed, 19 Jan 2005 23:08:48 +0100 In-Reply-To: References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: Cc: "WebDAV WG)" From: "Roy T. Fielding" Date: Wed, 19 Jan 2005 14:08:47 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/19/2005 11:08:48 PM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/19/2005 11:08:51 PM, Serialize complete at 01/19/2005 11:08:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/B13B28C8-6A66-11D9-BBF5-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9298 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 22:08:56 +0000 Content-Transfer-Encoding: 7bit On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote: > When I first considered ETags and bindings, I assumed that all > bindings to the same resource MUST show the same ETag. Well, that assumption was in error. Errors happen and no amount of specification can prevent them. In particular, specifying the internal implementation of ETag just to prevent people from making erroneous assumptions about the interface is contrary to the design of HTTP. One person's need for etags will differ from the needs of others. In Apache httpd, for example, the contents of default etags are configurable. Some people will want the inode and last-mod, other people cannot include the inode due to use of clusters, while still others will use an MD5 hash of a pre-generated response message because their content is backed by a CMS. There is no way for the standard to guess all of the possible implementations of etags. There are two sections to consider in the bindings draft: 2.6 PROPFIND and Bindings Consistent with [RFC2518] the value of a dead property MUST be, and the value of a live property SHOULD be, independent of the number of bindings to its host resource or of the path submitted to PROPFIND. which I consider to be in error because live properties are owned by the server -- any requirement that they be consistent across bindings is wrong. and 2.7 Determining Whether Two Bindings Are to the Same Resource which tells the implementer the right way to test for equivalence. > So if I wrote a synchronizing client (which I am), and Brian wrote an > authoring server (which he does), if we were guided only by the specs > and our interpretations, we would probably have interoperability > problems. No, you would have errors. There is a difference between making a standard that enables interoperability and forcing implementations to use it correctly. > Thus, I support adding text to bindings, either limiting the ways that > servers can implement ETags and bindings, or explaining to clients the > wide range of possible implementations they might have to deal with. Why do you insist on violating the basic design principles of an interface? HTTP is supposed to support loose coupling of software systems, which means the standards cannot specify anything like what you describe above. The specification is not the place to put tutorials on server design or lecture notes on potential implementations -- people can write books about that. ....Roy From w3c-dist-auth-request@w3.org Wed Jan 19 18:05:59 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06362 for ; Wed, 19 Jan 2005 18:05:59 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrOsY-0000lZ-DF for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:04:46 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrOsS-0000gB-Qf for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 23:04:40 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CrOsS-0007SQ-E3 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 23:04:40 +0000 Received: (qmail invoked by alias); 19 Jan 2005 23:04:07 -0000 Received: from pD9535794.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.148) by mail.gmx.net (mp019) with SMTP; 20 Jan 2005 00:04:07 +0100 X-Authenticated: #1915285 Message-ID: <41EEE75E.10002@gmx.de> Date: Thu, 20 Jan 2005 00:03:58 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: webdav References: <8D96EDA0AC04D31197B400A0C96C14800E2C7337@corp.webb.net> <41EE9C6C.1000803@gmx.de> <6329B704-6A56-11D9-A835-000A95AACED2@xythos.com> In-Reply-To: <6329B704-6A56-11D9-A835-000A95AACED2@xythos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Discovering bindings in BIND X-Archived-At: http://www.w3.org/mid/41EEE75E.10002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:04:46 +0000 Content-Transfer-Encoding: 7bit Brian Korver wrote: > On Jan 19, 2005, at 9:44 AM, Julian Reschke wrote: > >> >> Joe Hildebrand wrote: >> >>> Assume I'm writing an authoring client, and want to show UI to the >>> user with >>> an enumeration of all of the bindings to a particular resource. >>> Section 2.9 >> >> >> In general, you can't display *all* bindings to a resource. There may >> be an infinite number (if a parent collection has a bind loop). > > > Don't you mean, 'in general, you can...'? I always assumed that having > an infinite > number of parents is the exception. Well, in *general*, you can't. In many cases, you can. And you can always if your server either doesn't support collection bindings or somehow rejects bind loop creation attempts. Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 19 18:11:51 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07052 for ; Wed, 19 Jan 2005 18:11:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrOyV-0003FI-Az for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:10:55 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrOyU-0003En-R8 for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 23:10:54 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.34) id 1CrOyK-00026e-Ok for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 23:10:45 +0000 Received: (qmail invoked by alias); 19 Jan 2005 23:10:19 -0000 Received: from pD9535794.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.148) by mail.gmx.net (mp005) with SMTP; 20 Jan 2005 00:10:19 +0100 X-Authenticated: #1915285 Message-ID: <41EEE8C9.2060707@gmx.de> Date: Thu, 20 Jan 2005 00:10:01 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Lisa Dusseault , "WebDAV WG)" References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EEE8C9.2060707@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9300 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:10:55 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > Well, that assumption was in error. Errors happen and no amount > of specification can prevent them. In particular, specifying the > internal implementation of ETag just to prevent people from making > erroneous assumptions about the interface is contrary to the design > of HTTP. One person's need for etags will differ from the needs > of others. > > In Apache httpd, for example, the contents of default etags are > configurable. Some people will want the inode and last-mod, > other people cannot include the inode due to use of clusters, > while still others will use an MD5 hash of a pre-generated > response message because their content is backed by a CMS. > There is no way for the standard to guess all of the possible > implementations of etags. > > There are two sections to consider in the bindings draft: > > 2.6 PROPFIND and Bindings > > Consistent with [RFC2518] the value of a dead property MUST be, and > the value of a live property SHOULD be, independent of the number of > bindings to its host resource or of the path submitted to PROPFIND. > > which I consider to be in error because live properties are owned > by the server -- any requirement that they be consistent across > bindings is wrong. I'm tempted to say "I told you so" (not to you, Roy :-). Although it would be certainly nice to be able to rely on that, we don't seem to able to mandate that. > and > > 2.7 Determining Whether Two Bindings Are to the Same Resource > > which tells the implementer the right way to test for equivalence. > >> So if I wrote a synchronizing client (which I am), and Brian wrote an >> authoring server (which he does), if we were guided only by the specs >> and our interpretations, we would probably have interoperability >> problems. > > > No, you would have errors. There is a difference between making a > standard that enables interoperability and forcing implementations > to use it correctly. > >> Thus, I support adding text to bindings, either limiting the ways that >> servers can implement ETags and bindings, or explaining to clients the >> wide range of possible implementations they might have to deal with. > > > Why do you insist on violating the basic design principles > of an interface? HTTP is supposed to support loose coupling > of software systems, which means the standards cannot specify > anything like what you describe above. The specification is > not the place to put tutorials on server design or lecture notes > on potential implementations -- people can write books about that. And they actually do that :-) I'm also a bit concerned by attempts to turn WebDAV into something like NFS-over-HTTP. It can be used like that, but it's only *one* usage of it. Attempting to optimize WebDAV for that particular case (for instance, by adding new ETag requirements that in practice many servers will not be able to implement), IMHO is a bad idea, and I will continue to object to changes like that. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 19 18:16:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07619 for ; Wed, 19 Jan 2005 18:16:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrP35-0004mq-2F for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:15:39 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrP32-0004in-3P; Wed, 19 Jan 2005 23:15:36 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CrP31-0000gR-SR; Wed, 19 Jan 2005 23:15:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0JNF47j008235; Wed, 19 Jan 2005 18:15:04 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0JNF4Ww201968; Wed, 19 Jan 2005 18:15:04 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0JNF4Hp019306; Wed, 19 Jan 2005 18:15:04 -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 j0JNF4eR019299; Wed, 19 Jan 2005 18:15:04 -0500 In-Reply-To: To: "Roy T. Fielding" Cc: Lisa Dusseault , "WebDAV WG)" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 18:15:07 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 18:15:03, Serialize complete at 01/19/2005 18:15:03 Content-Type: multipart/alternative; boundary="=_alternative 007FB83285256F8E_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF0D0C3AB5.7B4DFF54-ON85256F8E.007D870D-85256F8E.007FB835@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9301 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:15:39 +0000 This is a multipart message in MIME format. --=_alternative 007FB83285256F8E_= Content-Type: text/plain; charset="US-ASCII" I heartily agree with everything Roy says here. Roy: WRT your concern about the statement about live properties, would it be OK instead to say: 2.6 PROPFIND and Bindings Consistent with [RFC2518] the value of a dead property of a given resource MUST be independent of path to that resource submitted to PROPFIND. The value of a live property SHOULD be independent of the path submitted to PROPFIND, unless the definition of the property explicitly states otherwise. In other words, we are requiring live property definers to include in the live property definition the behavior of that property in the context of a resource being identified by multiple URLs. Or would you prefer that the spec just say nothing about the behavior of live properties? Cheers, Geoff Roy wrote on 01/19/2005 05:08:47 PM: > > On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote: > > When I first considered ETags and bindings, I assumed that all > > bindings to the same resource MUST show the same ETag. > > Well, that assumption was in error. Errors happen and no amount > of specification can prevent them. In particular, specifying the > internal implementation of ETag just to prevent people from making > erroneous assumptions about the interface is contrary to the design > of HTTP. One person's need for etags will differ from the needs > of others. > > In Apache httpd, for example, the contents of default etags are > configurable. Some people will want the inode and last-mod, > other people cannot include the inode due to use of clusters, > while still others will use an MD5 hash of a pre-generated > response message because their content is backed by a CMS. > There is no way for the standard to guess all of the possible > implementations of etags. > > There are two sections to consider in the bindings draft: > > 2.6 PROPFIND and Bindings > > Consistent with [RFC2518] the value of a dead property MUST be, and > the value of a live property SHOULD be, independent of the number of > bindings to its host resource or of the path submitted to PROPFIND. > > which I consider to be in error because live properties are owned > by the server -- any requirement that they be consistent across > bindings is wrong. > > and > > 2.7 Determining Whether Two Bindings Are to the Same Resource > > which tells the implementer the right way to test for equivalence. > > > So if I wrote a synchronizing client (which I am), and Brian wrote an > > authoring server (which he does), if we were guided only by the specs > > and our interpretations, we would probably have interoperability > > problems. > > No, you would have errors. There is a difference between making a > standard that enables interoperability and forcing implementations > to use it correctly. > > > Thus, I support adding text to bindings, either limiting the ways that > > servers can implement ETags and bindings, or explaining to clients the > > wide range of possible implementations they might have to deal with. > > Why do you insist on violating the basic design principles > of an interface? HTTP is supposed to support loose coupling > of software systems, which means the standards cannot specify > anything like what you describe above. The specification is > not the place to put tutorials on server design or lecture notes > on potential implementations -- people can write books about that. > > ....Roy > > --=_alternative 007FB83285256F8E_= Content-Type: text/html; charset="US-ASCII"
I heartily agree with everything Roy says here.

Roy: WRT your concern about the statement about live properties,
would it be OK instead to say:

    2.6  PROPFIND and Bindings

    Consistent with [RFC2518] the value of a dead property of a
     given resource MUST be independent of path to that resource
     submitted to PROPFIND.  The value of a live property SHOULD
     be independent of the path submitted to PROPFIND, unless
     the definition of the property explicitly states otherwise.

In other words, we are requiring live property definers to include
in the live property definition the behavior of that property in
the context of a resource being identified by multiple URLs.

Or would you prefer that the spec just say nothing about the behavior
of live properties?

Cheers,
Geoff



Roy wrote on 01/19/2005 05:08:47 PM:

>
> On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote:
> > When I first considered ETags and bindings, I assumed that all
> > bindings to the same resource MUST show the same ETag.
>
> Well, that assumption was in error.  Errors happen and no amount
> of specification can prevent them.  In particular, specifying the
> internal implementation of ETag just to prevent people from making
> erroneous assumptions about the interface is contrary to the design
> of HTTP. One person's need for etags will differ from the needs
> of others.
>
> In Apache httpd, for example, the contents of default etags are
> configurable.  Some people will want the inode and last-mod,
> other people cannot include the inode due to use of clusters,
> while still others will use an MD5 hash of a pre-generated
> response message because their content is backed by a CMS.
> There is no way for the standard to guess all of the possible
> implementations of etags.
>
> There are two sections to consider in the bindings draft:
>
>    2.6  PROPFIND and Bindings
>
>     Consistent with [RFC2518] the value of a dead property MUST be, and
>     the value of a live property SHOULD be, independent of the number of
>     bindings to its host resource or of the path submitted to PROPFIND.
>
> which I consider to be in error because live properties are owned
> by the server -- any requirement that they be consistent across
> bindings is wrong.
>
> and
>
>    2.7  Determining Whether Two Bindings Are to the Same Resource
>
> which tells the implementer the right way to test for equivalence.
>
> > So if I wrote a synchronizing client (which I am), and Brian wrote an
> > authoring server (which he does), if we were guided only by the specs
> > and our interpretations, we would probably have interoperability
> > problems.
>
> No, you would have errors.  There is a difference between making a
> standard that enables interoperability and forcing implementations
> to use it correctly.
>
> > Thus, I support adding text to bindings, either limiting the ways that
> > servers can implement ETags and bindings, or explaining to clients the
> > wide range of possible implementations they might have to deal with.
>
> Why do you insist on violating the basic design principles
> of an interface?  HTTP is supposed to support loose coupling
> of software systems, which means the standards cannot specify
> anything like what you describe above.  The specification is
> not the place to put tutorials on server design or lecture notes
> on potential implementations -- people can write books about that.
>
> ....Roy
>
>
--=_alternative 007FB83285256F8E_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 18:39:22 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09834 for ; Wed, 19 Jan 2005 18:39:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrPPI-0004Kx-65 for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:38:36 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrPPG-0004J5-4C for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 23:38:34 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by lisa.w3.org with esmtp (Exim 4.34) id 1CrPP5-0006lQ-UZ for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 23:38:24 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j0JNcV327139; Thu, 20 Jan 2005 00:38:31 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005012000382945:9845 ; Thu, 20 Jan 2005 00:38:29 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <385A6475-6A73-11D9-BBF5-000D93324AD6@gbiv.com> Cc: "WebDAV WG)" From: "Roy T. Fielding" Date: Wed, 19 Jan 2005 15:38:28 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/20/2005 12:38:29 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/20/2005 12:38:31 AM, Serialize complete at 01/20/2005 12:38:31 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/385A6475-6A73-11D9-BBF5-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9302 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:38:36 +0000 Content-Transfer-Encoding: quoted-printable On Jan 19, 2005, at 3:15 PM, Geoffrey M Clemm wrote: > > I heartily agree with everything Roy says here. > > Roy: WRT your concern about the statement about live properties, > would it be OK instead to say: > > =A0 =A0 2.6 =A0PROPFIND and Bindings > > =A0 =A0 Consistent with [RFC2518] the value of a dead property of a > =A0 =A0 =A0given resource MUST be independent of path to that resource > =A0 =A0 =A0submitted to PROPFIND. =A0The value of a live property = SHOULD > =A0 =A0 =A0be independent of the path submitted to PROPFIND, unless > =A0 =A0 =A0the definition of the property explicitly states otherwise. I don't like meaningless SHOULDs. How is an implementation supposed to test compliance with such a requirement? I would prefer that the specification say nothing about the value of a live property, since live properties are (by definition) not controlled by the client and thus not subject to interoperability constraints aside from whatever may be in their definition. The only thing that can be legitimately said is that "The value of a live property MUST comply with the definition of that property." which is, of course, a completely vacuous statement and not subject to the bindings specification. ....Roy= From w3c-dist-auth-request@w3.org Wed Jan 19 18:39:34 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09882 for ; Wed, 19 Jan 2005 18:39:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrPPi-0004Vy-6k for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:39:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrPPh-0004Uc-OD; Wed, 19 Jan 2005 23:39:01 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by bart.w3.org with esmtp (Exim 4.34) id 1CrPPh-0004vi-IP; Wed, 19 Jan 2005 23:39:01 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0JNcUJX009663; Wed, 19 Jan 2005 18:38:30 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0JNcUGu285082; Wed, 19 Jan 2005 18:38:30 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0JNcUCP020976; Wed, 19 Jan 2005 18:38:30 -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 j0JNcT4S020971; Wed, 19 Jan 2005 18:38:29 -0500 In-Reply-To: To: Lisa Dusseault Cc: " webdav" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 18:38:28 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 18:38:29, Serialize complete at 01/19/2005 18:38:29 Content-Type: multipart/alternative; boundary="=_alternative 0081DB7C85256F8E_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF3235D45C.0B248E53-ON85256F8E.008145ED-85256F8E.0081DB7D@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9303 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:39:02 +0000 This is a multipart message in MIME format. --=_alternative 0081DB7C85256F8E_= Content-Type: text/plain; charset="US-ASCII" A client cannot take such short-cuts unless the etag specification states they can take those short cuts. There is nothing in the etag specification that allows them to make that assumption, and therefore as Greg has pointed out, it is just an implementation error if they base their implementation on something other than the specification. Perhaps we should also state that the last segment of the etag does not have to match the current modification date, to make sure they do not optimize their implementation by making that assumption? (:-) Cheers, Geoff Lisa wrote on 01/19/2005 12:16:16 PM: > > The need for extra specification is introduced in binding, because the > bindings draft provides a way to identify whether two bindings map to > the same resource. That functionality could lead a client to take > either valuable short-cuts or harmful short-cuts when caching ETags to > synchronize resources. > > Lisa > > On Jan 19, 2005, at 4:13 AM, Geoffrey M Clemm wrote: > > > I agree with Julian. This is an existing RFC-2616 issue, > > not an issue introduced by the BIND specification, since: > > - RFC-2616 explicitly states that two URIs can be mapped to the same > > resource > > - RFC-2616 is where entity tags are defined > > Therefore whether or not two URIs that are mapped to the same resource > > have the same entity tag is an existing RFC-2616 issue. > > > > If there is current consensus on this question, then I'm OK with > > adding a sentence to the bind specification about it. But if there is > > not consensus (and I suspect there is not), then I believe it makes > > no sense to hold up the BIND specification because of an issue with the > > etag specification in RFC-2616. > > > > Cheers, > > Geoff > > > > Julian wrote on 01/19/2005 03:18:38 AM: > > > > [WRT whether or not the etag SHOULD/MUST be the same at different > > bindings]: > > > >> That being said I do agree with the other comments Geoff made in > >> >> 0060.html> > > > >> -- I'm just not convinced that BIND needs to decide either way at > >> this > >> stage of the standards process. Sometimes, when something is initially > >> submitted, being silent on a particular thing can be the right thing > >> to > >> do. In particular, this seems to be an issue that actually affects > >> RFC2616 itself and possibly should be clarified there. > > > > --=_alternative 0081DB7C85256F8E_= Content-Type: text/html; charset="US-ASCII"
A client cannot take such short-cuts unless the etag specification
states they can take those short cuts.  There is nothing in the etag
specification that allows them to make that assumption, and therefore
as Greg has pointed out, it is just an implementation error if they
base their implementation on something other than the specification.

Perhaps we should also state that the last segment of the etag does
not have to match the current modification date, to make sure they do
not optimize their implementation by making that assumption?  (:-)

Cheers,
Geoff

Lisa wrote on 01/19/2005 12:16:16 PM:

>
> The need for extra specification is introduced in binding, because the  
> bindings draft provides a way to identify whether two bindings map to  
> the same resource.  That functionality could lead a client to take  
> either valuable short-cuts or harmful short-cuts when caching ETags to  
> synchronize resources.
>
> Lisa
>
> On Jan 19, 2005, at 4:13 AM, Geoffrey M Clemm wrote:
>
> > I agree with Julian.  This is an existing RFC-2616 issue,
> > not an issue introduced by the BIND specification, since:
> > - RFC-2616 explicitly states that two URIs can be mapped to the same
> > resource
> > - RFC-2616 is where entity tags are defined
> > Therefore whether or not two URIs that are mapped to the same resource
> > have the same entity tag is an existing RFC-2616 issue.
> >
> > If there is current consensus on this question, then I'm OK with
> > adding a sentence to the bind specification about it.  But if there is
> > not consensus (and I suspect there is not), then I believe it makes
> > no sense to hold up the BIND specification because of an issue with the
> > etag specification in RFC-2616.
> >
> > Cheers,
> > Geoff
> >
> > Julian wrote on 01/19/2005 03:18:38 AM:
> >
> > [WRT whether or not the etag SHOULD/MUST be the same at different
> > bindings]:
> >
> >> That being said I do agree with the other comments Geoff made in
> >> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/
> >> 0060.html>
> >
> >> -- I'm just not convinced that BIND needs to decide either way at  
> >> this
> >> stage of the standards process. Sometimes, when something is initially
> >> submitted, being silent on a particular thing can be the right thing  
> >> to
> >> do. In particular, this seems to be an issue that actually affects
> >> RFC2616 itself and possibly should be clarified there.
> >
>
>
--=_alternative 0081DB7C85256F8E_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 18:43:42 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10287 for ; Wed, 19 Jan 2005 18:43:42 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrPTh-0006NY-NH for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:43:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrPTh-0006Mb-6S; Wed, 19 Jan 2005 23:43:09 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CrPTh-0005yd-1N; Wed, 19 Jan 2005 23:43:09 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0JNgc7j019251; Wed, 19 Jan 2005 18:42:38 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0JNgcWw250930; Wed, 19 Jan 2005 18:42:38 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0JNgcPX004156; Wed, 19 Jan 2005 18:42:38 -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 j0JNgbxt004152; Wed, 19 Jan 2005 18:42:37 -0500 In-Reply-To: <385A6475-6A73-11D9-BBF5-000D93324AD6@gbiv.com> To: "Roy T. Fielding" Cc: "WebDAV WG)" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 18:42:41 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 18:42:37, Serialize complete at 01/19/2005 18:42:37 Content-Type: multipart/alternative; boundary="=_alternative 00823E5785256F8E_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF3522737E.1EFB65FA-ON85256F8E.008222AC-85256F8E.00823E59@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9304 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:43:09 +0000 This is a multipart message in MIME format. --=_alternative 00823E5785256F8E_= Content-Type: text/plain; charset="US-ASCII" I agree with Roy's rationale and conclusion, and support the removal of the reference to live properties in section 2.6. Cheers, Geoff Roy wrote on 01/19/2005 06:38:28 PM: > > On Jan 19, 2005, at 3:15 PM, Geoffrey M Clemm wrote: > > > > I heartily agree with everything Roy says here. > > > > Roy: WRT your concern about the statement about live properties, > > would it be OK instead to say: > > > > 2.6 PROPFIND and Bindings > > > > Consistent with [RFC2518] the value of a dead property of a > > given resource MUST be independent of path to that resource > > submitted to PROPFIND. The value of a live property SHOULD > > be independent of the path submitted to PROPFIND, unless > > the definition of the property explicitly states otherwise. > > I don't like meaningless SHOULDs. How is an implementation supposed > to test compliance with such a requirement? I would prefer that the > specification say nothing about the value of a live property, > since live properties are (by definition) not controlled by the > client and thus not subject to interoperability constraints aside > from whatever may be in their definition. The only thing that can > be legitimately said is that > > "The value of a live property MUST comply with the definition > of that property." > > which is, of course, a completely vacuous statement and not > subject to the bindings specification. > > ....Roy > --=_alternative 00823E5785256F8E_= Content-Type: text/html; charset="US-ASCII"
I agree with Roy's rationale and conclusion, and support the
removal of the reference to live properties in section 2.6.

Cheers,
Geoff

Roy wrote on 01/19/2005 06:38:28 PM:

>
> On Jan 19, 2005, at 3:15 PM, Geoffrey M Clemm wrote:
> >
> > I heartily agree with everything Roy says here.
> >
> > Roy: WRT your concern about the statement about live properties,
> > would it be OK instead to say:
> >
> >     2.6  PROPFIND and Bindings
> >
> >      Consistent with [RFC2518] the value of a dead property of a
> >      given resource MUST be independent of path to that resource
> >      submitted to PROPFIND.  The value of a live property SHOULD
> >      be independent of the path submitted to PROPFIND, unless
> >      the definition of the property explicitly states otherwise.
>
> I don't like meaningless SHOULDs.  How is an implementation supposed
> to test compliance with such a requirement?  I would prefer that the
> specification say nothing about the value of a live property,
> since live properties are (by definition) not controlled by the
> client and thus not subject to interoperability constraints aside
> from whatever may be in their definition.  The only thing that can
> be legitimately said is that
>
>    "The value of a live property MUST comply with the definition
>     of that property."
>
> which is, of course, a completely vacuous statement and not
> subject to the bindings specification.
>
> ....Roy
>
--=_alternative 00823E5785256F8E_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 18:57:19 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11237 for ; Wed, 19 Jan 2005 18:57:19 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrPga-00042D-2T for w3c-dist-auth-dist@listhub.w3.org; Wed, 19 Jan 2005 23:56:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrPgZ-00041b-Bb for w3c-dist-auth@listhub.w3.org; Wed, 19 Jan 2005 23:56:27 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1CrPgZ-0000J7-40 for w3c-dist-auth@w3.org; Wed, 19 Jan 2005 23:56:27 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0JNuPw4019406 for ; Wed, 19 Jan 2005 15:56:25 -0800 (PST) Message-Id: <200501192356.j0JNuPw4019406@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'WebDAV WG\)'" Date: Wed, 19 Jan 2005 15:56:23 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <385A6475-6A73-11D9-BBF5-000D93324AD6@gbiv.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcT+gAjKNwjGddzTSCWv/HwKfs/+cAAAQCsg Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? X-Archived-At: http://www.w3.org/mid/200501192356.j0JNuPw4019406@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9305 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jan 2005 23:56:28 +0000 Content-Transfer-Encoding: 7bit With all due respect to the engineer from Day spending a couple of enjoyable hours procrastinating on the DAV list today, I disagree. I pressed for this language because: - a statement about dead properties in this situation without a similar statement about live properties begs the question of how live properties should behave, - not making a statement about live properties here is ambiguous, and could reasonably be interpreted in multiple contradictory ways (silence = intended assent, silence = intended prohibition), and leads to implementors trying to read spec writers' minds, - the additional language makes it clear that servers have this additional design freedom, if they so desire. The comment about testability is a red herring here, since the requirement is at the design level. Given a specific live property, it is certainly possible to test whether it has a different value for different bindings. I'll point to the long discussions we've had on this issue as evidence that lack of specification language on this issue does not lead to experienced engineers drawing the same conclusion about the behavior of live properties across multiple bindings. > I don't like meaningless SHOULDs. How is an implementation > supposed to test compliance with such a requirement? I would > prefer that the specification say nothing about the value of > a live property, since live properties are (by definition) > not controlled by the client and thus not subject to > interoperability constraints aside from whatever may be in > their definition. - Jim From w3c-dist-auth-request@w3.org Wed Jan 19 19:26:56 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12798 for ; Wed, 19 Jan 2005 19:26:56 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrQ8m-0001yn-NC for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 00:25:36 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrQ8l-0001xW-T4 for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 00:25:35 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CrQ8l-0005lp-FJ for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 00:25:35 +0000 Received: (qmail invoked by alias); 20 Jan 2005 00:25:02 -0000 Received: from pD9535794.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.148) by mail.gmx.net (mp023) with SMTP; 20 Jan 2005 01:25:02 +0100 X-Authenticated: #1915285 Message-ID: <41EEFA56.2070107@gmx.de> Date: Thu, 20 Jan 2005 01:24:54 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm CC: "Roy T. Fielding" , "WebDAV WG)" , w3c-dist-auth-request@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EEFA56.2070107@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 00:25:36 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > I agree with Roy's rationale and conclusion, and support the > removal of the reference to live properties in section 2.6. Just checking...: for a server that does support both RFC3253 and BIND, the value of a WebDAV property MUST NOT vary across bindings unless it's reported as a live property through DAV:supported-live-property-set? (That's something we all should be able to agree upon) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 19 19:46:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14298 for ; Wed, 19 Jan 2005 19:46:27 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrQSH-0007jF-Td for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 00:45:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrQSH-0007il-8j for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 00:45:45 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrQS7-0000bx-8K for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 00:45:35 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0K0jinX006771; Wed, 19 Jan 2005 16:45:44 -0800 Date: Wed, 19 Jan 2005 16:45:44 -0800 Message-Id: <200501200045.j0K0jinX006771@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 71] New: Clarify what servers may and may not do with privileges when BIND is used X-Archived-At: http://www.w3.org/mid/200501200045.j0K0jinX006771@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9307 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 00:45:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71 Summary: Clarify what servers may and may not do with privileges when BIND is used Product: WebDAV-BIND Version: -latest Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 04. BIND Method AssignedTo: julian.reschke@greenbytes.de ReportedBy: lisa@osafoundation.org QAContact: w3c-dist-auth@w3.org The BIND specification doesn't say anything about what the server will do with the privileges of a resource (particularly inherited permissions) when it is bound into a new collection. We should offer some guidance. Use case: In Chandler we want a user to be able to share the same item (for example, a calendar event) in multiple collections. For example, I might want to show the "OSAF holiday party" in both my work calendar share and my home calendar share, so that other users who view either my work or my home calendar will see the event regardless (and users who share both won't see the event twice). The natural way to do this if the server supports bindings would be to create the event in one collection, let's say the client will create it in my work share where permissions are inherited so that all OSAF people can view the event. Then BIND the event to the other collection, where the inherited permissions normally would automatically make it so that my family and friends can view the event. Do we leave it unspecified what happens in this case? Do I end up with a resource that is bound into my home calendar but only work people can see it unless my client fixes up the ACLs? Or do I end up with a resource that is bound into both and has the sum permissions of both? If the client has to fix up the ACLs, now what happens when I add a person to the permissions of my home calendar share, and then apply that new permission to all the resources in my home calendar share? Does my client have to go through each one and ACL each one or can the server calculate the appropriate permissions for resources that are bound into both collections? I can imagine a server implementing it either way depending on what they think the common use cases are; what can the client predict or require here? This may be a difficult problem, but it merits at least some discussion to see if we can make implementation issues clearer to clients, or to see if we can make additional requirements on servers in order to make client implementations simpler. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Wed Jan 19 20:08:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15389 for ; Wed, 19 Jan 2005 20:08:09 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrQn7-00066i-T2 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 01:07:17 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrQn7-000669-8m for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 01:07:17 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by bart.w3.org with esmtp (Exim 4.34) id 1CrQn6-0003oA-Sp for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 01:07:17 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j0K17E301174; Thu, 20 Jan 2005 02:07:14 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005012002071194:9892 ; Thu, 20 Jan 2005 02:07:11 +0100 In-Reply-To: <200501192356.j0JNuPw4019406@services.cse.ucsc.edu> References: <200501192356.j0JNuPw4019406@services.cse.ucsc.edu> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <9C59E7CC-6A7F-11D9-BBF5-000D93324AD6@gbiv.com> Cc: "'WebDAV WG\)'" From: "Roy T. Fielding" Date: Wed, 19 Jan 2005 17:07:10 -0800 To: X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/20/2005 02:07:12 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/20/2005 02:07:14 AM, Serialize complete at 01/20/2005 02:07:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/9C59E7CC-6A7F-11D9-BBF5-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9308 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 01:07:17 +0000 Content-Transfer-Encoding: 7bit On Jan 19, 2005, at 3:56 PM, Jim Whitehead wrote: > > With all due respect to the engineer from Day spending a couple of > enjoyable > hours procrastinating on the DAV list today, I disagree. > > I pressed for this language because: > > - a statement about dead properties in this situation without a similar > statement about live properties begs the question of how live > properties > should behave, So what? Let the reader beg the question. In a specification, lack of a requirement means there is no requirement. > - not making a statement about live properties here is ambiguous, and > could > reasonably be interpreted in multiple contradictory ways > (silence = intended assent, silence = intended prohibition), > and leads to implementors trying to > read spec writers' minds, How is it ambiguous? Intentions here are irrelevant. > - the additional language makes it clear that servers have this > additional > design freedom, if they so desire. No, the additional language was just plain wrong. It introduced a bug in the protocol due to overzealous specification of things outside the control of this particular document. That is why we try to avoid adding such cruft to specifications in the first place. > The comment about testability is a red herring here, since the > requirement > is at the design level. Given a specific live property, it is certainly > possible to test whether it has a different value for different > bindings. The original text said that live properties SHOULD be the same, which was a false requirement. The replacement that Geoff briefly mentioned was that they SHOULD be the same unless they were defined not to be the same. That text would be vacuous. It cannot be tested because a client cannot know whether changes (or lack of changes) in the live property value are due to the bindings, the definition, or some other activity going on behind the server interface. The only reasonable test, therefore, is that the property remains true to its definition regardless of whatever actions have taken place, which is a test of the property definition and NOT a test of the bindings specification. In other words, given any live property, whether or not it has a different value after the binding change is of no use nor concern of the client. > I'll point to the long discussions we've had on this issue as evidence > that > lack of specification language on this issue does not lead to > experienced > engineers drawing the same conclusion about the behavior of live > properties > across multiple bindings. And I'll point to the same discussions as evidence that if the chairs were not so persistently obstinate in ignoring actual working group consensus on the issues then maybe they could make reasonable progress on drafts that should have been completed four years ago. This issue, like many others, is whether it is ever appropriate for experienced engineers to draw conclusions about the implementation behind an interface, as opposed to simply reading the specification, concluding that it defines the interface, and not assuming anything about what happens beyond what is required of that interface. You can find the answer to that question in any basic text on Software Engineering -- it does not need my opinion to justify it. ....Roy From w3c-dist-auth-request@w3.org Wed Jan 19 21:12:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20456 for ; Wed, 19 Jan 2005 21:12:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrRmX-0003fc-N1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 02:10:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrRmW-0003de-O4; Thu, 20 Jan 2005 02:10:44 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrRmM-0004XR-QE; Thu, 20 Jan 2005 02:10:34 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0K2ADSK013116; Wed, 19 Jan 2005 21:10:13 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0K2ADWw288454; Wed, 19 Jan 2005 21:10:13 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0K2ADqv021024; Wed, 19 Jan 2005 21:10:13 -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 j0K2ADHU021018; Wed, 19 Jan 2005 21:10:13 -0500 In-Reply-To: <41EEFA56.2070107@gmx.de> To: Julian Reschke Cc: "Roy T. Fielding" , "WebDAV WG)" , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 21:10:11 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 21:10:12, Serialize complete at 01/19/2005 21:10:12 Content-Type: multipart/alternative; boundary="=_alternative 000BEAC385256F8F_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF2C40E67D.9EF9EC7D-ON85256F8F.000BDBDD-85256F8F.000BEAC6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9309 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 02:10:45 +0000 This is a multipart message in MIME format. --=_alternative 000BEAC385256F8F_= Content-Type: text/plain; charset="US-ASCII" I certainly agree with that. Cheers, Geoff Julian wrote on 01/19/2005 07:24:54 PM: > > Geoffrey M Clemm wrote: > > > > I agree with Roy's rationale and conclusion, and support the > > removal of the reference to live properties in section 2.6. > > Just checking...: > > for a server that does support both RFC3253 and BIND, the value of a > WebDAV property MUST NOT vary across bindings unless it's reported as a > live property through DAV:supported-live-property-set? > > (That's something we all should be able to agree upon) --=_alternative 000BEAC385256F8F_= Content-Type: text/html; charset="US-ASCII"
I certainly agree with that.

Cheers,
Geoff

Julian wrote on 01/19/2005 07:24:54 PM:
>
> Geoffrey M Clemm wrote:
> >
> > I agree with Roy's rationale and conclusion, and support the
> > removal of the reference to live properties in section 2.6.
>
> Just checking...:
>
> for a server that does support both RFC3253 and BIND, the value of a
> WebDAV property MUST NOT vary across bindings unless it's reported as a
> live property through DAV:supported-live-property-set?
>
> (That's something we all should be able to agree upon)
 --=_alternative 000BEAC385256F8F_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 21:45:44 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22939 for ; Wed, 19 Jan 2005 21:45:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrSJX-0007PE-2O for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 02:44:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrSJW-0007Ok-Da for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 02:44:50 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by bart.w3.org with esmtp (Exim 4.34) id 1CrSJW-00056z-7h for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 02:44:50 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0K2iG7j020556 for ; Wed, 19 Jan 2005 21:44:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0K2iGGu284990 for ; Wed, 19 Jan 2005 21:44:16 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0K2iGNm014389 for ; Wed, 19 Jan 2005 21:44:16 -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 j0K2iGpS014386 for ; Wed, 19 Jan 2005 21:44:16 -0500 In-Reply-To: <9C59E7CC-6A7F-11D9-BBF5-000D93324AD6@gbiv.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 21:44:17 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 21:44:16, Serialize complete at 01/19/2005 21:44:16 Content-Type: multipart/alternative; boundary="=_alternative 000F0A2385256F8F_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OFDB49E2C6.43A84B1A-ON85256F8F.000C7499-85256F8F.000F0A24@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 02:44:51 +0000 This is a multipart message in MIME format. --=_alternative 000F0A2385256F8F_= Content-Type: text/plain; charset="US-ASCII" I enthusiastically concur with everything Roy has stated in this message. Answering a question about whether something is true is done by quoting the normative section in the specification that states it is true. Answering a question about whether something is forbidden is done by quoting the normative section in the specification that states it is forbidden. If it isn't stated in the specification, then it is neither required nor forbidden. You get interoperation between a wide range of implementations by only requiring implementations to do what is explicitly required, and to have implementations rely only on things that are explicitly required. Cheers, Geoff Roy wrote on 01/19/2005 08:07:10 PM: > > On Jan 19, 2005, at 3:56 PM, Jim Whitehead wrote: > > I pressed for this language because: > > > > - a statement about dead properties in this situation without a similar > > statement about live properties begs the question of how live > > properties > > should behave, > > So what? Let the reader beg the question. In a specification, lack > of a requirement means there is no requirement. > > > - not making a statement about live properties here is ambiguous, and > > could > > reasonably be interpreted in multiple contradictory ways > > (silence = intended assent, silence = intended prohibition), > > and leads to implementors trying to > > read spec writers' minds, > > How is it ambiguous? Intentions here are irrelevant. > > > - the additional language makes it clear that servers have this > > additional > > design freedom, if they so desire. > > No, the additional language was just plain wrong. It introduced a > bug in the protocol due to overzealous specification of things outside > the control of this particular document. That is why we try to > avoid adding such cruft to specifications in the first place. > > > The comment about testability is a red herring here, since the > > requirement > > is at the design level. Given a specific live property, it is certainly > > possible to test whether it has a different value for different > > bindings. > > The original text said that live properties SHOULD be the same, > which was a false requirement. The replacement that Geoff > briefly mentioned was that they SHOULD be the same unless they > were defined not to be the same. That text would be vacuous. > It cannot be tested because a client cannot know whether changes > (or lack of changes) in the live property value are due to the > bindings, the definition, or some other activity going on behind > the server interface. The only reasonable test, therefore, is that > the property remains true to its definition regardless of whatever > actions have taken place, which is a test of the property definition > and NOT a test of the bindings specification. > > In other words, given any live property, whether or not it has a > different value after the binding change is of no use nor concern > of the client. > > > I'll point to the long discussions we've had on this issue as evidence > > that > > lack of specification language on this issue does not lead to > > experienced > > engineers drawing the same conclusion about the behavior of live > > properties > > across multiple bindings. > > And I'll point to the same discussions as evidence that if the chairs > were not so persistently obstinate in ignoring actual working group > consensus on the issues then maybe they could make reasonable > progress on drafts that should have been completed four years ago. > This issue, like many others, is whether it is ever appropriate for > experienced engineers to draw conclusions about the implementation > behind an interface, as opposed to simply reading the specification, > concluding that it defines the interface, and not assuming anything > about what happens beyond what is required of that interface. > > You can find the answer to that question in any basic text on > Software Engineering -- it does not need my opinion to justify it. --=_alternative 000F0A2385256F8F_= Content-Type: text/html; charset="US-ASCII"
I enthusiastically concur with everything Roy has stated in this message.

Answering a question about whether something is true is done by
quoting the normative section in the specification that states it is true.
Answering a question about whether something is forbidden is done by
quoting the normative section in the specification that states it is forbidden.

If it isn't stated in the specification, then it is neither required nor
forbidden.  You get interoperation between a wide range of implementations
by only requiring implementations to do what is explicitly required,
and to have implementations rely only on things that are explicitly required.

Cheers,
Geoff

Roy wrote on 01/19/2005 08:07:10 PM:
>
> On Jan 19, 2005, at 3:56 PM, Jim Whitehead wrote:
> > I pressed for this language because:
> >
> > - a statement about dead properties in this situation without a similar
> > statement about live properties begs the question of how live
> > properties
> > should behave,
>
> So what?  Let the reader beg the question. In a specification, lack
> of a requirement means there is no requirement.
>
> > - not making a statement about live properties here is ambiguous, and
> > could
> > reasonably be interpreted in multiple contradictory ways
> > (silence = intended assent, silence = intended prohibition),
> > and leads to implementors trying to
> > read spec writers' minds,
>
> How is it ambiguous?  Intentions here are irrelevant.
>
> > - the additional language makes it clear that servers have this
> > additional
> > design freedom, if they so desire.
>
> No, the additional language was just plain wrong.  It introduced a
> bug in the protocol due to overzealous specification of things outside
> the control of this particular document.  That is why we try to
> avoid adding such cruft to specifications in the first place.
>
> > The comment about testability is a red herring here, since the
> > requirement
> > is at the design level. Given a specific live property, it is certainly
> > possible to test whether it has a different value for different
> > bindings.
>
> The original text said that live properties SHOULD be the same,
> which was a false requirement.  The replacement that Geoff
> briefly mentioned was that they SHOULD be the same unless they
> were defined not to be the same.  That text would be vacuous.
> It cannot be tested because a client cannot know whether changes
> (or lack of changes) in the live property value are due to the
> bindings, the definition, or some other activity going on behind
> the server interface. The only reasonable test, therefore, is that
> the property remains true to its definition regardless of whatever
> actions have taken place, which is a test of the property definition
> and NOT a test of the bindings specification.
>
> In other words, given any live property, whether or not it has a
> different value after the binding change is of no use nor concern
> of the client.
>
> > I'll point to the long discussions we've had on this issue as evidence
> > that
> > lack of specification language on this issue does not lead to
> > experienced
> > engineers drawing the same conclusion about the behavior of live
> > properties
> > across multiple bindings.
>
> And I'll point to the same discussions as evidence that if the chairs
> were not so persistently obstinate in ignoring actual working group
> consensus on the issues then maybe they could make reasonable
> progress on drafts that should have been completed four years ago.
> This issue, like many others, is whether it is ever appropriate for
> experienced engineers to draw conclusions about the implementation
> behind an interface, as opposed to simply reading the specification,
> concluding that it defines the interface, and not assuming anything
> about what happens beyond what is required of that interface.
>
> You can find the answer to that question in any basic text on
> Software Engineering -- it does not need my opinion to justify it.
 --=_alternative 000F0A2385256F8F_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 21:54:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23664 for ; Wed, 19 Jan 2005 21:54:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrSSB-0002Ix-FC for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 02:53:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrSSB-0002IT-6n for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 02:53:47 +0000 Received: from gate.arc.nasa.gov ([128.102.102.51]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrSS1-0003DH-3W for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 02:53:37 +0000 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0K2rhP12275 for ; Wed, 19 Jan 2005 18:53:43 -0800 (PST) Message-ID: <41EF1D37.4030200@cse.ucsc.edu> Date: Wed, 19 Jan 2005 18:53:43 -0800 From: Elias Sinderson Reply-To: WebDAV WG User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG 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-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41EF1D37.4030200@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9311 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 02:53:47 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > I agree with Roy's rationale and conclusion, and support the removal > of the reference to live properties in section 2.6 So, in effect, the spec will state that dead properties MUST be the same across all bindings to a given resource, and that (by remaining silent on the issue) live properties MAY vary depending on server implementation. I am not oposed to this, however as a guide to client implementors it might be nice to point out that they can't neccessarily depend on live properties being the same across all bindings to a resource. Cheers, Elias From w3c-dist-auth-request@w3.org Wed Jan 19 22:04:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24474 for ; Wed, 19 Jan 2005 22:04:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrSbV-0005YY-C8 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 03:03:25 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrSbU-0005Xc-Kh; Thu, 20 Jan 2005 03:03:24 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrSbK-0004jt-Lt; Thu, 20 Jan 2005 03:03:14 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0K32oSK022362; Wed, 19 Jan 2005 22:02: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/VER6.6) with ESMTP id j0K32oWw281516; Wed, 19 Jan 2005 22:02:50 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0K32o5G002653; Wed, 19 Jan 2005 22:02:50 -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 j0K32odQ002648; Wed, 19 Jan 2005 22:02:50 -0500 In-Reply-To: <41EE9C6C.1000803@gmx.de> To: Julian Reschke Cc: Joe Hildebrand , webdav , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 22:02:50 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 22:02:49, Serialize complete at 01/19/2005 22:02:49 Content-Type: multipart/alternative; boundary="=_alternative 0010BCED85256F8F_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Discovering bindings in BIND X-Archived-At: http://www.w3.org/mid/OF2A4BA302.6B25DC68-ON85256F8F.000F3CE2-85256F8F.0010BCEE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9312 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 03:03:25 +0000 This is a multipart message in MIME format. --=_alternative 0010BCED85256F8F_= Content-Type: text/plain; charset="US-ASCII" One minor terminological correction. When Julian said "you can't display *all* bindings to a resource", he meant to say "you can't display all paths a resource is mapped to" (you can display all bindings to a resource, since there are only a finite number of them, and they are enumerated by the DAV:parent-set property). Cheers, Geoff Julian wrote on 01/19/2005 12:44:12 PM: > > Joe Hildebrand wrote: > > Assume I'm writing an authoring client, and want to show UI to theuser with > > an enumeration of all of the bindings to a particular resource. Section 2.9 > > In general, you can't display *all* bindings to a resource. There may be > an infinite number (if a parent collection has a bind loop). > > > of BIND says I get the DAV:parent-set property. However, section 3.2 says > > (and the example in 3.2.1 confirms) that not all of the binding paths can be > > returned in that property. > > It returns all bindings (each with a URI to the collection it's in). If > you need to compute all *paths*, you'll need to redo that step > recursively for these collections. > > > Is the idea that the client would walk up the tree looking for other paths > > to this resource? > > Yes, if it needs to. It just has to keep in mind that doing it without > special loop checks may result in an infinite loop. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0010BCED85256F8F_= Content-Type: text/html; charset="US-ASCII"
One minor terminological correction.

When Julian said "you can't display *all* bindings to a resource",
he meant to say "you can't display all paths a resource is mapped to"
(you can display all bindings to a resource, since there are only
a finite number of them, and they are enumerated by the DAV:parent-set
property).

Cheers,
Geoff

Julian wrote on 01/19/2005 12:44:12 PM:
>
> Joe Hildebrand wrote:
> > Assume I'm writing an authoring client, and want to show UI to theuser with
> > an enumeration of all of the bindings to a particular resource.  Section 2.9
>
> In general, you can't display *all* bindings to a resource. There may be
> an infinite number (if a parent collection has a bind loop).
>
> > of BIND says I get the DAV:parent-set property.  However, section 3.2 says
> > (and the example in 3.2.1 confirms) that not all of the binding paths can be
> > returned in that property.
>
> It returns all bindings (each with a URI to the collection it's in). If
> you need to compute all *paths*, you'll need to redo that step
> recursively for these collections.
>
> > Is the idea that the client would walk up the tree looking for other paths
> > to this resource?
>
> Yes, if it needs to. It just has to keep in mind that doing it without
> special loop checks may result in an infinite loop.
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0010BCED85256F8F_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 22:26:07 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25806 for ; Wed, 19 Jan 2005 22:26:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrSwO-0005My-Qc for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 03:25:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrSwK-0005J6-17 for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 03:24:56 +0000 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by bart.w3.org with esmtp (Exim 4.34) id 1CrSwJ-0004EL-S7 for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 03:24:55 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0K3OP8S001701 for ; Wed, 19 Jan 2005 22:24:25 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0K3OPWw229684 for ; Wed, 19 Jan 2005 22:24:25 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0K3OOuO013623 for ; Wed, 19 Jan 2005 22:24: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 j0K3OOp5013620 for ; Wed, 19 Jan 2005 22:24:24 -0500 In-Reply-To: <41EF1D37.4030200@cse.ucsc.edu> To: WebDAV WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 22:24:25 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 22:24:24, Serialize complete at 01/19/2005 22:24:24 Content-Type: multipart/alternative; boundary="=_alternative 0012B6E485256F8F_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.146 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF2EEED492.F29A464F-ON85256F8F.0010CD3C-85256F8F.0012B6E6@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9313 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 03:25:00 +0000 This is a multipart message in MIME format. --=_alternative 0012B6E485256F8F_= Content-Type: text/plain; charset="US-ASCII" If there were a well-defined (and finite) number of such "guidances", I could live with it (and it was on that basis that I reluctantly agreed to adding the "guidance" text about locking). But as soon as we agree to one such "guidance", a new one is suggested. I despair of ever getting the BIND protocol published if it is delayed until it has become a complete "implementation guide". I noticed that yet another such request for "guidance text" has just been posted to the bug database [bug 71]. I also note that nothing in the "bug" has to do with any of the methods or properties defined by the binding specification, but is about access control. I have nothing against asking for guidance from the mailing list, but holding a specification hostage until all of your implementation issues have been addressed by the mailing list seems a bit unreasonable. Cheers, Geoff Elias wrote on 01/19/2005 09:53:43 PM: > > Geoffrey M Clemm wrote: > > > I agree with Roy's rationale and conclusion, and support the removal > > of the reference to live properties in section 2.6 > > So, in effect, the spec will state that dead properties MUST be the same > across all bindings to a given resource, and that (by remaining silent > on the issue) live properties MAY vary depending on server > implementation. I am not oposed to this, however as a guide to client > implementors it might be nice to point out that they can't neccessarily > depend on live properties being the same across all bindings to a resource. --=_alternative 0012B6E485256F8F_= Content-Type: text/html; charset="US-ASCII"
If there were a well-defined (and finite) number of such "guidances",
I could live with it (and it was on that basis that I reluctantly
agreed to adding the "guidance" text about locking).

But as soon as we agree to one such "guidance", a new one is suggested.
I despair of ever getting the BIND protocol published if it is delayed
until it has become a complete "implementation guide".

I noticed that yet another such request for "guidance text" has just been posted to the
bug database [bug 71].  I also note that nothing in the "bug" has to
do with any of the methods or properties defined by the binding specification,
but is about access control.

I have nothing against asking for guidance from the mailing list,
but holding a specification hostage until all of your implementation
issues have been addressed by the mailing list seems a bit unreasonable.  

Cheers,
Geoff


Elias wrote on 01/19/2005 09:53:43 PM:
>
> Geoffrey M Clemm wrote:
>
> > I agree with Roy's rationale and conclusion, and support the  removal
> > of the reference to live properties in section 2.6
>
> So, in effect, the spec will state that dead properties MUST be the same
> across all bindings to a given resource, and that (by remaining silent
> on the issue) live properties MAY vary depending on server
> implementation. I am not oposed to this, however as a guide to client
> implementors it might be nice to point out that they can't neccessarily
> depend on live properties being the same across all bindings to a resource.

 --=_alternative 0012B6E485256F8F_=-- From w3c-dist-auth-request@w3.org Wed Jan 19 22:35:14 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27744 for ; Wed, 19 Jan 2005 22:35:14 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrT5f-0000Ps-Tr for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 03:34:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrT5f-0000Oz-8l; Thu, 20 Jan 2005 03:34:35 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrT5V-00020s-AT; Thu, 20 Jan 2005 03:34:25 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0K3Y37j019350; Wed, 19 Jan 2005 22:34:03 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0K3Y3Gu279666; Wed, 19 Jan 2005 22:34:03 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0K3Y3t2008748; Wed, 19 Jan 2005 22:34:03 -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 j0K3Y3RK008733; Wed, 19 Jan 2005 22:34:03 -0500 In-Reply-To: To: Geoffrey M Clemm Cc: WebDAV WG , w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Wed, 19 Jan 2005 22:34:07 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/19/2005 22:34:02, Serialize complete at 01/19/2005 22:34:02 Content-Type: multipart/alternative; boundary="=_alternative 00139A3085256F8F_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.143 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF795C5357.C5515B22-ON85256F8F.00132DCB-85256F8F.00139A31@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9314 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 03:34:35 +0000 This is a multipart message in MIME format. --=_alternative 00139A3085256F8F_= Content-Type: text/plain; charset="US-ASCII" And just to be clear (and to apologize for being a bit testy in the message below :-), Elias was not the one posting requests for implementation help ... his posts have all been very reasonable (:-). Cheers, Geoff Geoff wrote on 01/19/2005 10:24:25 PM: > > If there were a well-defined (and finite) number of such "guidances", > I could live with it (and it was on that basis that I reluctantly > agreed to adding the "guidance" text about locking). > > But as soon as we agree to one such "guidance", a new one is suggested. > I despair of ever getting the BIND protocol published if it is delayed > until it has become a complete "implementation guide". > > I noticed that yet another such request for "guidance text" has just > been posted to the > bug database [bug 71]. I also note that nothing in the "bug" has to > do with any of the methods or properties defined by the binding specification, > but is about access control. > > I have nothing against asking for guidance from the mailing list, > but holding a specification hostage until all of your implementation > issues have been addressed by the mailing list seems a bit unreasonable. > > Cheers, > Geoff > > > Elias wrote on 01/19/2005 09:53:43 PM: > > > > Geoffrey M Clemm wrote: > > > > > I agree with Roy's rationale and conclusion, and support the removal > > > of the reference to live properties in section 2.6 > > > > So, in effect, the spec will state that dead properties MUST be the same > > across all bindings to a given resource, and that (by remaining silent > > on the issue) live properties MAY vary depending on server > > implementation. I am not oposed to this, however as a guide to client > > implementors it might be nice to point out that they can't neccessarily > > depend on live properties being the same across all bindings to a resource. --=_alternative 00139A3085256F8F_= Content-Type: text/html; charset="US-ASCII"
And just to be clear (and to apologize for being a bit testy
in the message below :-), Elias was not the one posting requests
for implementation help ... his posts have all been very reasonable (:-).

Cheers,
Geoff

Geoff wrote on 01/19/2005 10:24:25 PM:
>
> If there were a well-defined (and finite) number of such "guidances",
> I could live with it (and it was on that basis that I reluctantly
> agreed to adding the "guidance" text about locking).
>
> But as soon as we agree to one such "guidance", a new one is suggested.
> I despair of ever getting the BIND protocol published if it is delayed
> until it has become a complete "implementation guide".
>
> I noticed that yet another such request for "guidance text" has just
> been posted to the
> bug database [bug 71].  I also note that nothing in the "bug" has to
> do with any of the methods or properties defined by the binding specification,
> but is about access control.
>
> I have nothing against asking for guidance from the mailing list,
> but holding a specification hostage until all of your implementation
> issues have been addressed by the mailing list seems a bit unreasonable.  
>
> Cheers,
> Geoff
>
>
> Elias wrote on 01/19/2005 09:53:43 PM:
> >
> > Geoffrey M Clemm wrote:
> >
> > > I agree with Roy's rationale and conclusion, and support the  removal
> > > of the reference to live properties in section 2.6
> >
> > So, in effect, the spec will state that dead properties MUST be the same
> > across all bindings to a given resource, and that (by remaining silent
> > on the issue) live properties MAY vary depending on server
> > implementation. I am not oposed to this, however as a guide to client
> > implementors it might be nice to point out that they can't neccessarily
> > depend on live properties being the same across all bindings to a resource.
 --=_alternative 00139A3085256F8F_=-- From w3c-dist-auth-request@w3.org Thu Jan 20 00:55:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09207 for ; Thu, 20 Jan 2005 00:55:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrVGL-0007zI-BM for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 05:53:45 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrVGJ-0007xo-GQ for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 05:53:43 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CrVGJ-0001SD-1X for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 05:53:43 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0K5rcaa015209 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Jan 2005 21:53:41 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41EF1D37.4030200@cse.ucsc.edu> References: <41EF1D37.4030200@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9CDB1025-6AA7-11D9-BEE8-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Wed, 19 Jan 2005 21:53:30 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/9CDB1025-6AA7-11D9-BEE8-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9315 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 05:53:45 +0000 Content-Transfer-Encoding: 7bit I agree with Elias -- I'm not insisting on any particular requirements, but I have definitely found that when the spec is entirely silent on an issue (particularly on an issue where implementations may vary and the variations can affect interoperability), readers unconsciously fill in with their assumptions. Lisa On Jan 19, 2005, at 6:53 PM, Elias Sinderson wrote: > > Geoffrey M Clemm wrote: > >> I agree with Roy's rationale and conclusion, and support the removal >> of the reference to live properties in section 2.6 > > So, in effect, the spec will state that dead properties MUST be the > same across all bindings to a given resource, and that (by remaining > silent on the issue) live properties MAY vary depending on server > implementation. I am not oposed to this, however as a guide to client > implementors it might be nice to point out that they can't > neccessarily depend on live properties being the same across all > bindings to a resource. > > > Cheers, > Elias > From w3c-dist-auth-request@w3.org Thu Jan 20 07:05:40 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19732 for ; Thu, 20 Jan 2005 07:05:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Crb1k-0008TG-QE for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 12:03:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Crb1k-0008Sm-2s for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 12:03:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Crb1j-0006QF-S4 for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 12:03:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0KC33Hp007286; Thu, 20 Jan 2005 04:03:03 -0800 Date: Thu, 20 Jan 2005 04:03:03 -0800 Message-Id: <200501201203.j0KC33Hp007286@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 71] Clarify what servers may and may not do with privileges when BIND is used X-Archived-At: http://www.w3.org/mid/200501201203.j0KC33Hp007286@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9316 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 12:03:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-20 04:03 ------- As far as I can tell, this is not a question about BIND at all -- applying MOVE to the resource, moving it from one collection to the other would lead to the same questions. If you feel that the working group can give an answer here (which I doubt), then you probably should raise an issue against RFC3744 (see for mailing list 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@w3.org Thu Jan 20 07:21:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21331 for ; Thu, 20 Jan 2005 07:21:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrbIR-0004wj-F5 for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 12:20:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrbIR-0004wB-62 for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 12:20:19 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CrbIQ-0001ct-VB for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 12:20:19 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0KCKIQv007330; Thu, 20 Jan 2005 04:20:18 -0800 Date: Thu, 20 Jan 2005 04:20:18 -0800 Message-Id: <200501201220.j0KCKIQv007330@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 71] Clarify what servers may and may not do with privileges when BIND is used X-Archived-At: http://www.w3.org/mid/200501201220.j0KCKIQv007330@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9317 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 12:20:19 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71 ------- Additional Comments From geoffrey.clemm@us.ibm.com 2005-01-20 04:20 ------- I agree with 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@w3.org Thu Jan 20 07:25:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21519 for ; Thu, 20 Jan 2005 07:25:53 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrbNE-0006B2-UE for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 12:25:16 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CrbNE-0006AT-Ka for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 12:25:16 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CrbN4-0002YR-Lw for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 12:25:06 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0KCOjSK000796 for ; Thu, 20 Jan 2005 07:24:45 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0KCOjWw269682 for ; Thu, 20 Jan 2005 07:24:45 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0KCOjoS024111 for ; Thu, 20 Jan 2005 07:24:45 -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 j0KCOjbK024108; Thu, 20 Jan 2005 07:24:45 -0500 In-Reply-To: To: Joe Hildebrand Cc: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 20 Jan 2005 07:24:42 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/20/2005 07:24:44, Serialize complete at 01/20/2005 07:24:44 Content-Type: multipart/alternative; boundary="=_alternative 00442D6C85256F8F_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Please add bugzilla "products" for RFC-3744 and RFC-3253 X-Archived-At: http://www.w3.org/mid/OF4E876A76.0443DE74-ON85256F8F.0043E6B9-85256F8F.00442D70@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9318 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 12:25:16 +0000 This is a multipart message in MIME format. --=_alternative 00442D6C85256F8F_= Content-Type: text/plain; charset="US-ASCII" Joe: Please add bugzilla "products" for "WebDAV-RFC 3253" and "WebDAV-RFC 3744" Thanks, Geoff --=_alternative 00442D6C85256F8F_= Content-Type: text/html; charset="US-ASCII"
Joe:

Please add bugzilla "products" for "WebDAV-RFC 3253" and "WebDAV-RFC 3744"

Thanks,
Geoff
--=_alternative 00442D6C85256F8F_=-- From w3c-dist-auth-request@w3.org Thu Jan 20 12:54:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19805 for ; Thu, 20 Jan 2005 12:54:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrgUK-0000EC-UK for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 17:52:56 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrgUK-0000De-9k for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 17:52:56 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by bart.w3.org with esmtp (Exim 4.34) id 1CrgUK-0002lG-4R for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 17:52:56 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 09:52:24 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41EF1D37.4030200@cse.ucsc.edu> References: <41EF1D37.4030200@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0A74A7F4-6B0C-11D9-A835-000A95AACED2@xythos.com> Content-Transfer-Encoding: 7bit From: Brian Korver Date: Thu, 20 Jan 2005 09:52:24 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 20 Jan 2005 17:52:24.0069 (UTC) FILETIME=[CC098350:01C4FF18] Received-SPF: none (bart.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/0A74A7F4-6B0C-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9319 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 17:52:56 +0000 Content-Transfer-Encoding: 7bit On Jan 19, 2005, at 6:53 PM, Elias Sinderson wrote: > So, in effect, the spec will state that dead properties MUST be the > same across all bindings to a given resource, and that (by remaining > silent on the issue) live properties MAY vary depending on server > implementation. I am not oposed to this, however as a guide to client > implementors it might be nice to point out that they can't > neccessarily depend on live properties being the same across all > bindings to a resource. > > > Cheers, > Elias > I agree. I believe this change would make the spec better, not worse. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Jan 20 15:58:11 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05141 for ; Thu, 20 Jan 2005 15:58:11 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrjM6-0001rC-2g for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 20:56:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrjM5-0001qi-DH for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 20:56:37 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by bart.w3.org with esmtp (Exim 4.34) id 1CrjM5-000676-68 for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 20:56:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05026; Thu, 20 Jan 2005 15:56:33 -0500 (EST) Message-Id: <200501202056.PAA05026@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Date: Thu, 20 Jan 2005 15:56:33 -0500 Received-SPF: none (bart.w3.org: domain of dinaras@cnri.reston.va.us does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/200501202056.PAA05026@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9320 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 20:56:38 +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 : Quota and Size Properties for DAV Collections Author(s) : B. Korver, et al. Filename : draft-ietf-webdav-quota-05.txt Pages : 10 Date : 2005-1-20 WebDAV servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-05.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-quota-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-quota-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-20161845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-quota-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-quota-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-20161845.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Jan 20 16:32:41 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08677 for ; Thu, 20 Jan 2005 16:32:41 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Crjty-0005a4-6A for w3c-dist-auth-dist@listhub.w3.org; Thu, 20 Jan 2005 21:31:38 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Crjtx-0005Za-J0 for w3c-dist-auth@listhub.w3.org; Thu, 20 Jan 2005 21:31:37 +0000 Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com) by lisa.w3.org with esmtp (Exim 4.34) id 1Crjtn-0002sj-I1 for w3c-dist-auth@w3.org; Thu, 20 Jan 2005 21:31:27 +0000 Received: from [192.168.1.151] ([64.154.218.194]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jan 2005 13:31:03 -0800 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDAV WG From: Brian Korver Date: Thu, 20 Jan 2005 13:31:02 -0800 X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 20 Jan 2005 21:31:03.0165 (UTC) FILETIME=[57A0B2D0:01C4FF37] Received-SPF: none (lisa.w3.org: domain of briank@xythos.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9321 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jan 2005 21:31:38 +0000 Content-Transfer-Encoding: 7bit This version incorporates all of the editorial fixes that Julian pointed out previously, plus renames storage-quota-reached to quota-not-exceeded. As far as I'm aware, the only outstanding issue is whether we use the string "quota" or something else. -brian briank@xythos.com Begin forwarded message: > Resent-From: w3c-dist-auth@w3.org > From: Internet-Drafts@ietf.org > Date: January 20, 2005 12:56:33 PM PST > To: i-d-announce@ietf.org > Cc: w3c-dist-auth@w3.org > Subject: I-D ACTION:draft-ietf-webdav-quota-05.txt > > 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 : Quota and Size Properties for DAV Collections > Author(s) : B. Korver, et al. > Filename : draft-ietf-webdav-quota-05.txt > Pages : 10 > Date : 2005-1-20 > > WebDAV servers are frequently deployed with quota (size) limitations. > This document discusses the properties and minor behaviors needed > for > clients to interoperate with quota (size) implementations on WebDAV > repositories. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-05.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-quota-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-webdav-quota-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-1-20161845.I-D@ietf.org> > From w3c-dist-auth-request@w3.org Thu Jan 20 20:11:09 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03577 for ; Thu, 20 Jan 2005 20:11:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CrnHo-0005HO-MZ for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 01:08:28 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrnHn-0005Gk-Uo for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 01:08:27 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.34) id 1CrnHn-0006xK-MM for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 01:08:27 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0L18QoF006557; Thu, 20 Jan 2005 17:08:26 -0800 (PST) Message-Id: <200501210108.j0L18QoF006557@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Brian Korver'" , "'WebDAV WG'" Date: Thu, 20 Jan 2005 17:08:22 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <0A74A7F4-6B0C-11D9-A835-000A95AACED2@xythos.com> Thread-Index: AcT/GQjKJ90NKyhETumChu5VLS2DVgAPJnPw Received-SPF: none (bart.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? X-Archived-At: http://www.w3.org/mid/200501210108.j0L18QoF006557@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9322 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 01:08:28 +0000 Content-Transfer-Encoding: 7bit I can support this language as well. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Brian Korver > Sent: Thursday, January 20, 2005 9:52 AM > To: WebDAV WG > Subject: Re: ETags? > > > On Jan 19, 2005, at 6:53 PM, Elias Sinderson wrote: > > So, in effect, the spec will state that dead properties MUST be the > > same across all bindings to a given resource, and that (by > remaining > > silent on the issue) live properties MAY vary depending on server > > implementation. I am not oposed to this, however as a guide > to client > > implementors it might be nice to point out that they can't > > neccessarily depend on live properties being the same across all > > bindings to a resource. > > > > > > Cheers, > > Elias > > > > I agree. I believe this change would make the spec better, not worse. > > -brian > briank@xythos.com > > > From w3c-dist-auth-request@w3.org Fri Jan 21 16:47:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25697 for ; Fri, 21 Jan 2005 16:47:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs6b5-0004jU-84 for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 21:45:39 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs6b3-0004ii-FW for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 21:45:37 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cs6at-0007Rz-87 for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 21:45:27 +0000 Received: (qmail invoked by alias); 21 Jan 2005 21:45:03 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp008) with SMTP; 21 Jan 2005 22:45:03 +0100 X-Authenticated: #1915285 Message-ID: <41F177D3.3010406@gmx.de> Date: Fri, 21 Jan 2005 22:44:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Lisa Dusseault , "WebDAV WG)" References: <53146294-69B1-11D9-A835-000A95AACED2@xythos.com> <41EDAF57.3070206@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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F177D3.3010406@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9323 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 21:45:39 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > ... > There are two sections to consider in the bindings draft: > > 2.6 PROPFIND and Bindings > > Consistent with [RFC2518] the value of a dead property MUST be, and > the value of a live property SHOULD be, independent of the number of > bindings to its host resource or of the path submitted to PROPFIND. > > which I consider to be in error because live properties are owned > by the server -- any requirement that they be consistent across > bindings is wrong. > ... OK, re-opening issue "2.6_bindings_vs_properties": . Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 21 16:50:13 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26012 for ; Fri, 21 Jan 2005 16:50:12 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs6et-0005XX-T1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 21:49:35 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs6et-0005Wi-DN for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 21:49:35 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cs6et-0003lb-29 for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 21:49:35 +0000 Received: (qmail invoked by alias); 21 Jan 2005 21:49:02 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp017) with SMTP; 21 Jan 2005 22:49:02 +0100 X-Authenticated: #1915285 Message-ID: <41F178C6.4010508@gmx.de> Date: Fri, 21 Jan 2005 22:48:54 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoffrey M Clemm 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F178C6.4010508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9324 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 21:49:35 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > If there were a well-defined (and finite) number of such "guidances", > I could live with it (and it was on that basis that I reluctantly > agreed to adding the "guidance" text about locking). > > But as soon as we agree to one such "guidance", a new one is suggested. > I despair of ever getting the BIND protocol published if it is delayed > until it has become a complete "implementation guide". > > I noticed that yet another such request for "guidance text" has just > been posted to the > bug database [bug 71]. I also note that nothing in the "bug" has to > do with any of the methods or properties defined by the binding > specification, > but is about access control. > > I have nothing against asking for guidance from the mailing list, > but holding a specification hostage until all of your implementation > issues have been addressed by the mailing list seems a bit unreasonable. > > Cheers, > Geoff For the record: I completely agree with that statement. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 21 16:56:55 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26948 for ; Fri, 21 Jan 2005 16:56:55 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs6lE-0007Wl-6U for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 21:56:08 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs6lC-0007Vu-8W for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 21:56:06 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cs6lB-0004dL-TN for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 21:56:06 +0000 Received: (qmail invoked by alias); 21 Jan 2005 21:55:33 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp009) with SMTP; 21 Jan 2005 22:55:33 +0100 X-Authenticated: #1915285 Message-ID: <41F17A4C.40904@gmx.de> Date: Fri, 21 Jan 2005 22:55:24 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> In-Reply-To: <41EF1D37.4030200@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F17A4C.40904@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9325 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 21:56:08 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > > Geoffrey M Clemm wrote: > >> I agree with Roy's rationale and conclusion, and support the removal >> of the reference to live properties in section 2.6 > > > So, in effect, the spec will state that dead properties MUST be the same > across all bindings to a given resource, and that (by remaining silent > on the issue) live properties MAY vary depending on server > implementation. I am not oposed to this, however as a guide to client > implementors it might be nice to point out that they can't neccessarily > depend on live properties being the same across all bindings to a resource. I'm not happy with this text, as it sort-of *encourages* people to define live properties that way. So *if* the spec makes a statement about dead properties, but *doesn't* make statement about live properties, that should be clear enough ("if the spec author's would have wanted to make a statement about live properties, they would have done it here"). Having the choice between two text versions that technically say the same, I'm voting for the shorter and simpler one. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 21 17:37:38 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29570 for ; Fri, 21 Jan 2005 17:37:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs7OV-00036G-8A for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 22:36:43 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs7OU-00035i-EQ for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 22:36:42 +0000 Received: from gate.arc.nasa.gov ([128.102.102.51]) by bart.w3.org with esmtp (Exim 4.34) id 1Cs7OU-0002Ip-4G for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 22:36:42 +0000 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0LMacP20723 for ; Fri, 21 Jan 2005 14:36:38 -0800 (PST) Message-ID: <41F183F6.3000904@cse.ucsc.edu> Date: Fri, 21 Jan 2005 14:36:38 -0800 From: Elias Sinderson Reply-To: WebDAV WG User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> In-Reply-To: <41F17A4C.40904@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F183F6.3000904@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9326 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 22:36:43 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Elias Sinderson wrote: > >> So, in effect, the spec will state that dead properties MUST be the >> same across all bindings to a given resource, and that (by remaining >> silent on the issue) live properties MAY vary depending on server >> implementation. [...] > > I'm not happy with this text, as it sort-of *encourages* people to > define live properties that way. Just to be clear, I wasn't proposing any specific text, but merely observing that a note to client implementors would probably be useful. I agree that the use of MAY as above would likely encourage the definition of live properties that vary across bindings. > So *if* the spec makes a statement about dead properties, but > *doesn't* make statement about live properties, that should be clear > enough ("if the spec author's would have wanted to make a statement > about live properties, they would have done it here"). Hmm, I can imagine client implementors having discussions about this. Including a single sentence which states that clients can't necessarily depend on live properties being the same on different bindings to a given resource. > Having the choice between two text versions that technically say the > same, I'm voting for the shorter and simpler one. I generally agree, however this seems to be a case in which a little guidance could prevent a lot of headaches since the question will undoubtedly arise. OTOH, it does run dangerously close to Geoffs' statement regarding such guidances... I certainly don't feel strongly enough about the issue to hold up the BIND spec. Cheers, Elias From w3c-dist-auth-request@w3.org Fri Jan 21 17:45:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29928 for ; Fri, 21 Jan 2005 17:45:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs7Vv-0005g2-PP for w3c-dist-auth-dist@listhub.w3.org; Fri, 21 Jan 2005 22:44:23 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs7Vv-0005eO-76 for w3c-dist-auth@listhub.w3.org; Fri, 21 Jan 2005 22:44:23 +0000 Received: from gate.arc.nasa.gov ([128.102.102.51]) by bart.w3.org with esmtp (Exim 4.34) id 1Cs7Vu-0003Gi-TO for w3c-dist-auth@w3.org; Fri, 21 Jan 2005 22:44:23 +0000 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id j0LMiLP20783 for ; Fri, 21 Jan 2005 14:44:21 -0800 (PST) Message-ID: <41F185C5.8090805@cse.ucsc.edu> Date: Fri, 21 Jan 2005 14:44:21 -0800 From: Elias Sinderson Reply-To: WebDAV WG User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> In-Reply-To: <41F183F6.3000904@cse.ucsc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: none (bart.w3.org: domain of elias@cse.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F185C5.8090805@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9327 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jan 2005 22:44:23 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > [...] Including a single sentence which states that clients can't > necessarily depend on live properties being the same on different > bindings to a given resource. ... doesn't seem like an undue amount of verbiage in the spec. Again, Elias From w3c-dist-auth-request@w3.org Fri Jan 21 19:39:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10085 for ; Fri, 21 Jan 2005 19:39:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cs9Ha-00029K-Ck for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Jan 2005 00:37:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs9HZ-00028i-Kt for w3c-dist-auth@listhub.w3.org; Sat, 22 Jan 2005 00:37:41 +0000 Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by bart.w3.org with esmtp (Exim 4.34) id 1Cs9HZ-0002oP-9h for w3c-dist-auth@w3.org; Sat, 22 Jan 2005 00:37:41 +0000 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j0M0bc322577 for ; Sat, 22 Jan 2005 01:37:39 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005012201373693:12345 ; Sat, 22 Jan 2005 01:37:36 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F185C5.8090805@cse.ucsc.edu> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> Message-Id: From: "Roy T. Fielding" Date: Fri, 21 Jan 2005 16:37:37 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/22/2005 01:37:37 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 01/22/2005 01:37:38 AM, Serialize complete at 01/22/2005 01:37:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/D086F8AD-6C0D-11D9-BBF5-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9328 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Jan 2005 00:37:42 +0000 Content-Transfer-Encoding: 7bit On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: >> [...] Including a single sentence which states that clients can't >> necessarily depend on live properties being the same on different >> bindings to a given resource. > > ... doesn't seem like an undue amount of verbiage in the spec. It does to me, and I guess an explanation is in order. Let's say that a given live property definition does specify that its value must remain the same on different bindings to the same resource. In that case, the client can depend on them being the same and that simple little addition creates an unnecessary contradiction between what should have been orthogonal specifications. There is no reason for the binding specification to make blanket statements when there are no conditions that hold for all live properties -- that is why we have property definitions. Developers don't need any more guidance here. What they need are shorter specifications so that they don't have to waste their time digging through meaningless tripe just to understand the interface. ....Roy From w3c-dist-auth-request@w3.org Sat Jan 22 14:36:54 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26804 for ; Sat, 22 Jan 2005 14:36:54 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CsR10-0008C7-QU for w3c-dist-auth-dist@listhub.w3.org; Sat, 22 Jan 2005 19:33:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CsR0w-0008AN-KG for w3c-dist-auth@listhub.w3.org; Sat, 22 Jan 2005 19:33:42 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CsR0m-0006x6-9F for w3c-dist-auth@w3.org; Sat, 22 Jan 2005 19:33:32 +0000 Received: (qmail invoked by alias); 22 Jan 2005 19:33:08 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp025) with SMTP; 22 Jan 2005 20:33:08 +0100 X-Authenticated: #1915285 Message-ID: <41F2AA5B.6070503@gmx.de> Date: Sat, 22 Jan 2005 20:32:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@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 (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F2AA5B.6070503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9329 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 22 Jan 2005 19:33:46 +0000 Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: > >>> [...] Including a single sentence which states that clients can't >>> necessarily depend on live properties being the same on different >>> bindings to a given resource. >> >> >> ... doesn't seem like an undue amount of verbiage in the spec. > > > It does to me, and I guess an explanation is in order. Let's > say that a given live property definition does specify that its > value must remain the same on different bindings to the same > resource. In that case, the client can depend on them being > the same and that simple little addition creates an unnecessary > contradiction between what should have been orthogonal > specifications. There is no reason for the binding specification > to make blanket statements when there are no conditions that hold > for all live properties -- that is why we have property definitions. > > Developers don't need any more guidance here. What they need are > shorter specifications so that they don't have to waste their time > digging through meaningless tripe just to understand the interface. Thanks for the explanation. I do agree that the statement as proprosed is not only unnecessary but actually harmful. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Jan 22 22:40:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00843 for ; Sat, 22 Jan 2005 22:40:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CsYZq-0007Is-9M for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Jan 2005 03:38:14 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CsYZo-0007IB-6N for w3c-dist-auth@listhub.w3.org; Sun, 23 Jan 2005 03:38:12 +0000 Received: from mail22.sea5.speakeasy.net ([69.17.117.24] helo=mail14.speakeasy.net) by lisa.w3.org with esmtp (Exim 4.34) id 1CsYZd-0000Wb-VZ for w3c-dist-auth@w3.org; Sun, 23 Jan 2005 03:38:02 +0000 Received: (qmail 1374 invoked from network); 23 Jan 2005 03:38:09 -0000 Received: from adsl-63-194-88-161.dsl.snfc21.pacbell.net (HELO cse.ucsc.edu) (elias@[63.194.88.161]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Jan 2005 03:38:09 -0000 Message-ID: <41F31C1A.3080508@cse.ucsc.edu> Date: Sat, 22 Jan 2005 19:38:02 -0800 From: Elias Sinderson Reply-To: WebDAV WG User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> 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-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F31C1A.3080508@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9330 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Jan 2005 03:38:14 +0000 Content-Transfer-Encoding: 7bit Thanks Roy, that's an excellent point that I hadn't considered. For the record, I am no longer opposed to the spec remaining silent on the issue. Cheers, Elias ________________________________ Roy T. Fielding wrote: > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: > >>> [...] Including a single sentence which states that clients can't >>> necessarily depend on live properties being the same on different >>> bindings to a given resource. >> >> >> ... doesn't seem like an undue amount of verbiage in the spec. > > > It does to me, and I guess an explanation is in order. Let's > say that a given live property definition does specify that its > value must remain the same on different bindings to the same > resource. In that case, the client can depend on them being > the same and that simple little addition creates an unnecessary > contradiction between what should have been orthogonal > specifications. There is no reason for the binding specification > to make blanket statements when there are no conditions that hold > for all live properties -- that is why we have property definitions. > > Developers don't need any more guidance here. What they need are > shorter specifications so that they don't have to waste their time > digging through meaningless tripe just to understand the interface. > > ....Roy > From w3c-dist-auth-request@w3.org Sun Jan 23 07:18:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09281 for ; Sun, 23 Jan 2005 07:18:35 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Csgf3-00043d-15 for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Jan 2005 12:16:09 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Csgf2-00042y-AY for w3c-dist-auth@listhub.w3.org; Sun, 23 Jan 2005 12:16:08 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Csges-0005mv-25 for w3c-dist-auth@w3.org; Sun, 23 Jan 2005 12:15:58 +0000 Received: (qmail invoked by alias); 23 Jan 2005 12:15:24 -0000 Received: from pD953573C.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.87.60) by mail.gmx.net (mp020) with SMTP; 23 Jan 2005 13:15:24 +0100 X-Authenticated: #1915285 Message-ID: <41F3953C.9060702@gmx.de> Date: Sun, 23 Jan 2005 13:14:52 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Korver CC: WebDAV WG References: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.com> In-Reply-To: <95C2A37A-6B2A-11D9-A835-000A95AACED2@xythos.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt X-Archived-At: http://www.w3.org/mid/41F3953C.9060702@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9331 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Jan 2005 12:16:09 +0000 Content-Transfer-Encoding: 7bit Hi, below is my updated issues list. In general, this draft is a real improvement, and besides mainly editorial questions, the main issue the working group should consider is whether the Quota spec should handle disk limits (right now it does implicitly). I personally would prefer if it either wouldn't do it at all, or do it explicitly (through at least a different set of precondition names). Best regards, Julian - snip - Issues with draft-ietf-webdav-quota-05.txt Content 01-C03 quota vs disk space The spec says that servers may expose physical disk limits as quota. a) This is incompatible with NFS from which we're borrowing the semantics (it treats disk limits as a separate property, and so should we) Update -04: this still appears in the text, but is less critical now that authorability of the quota is gone. I'd still like to see the working group make an explicit decision to keep this, because it's IMHO clearly outside the scope of this spec (I'd prefer separate properties). 04-C06, section 3, DAV:quota-available-bytes "The DAV:quota-available-bytes property value is the value in octets representing the amount of additional disk space beyond the current allocation that can be allocated to this file or directory before further allocations will be refused. It is understood that this space may be consumed by allocations to other files or directories." Replace "file or directory" by "resource". Note that neither "file" or "directory" exist in WebDAV terminology. (same in section 4) 04-C07, section 3, DAV:quota-available-bytes "Support for this property is REQUIRED on collections, and OPTIONAL on other resources. A server SHOULD implement this property for each resource that has the DAV:quota-used-bytes property." What's the motivation for the distinction? (same in section 4) Update -05: this is actually in contradiction to Section 3 which says: " Implementing both DAV:quota-available-bytes and DAV:quota-used-bytes on all resources is RECOMMENDED." (note OPTIONAL != RECOMMENDED). In general, I think it would be wiser to have these requirements in a single place (so the spec can't contradict itself), whatever they are. 04-C11, section 7 "The total size of a collection, DAV:quota-used-bytes, is not necessarily a sum of the DAV:getcontentlength properties for resources stored in the collection." Actually, it won't be in most cases I'm aware of. Please either rephrase it (so this doesn't sound like an edge case) or drop the point. 05-C01, Section 4, last para "Support for this property enhances the client experience, because together with DAV:quota-available-bytes, the client has a chance of managing its files to avoid running out of allocated storage space. Clients may not be able to calculate the value as accurately on their own, depending on how total space used is calculated by the server." I think this is fluff; if you want say something like that, move it into the Introduction (where the motivation for the whole spec is explained). 05-C02, Section 4 I think this property is "computed" (as defined in RFC3253), and the spec should say so. 05-E01, section 1.2 I'd move those parts that "import" terminology from RFC2518/3253 into a separate subsection ("Terminology"), and also refer to the def of "computed" property (I think we need that later). 05-E02, section 1.2 "In order to work best with repositories that support quotas, client software should be able to determine and display the DAV:quota-available-bytes on collections." That is a forward reference. Either add "(defined below in ...)", or rewrite as: "In order to work best with repositories that support quotas, client software should be able to determine and display the new live properties defined below." 05-E02, section 5 The artwork in the request is too wide for RFC publication and should be re-indented (the response isn't too wide but should be re-indented for consistency nevertheless). 05-E03, section 7 In the list, please make punctuation consistent. From w3c-dist-auth-request@w3.org Sun Jan 23 10:52:34 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21496 for ; Sun, 23 Jan 2005 10:52:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Csk12-0000KC-L0 for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Jan 2005 15:51:04 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Csk11-0000JX-U3 for w3c-dist-auth@listhub.w3.org; Sun, 23 Jan 2005 15:51:03 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1Csk0r-0002y0-Mx for w3c-dist-auth@w3.org; Sun, 23 Jan 2005 15:50:53 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0NFoxaa013931 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 23 Jan 2005 07:51:01 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41F31C1A.3080508@cse.ucsc.edu> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8E1C802F-6D56-11D9-961E-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Sun, 23 Jan 2005 07:50:50 -0800 To: WebDAV WG X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/8E1C802F-6D56-11D9-961E-000A95B2BB72@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9332 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Jan 2005 15:51:04 +0000 Content-Transfer-Encoding: 7bit I wish it were so easy to write short, clear specifications that could be unambiguously understood and implemented. I wish features could be orthogonal. However, bindings together with existing WebDAV features, while mostly orthogonal, have a few interesting, confusing or important interactions. This isn't an unlimited set of work, folks. All these issues have been raised before this last call period (except maybe one?) and it isn't an ever growing set. We're talking about maybe half a page of new text to clarify important interactions to implementors, and then we're done and we'll have a really good spec. Lisa On Jan 22, 2005, at 7:38 PM, Elias Sinderson wrote: > > Thanks Roy, that's an excellent point that I hadn't considered. For > the record, I am no longer opposed to the spec remaining silent on the > issue. > > > Cheers, > Elias > ________________________________ > > Roy T. Fielding wrote: > >> >> On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: >> >>>> [...] Including a single sentence which states that clients can't >>>> necessarily depend on live properties being the same on different >>>> bindings to a given resource. >>> >>> >>> ... doesn't seem like an undue amount of verbiage in the spec. >> >> >> It does to me, and I guess an explanation is in order. Let's >> say that a given live property definition does specify that its >> value must remain the same on different bindings to the same >> resource. In that case, the client can depend on them being >> the same and that simple little addition creates an unnecessary >> contradiction between what should have been orthogonal >> specifications. There is no reason for the binding specification >> to make blanket statements when there are no conditions that hold >> for all live properties -- that is why we have property definitions. >> >> Developers don't need any more guidance here. What they need are >> shorter specifications so that they don't have to waste their time >> digging through meaningless tripe just to understand the interface. >> >> ....Roy >> > > From w3c-dist-auth-request@w3.org Sun Jan 23 18:27:40 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20107 for ; Sun, 23 Jan 2005 18:27:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Csr7K-0000R7-P4 for w3c-dist-auth-dist@listhub.w3.org; Sun, 23 Jan 2005 23:26:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Csr7J-0000Qd-So for w3c-dist-auth@listhub.w3.org; Sun, 23 Jan 2005 23:26:01 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Csr79-0001Zx-IZ for w3c-dist-auth@w3.org; Sun, 23 Jan 2005 23:25:51 +0000 Received: (qmail invoked by alias); 23 Jan 2005 23:25:27 -0000 Received: from p54856134.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.97.52) by mail.gmx.net (mp001) with SMTP; 24 Jan 2005 00:25:27 +0100 X-Authenticated: #1915285 Message-ID: <41F4325E.6030004@gmx.de> Date: Mon, 24 Jan 2005 00:25:18 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <8E1C802F-6D56-11D9-961E-000A95B2BB72@osafoundation.org> In-Reply-To: <8E1C802F-6D56-11D9-961E-000A95B2BB72@osafoundation.org> 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-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F4325E.6030004@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9333 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 23 Jan 2005 23:26:02 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I wish it were so easy to write short, clear specifications that could > be unambiguously understood and implemented. I wish features could be > orthogonal. Features *can* be orthogonal. Sometimes they aren't (in which case a spec needs to say something about it). The more orthogonal you make them, the simpler the specs and the interdependencies. > However, bindings together with existing WebDAV features, while mostly > orthogonal, have a few interesting, confusing or important interactions. > > This isn't an unlimited set of work, folks. All these issues have been > raised before this last call period (except maybe one?) and it isn't an > ever growing set. We're talking about maybe half a page of new text to > clarify important interactions to implementors, and then we're done and > we'll have a really good spec. At this point, unless you have a *specific* proposal for specification text, I don't really find this comment really helpful... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jan 24 12:03:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01342 for ; Mon, 24 Jan 2005 12:03:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ct7ZR-0001Ty-A4 for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Jan 2005 17:00:09 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ct7ZQ-0001TM-Ip for w3c-dist-auth@listhub.w3.org; Mon, 24 Jan 2005 17:00:08 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.34) id 1Ct7ZQ-0005Uo-Cz for w3c-dist-auth@w3.org; Mon, 24 Jan 2005 17:00:08 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0OGxZSK024220 for ; Mon, 24 Jan 2005 11:59:35 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0OGxZQK195682 for ; Mon, 24 Jan 2005 11:59:35 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0OGxYvL019429 for ; Mon, 24 Jan 2005 11:59: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 j0OGxYAk019424 for ; Mon, 24 Jan 2005 11:59:34 -0500 In-Reply-To: <41F31C1A.3080508@cse.ucsc.edu> To: WebDAV WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 24 Jan 2005 11:59:32 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/24/2005 11:59:34, Serialize complete at 01/24/2005 11:59:34 Content-Type: multipart/alternative; boundary="=_alternative 005D570385256F93_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF05AB56C0.C9C46462-ON85256F93.005CFF0F-85256F93.005D5706@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9334 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Jan 2005 17:00:09 +0000 This is a multipart message in MIME format. --=_alternative 005D570385256F93_= Content-Type: text/plain; charset="US-ASCII" I agree with Elias and Julian about the excellence of Roy's point, and would point out that in my opinion, it applies to most/all of the other requests for "guidance" in the binding spec for the behavior of functionality defined in other specifications. Cheers, Geoff Elias wrote on 01/22/2005 10:38:02 PM: > Thanks Roy, that's an excellent point that I hadn't considered. For the > record, I am no longer opposed to the spec remaining silent on the issue. > ________________________________ > > Roy T. Fielding wrote: > > > > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: > > > >>> [...] Including a single sentence which states that clients can't > >>> necessarily depend on live properties being the same on different > >>> bindings to a given resource. > >> > >> > >> ... doesn't seem like an undue amount of verbiage in the spec. > > > > > > It does to me, and I guess an explanation is in order. Let's > > say that a given live property definition does specify that its > > value must remain the same on different bindings to the same > > resource. In that case, the client can depend on them being > > the same and that simple little addition creates an unnecessary > > contradiction between what should have been orthogonal > > specifications. There is no reason for the binding specification > > to make blanket statements when there are no conditions that hold > > for all live properties -- that is why we have property definitions. > > > > Developers don't need any more guidance here. What they need are > > shorter specifications so that they don't have to waste their time > > digging through meaningless tripe just to understand the interface. > > > > ....Roy > > > > --=_alternative 005D570385256F93_= Content-Type: text/html; charset="US-ASCII"
I agree with Elias and Julian about the excellence of Roy's point,
and would point out that in my opinion, it applies to most/all
of the other requests for "guidance" in the binding spec for the
behavior of functionality defined in other specifications.

Cheers,
Geoff

Elias wrote on 01/22/2005 10:38:02 PM:

> Thanks Roy, that's an excellent point that I hadn't considered. For the
> record, I am no longer opposed to the spec remaining silent on the issue.
> ________________________________
>
> Roy T. Fielding wrote:
>
> >
> > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote:
> >
> >>> [...] Including a single sentence which states that clients can't
> >>> necessarily depend on live properties being the same on different
> >>> bindings to a given resource.
> >>
> >>
> >> ... doesn't seem like an undue amount of verbiage in the spec.
> >
> >
> > It does to me, and I guess an explanation is in order.  Let's
> > say that a given live property definition does specify that its
> > value must remain the same on different bindings to the same
> > resource.  In that case, the client can depend on them being
> > the same and that simple little addition creates an unnecessary
> > contradiction between what should have been orthogonal
> > specifications.  There is no reason for the binding specification
> > to make blanket statements when there are no conditions that hold
> > for all live properties -- that is why we have property definitions.
> >
> > Developers don't need any more guidance here.  What they need are
> > shorter specifications so that they don't have to waste their time
> > digging through meaningless tripe just to understand the interface.
> >
> > ....Roy
> >
>
>
--=_alternative 005D570385256F93_=-- From w3c-dist-auth-request@w3.org Mon Jan 24 12:33:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04219 for ; Mon, 24 Jan 2005 12:33:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ct84r-0002Fm-5E for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Jan 2005 17:32:37 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ct84q-0002FI-UE for w3c-dist-auth@listhub.w3.org; Mon, 24 Jan 2005 17:32:36 +0000 Received: from mx1.netapp.com ([216.240.18.38]) by bart.w3.org with esmtp (Exim 4.34) id 1Ct84q-00032s-I8 for w3c-dist-auth@w3.org; Mon, 24 Jan 2005 17:32:36 +0000 Received: from smtp1.corp.netapp.com (10.57.156.124) by mx1.netapp.com with ESMTP; 24 Jan 2005 09:32:05 -0800 X-IronPort-AV: i="3.88,148,1102320000"; d="scan'208,217"; a="86724572:sNHT23934972" Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.57.156.135]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j0OHW4pv024394; Mon, 24 Jan 2005 09:32:04 -0800 (PST) Received: from burgundy.hq.netapp.com ([10.56.10.66]) by svlexc01.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Jan 2005 09:32:04 -0800 Received: from lavender.hq.netapp.com ([10.56.11.75]) by burgundy.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Jan 2005 09:32:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5023A.9E7738EF" Date: Mon, 24 Jan 2005 09:32:03 -0800 Message-ID: <482A3FA0050D21419C269D13989C611326C8ED@lavender-fe.eng.netapp.com> Thread-Topic: ETags? Thread-Index: AcUCNoFeKe57ke5aSsmSWrt1I8svuwAAtoGA From: "Cox, Roger" To: "Geoffrey M Clemm" , "WebDAV WG" X-OriginalArrivalTime: 24 Jan 2005 17:32:04.0420 (UTC) FILETIME=[9EB8D840:01C5023A] Received-SPF: pass (bart.w3.org: domain of Roger.Cox@netapp.com designates 216.240.18.38 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? X-Archived-At: http://www.w3.org/mid/482A3FA0050D21419C269D13989C611326C8ED@lavender-fe.eng.netapp.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9335 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Jan 2005 17:32:37 +0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5023A.9E7738EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an implementor, I found 2518 to be an excellent specification. But sometimes, even though the authors knew what they meant, I didn't know what they meant. Any time the authors of a spec undergo any confusion or disagreement about the meaning of their spec, or discover such confusion among the readers of that spec, they've received a hint that the specification is not as clear as they might have thought, and therefore vulnerable to interoperability problems. =20 It seems to me that if the time and effort to clarify the meaning have been spent, it is an enourmous waste not to make that clarification available to potential implementors. =20 -- Roger -----Original Message----- From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]=20 Sent: Monday, January 24, 2005 9:00 AM To: WebDAV WG Subject: Re: ETags? =09 =09 I agree with Elias and Julian about the excellence of Roy's point,=20 and would point out that in my opinion, it applies to most/all=20 of the other requests for "guidance" in the binding spec for the behavior of functionality defined in other specifications.=20 =09 Cheers,=20 Geoff=20 =09 Elias wrote on 01/22/2005 10:38:02 PM: =09 > Thanks Roy, that's an excellent point that I hadn't considered. For the=20 > record, I am no longer opposed to the spec remaining silent on the issue. > ________________________________ >=20 > Roy T. Fielding wrote: >=20 > > > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: > > > >>> [...] Including a single sentence which states that clients can't=20 > >>> necessarily depend on live properties being the same on different=20 > >>> bindings to a given resource. > >> > >> > >> ... doesn't seem like an undue amount of verbiage in the spec. > > > > > > It does to me, and I guess an explanation is in order. Let's > > say that a given live property definition does specify that its > > value must remain the same on different bindings to the same > > resource. In that case, the client can depend on them being > > the same and that simple little addition creates an unnecessary > > contradiction between what should have been orthogonal > > specifications. There is no reason for the binding specification > > to make blanket statements when there are no conditions that hold > > for all live properties -- that is why we have property definitions. > > > > Developers don't need any more guidance here. What they need are > > shorter specifications so that they don't have to waste their time > > digging through meaningless tripe just to understand the interface. > > > > ....Roy > > >=20 >=20 =09 ------_=_NextPart_001_01C5023A.9E7738EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
As an=20 implementor, I found 2518 to be an excellent specification. But = sometimes, even=20 though the authors knew what they meant, I didn't know what they meant. = Any time=20 the authors of a spec undergo any confusion or disagreement about the = meaning of=20 their spec, or discover such confusion among the readers of that spec, = they've=20 received a hint that the specification is not as clear as = they might have=20 thought, and therefore vulnerable to interoperability=20 problems.
 
It=20 seems to me that if the time and effort to clarify the meaning have been = spent,=20 it is an enourmous waste not to make that clarification available to = potential=20 implementors.
 
 =20 -- Roger
-----Original Message-----
From: = Geoffrey M Clemm=20 [mailto:geoffrey.clemm@us.ibm.com]
Sent: Monday, January = 24, 2005=20 9:00 AM
To: WebDAV WG
Subject: Re:=20 ETags?


I agree with Elias = and Julian=20 about the excellence of Roy's point,
and=20 would point out that in my opinion, it applies to most/all =
of the other requests for "guidance" in the = binding spec=20 for the
behavior of functionality = defined in=20 other specifications.

Cheers,=20
Geoff

Elias wrote on=20 01/22/2005 10:38:02 PM:

> Thanks Roy, that's an excellent = point that=20 I hadn't considered. For the
> record, I am no longer opposed = to the=20 spec remaining silent on the issue.
>=20 ________________________________
>
> Roy T. Fielding=20 wrote:
>
> >
> > On Jan 21, 2005, at 2:44 PM, = Elias=20 Sinderson wrote:
> >
> >>> [...] Including a = single=20 sentence which states that clients can't
> >>> = necessarily=20 depend on live properties being the same on different
> = >>>=20 bindings to a given resource.
> >>
> = >>
>=20 >> ... doesn't seem like an undue amount of verbiage in the=20 spec.
> >
> >
> > It does to me, and I = guess an=20 explanation is in order.  Let's
> > say that a given = live=20 property definition does specify that its
> > value must = remain the=20 same on different bindings to the same
> > resource.  In = that=20 case, the client can depend on them being
> > the same and = that=20 simple little addition creates an unnecessary
> > = contradiction=20 between what should have been orthogonal
> > specifications.=20  There is no reason for the binding specification
> > to = make=20 blanket statements when there are no conditions that hold
> > = for all=20 live properties -- that is why we have property definitions.
>=20 >
> > Developers don't need any more guidance here. =  What=20 they need are
> > shorter specifications so that they don't = have to=20 waste their time
> > digging through meaningless tripe just = to=20 understand the interface.
> >
> > ....Roy
>=20 >
>
>
------_=_NextPart_001_01C5023A.9E7738EF-- From w3c-dist-auth-request@w3.org Mon Jan 24 12:54:37 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06111 for ; Mon, 24 Jan 2005 12:54:37 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ct8PI-0000wc-Cr for w3c-dist-auth-dist@listhub.w3.org; Mon, 24 Jan 2005 17:53:44 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ct8PI-0000w8-4f for w3c-dist-auth@listhub.w3.org; Mon, 24 Jan 2005 17:53:44 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ct8P7-0006OT-Sd for w3c-dist-auth@w3.org; Mon, 24 Jan 2005 17:53:34 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0OHrCSK004702 for ; Mon, 24 Jan 2005 12:53:12 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0OHrC46031670 for ; Mon, 24 Jan 2005 12:53:12 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0OHr2aj025237 for ; Mon, 24 Jan 2005 12:53:02 -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 j0OHr1ww025030 for ; Mon, 24 Jan 2005 12:53:01 -0500 In-Reply-To: <482A3FA0050D21419C269D13989C611326C8ED@lavender-fe.eng.netapp.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 24 Jan 2005 12:53:04 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/24/2005 12:53:01, Serialize complete at 01/24/2005 12:53:01 Content-Type: multipart/alternative; boundary="=_alternative 00623D9D85256F93_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: RE: ETags? X-Archived-At: http://www.w3.org/mid/OFAA1290C6.BB1C687A-ON85256F93.0061B90F-85256F93.00623DAA@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9336 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Jan 2005 17:53:44 +0000 This is a multipart message in MIME format. --=_alternative 00623D9D85256F93_= Content-Type: text/plain; charset="US-ASCII" If we were discussing clarifications of what the BINDING spec is saying about features introduced by the BINDING specification, I would completely agree with you that those clarifications should be added to the BINDING specification. The question is whether the binding specification should clarify features defined in another specification (e.g., LOCK's, ACL's, live properties, etc.). In particular, if there are clarifications, should they be inserted into whatever specification is currently being published, or should they be placed on the clarification list for the "bis" version of the specification in which the feature being clarified is defined? Cheers, Geoff "Cox, Roger" wrote on 01/24/2005 12:32:03 PM: > As an implementor, I found 2518 to be an excellent specification. > But sometimes, even though the authors knew what they meant, I > didn't know what they meant. Any time the authors of a spec undergo > any confusion or disagreement about the meaning of their spec, or > discover such confusion among the readers of that spec, they've > received a hint that the specification is not as clear as they might > have thought, and therefore vulnerable to interoperability problems. > > It seems to me that if the time and effort to clarify the meaning > have been spent, it is an enourmous waste not to make that > clarification available to potential implementors. > > -- Roger > -----Original Message----- > From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] > Sent: Monday, January 24, 2005 9:00 AM > To: WebDAV WG > Subject: Re: ETags? > > I agree with Elias and Julian about the excellence of Roy's point, > and would point out that in my opinion, it applies to most/all > of the other requests for "guidance" in the binding spec for the > behavior of functionality defined in other specifications. > > Cheers, > Geoff > > Elias wrote on 01/22/2005 10:38:02 PM: > > > Thanks Roy, that's an excellent point that I hadn't considered. For the > > record, I am no longer opposed to the spec remaining silent on the issue. > > ________________________________ > > > > Roy T. Fielding wrote: > > > > > > > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote: > > > > > >>> [...] Including a single sentence which states that clients can't > > >>> necessarily depend on live properties being the same on different > > >>> bindings to a given resource. > > >> > > >> > > >> ... doesn't seem like an undue amount of verbiage in the spec. > > > > > > > > > It does to me, and I guess an explanation is in order. Let's > > > say that a given live property definition does specify that its > > > value must remain the same on different bindings to the same > > > resource. In that case, the client can depend on them being > > > the same and that simple little addition creates an unnecessary > > > contradiction between what should have been orthogonal > > > specifications. There is no reason for the binding specification > > > to make blanket statements when there are no conditions that hold > > > for all live properties -- that is why we have property definitions. > > > > > > Developers don't need any more guidance here. What they need are > > > shorter specifications so that they don't have to waste their time > > > digging through meaningless tripe just to understand the interface. > > > > > > ....Roy > > > > > > > --=_alternative 00623D9D85256F93_= Content-Type: text/html; charset="US-ASCII"
If we were discussing clarifications of what the BINDING spec is
saying about features introduced by the BINDING specification,
I would completely agree with you that those clarifications should
be added to the BINDING specification.

The question is whether the binding specification should clarify
features defined in another specification (e.g., LOCK's, ACL's,
live properties, etc.).  In particular, if there are clarifications,
should they be inserted into whatever specification is currently
being published, or should they be placed on the clarification list
for the "bis" version of the specification in which the feature
being clarified is defined?

Cheers,
Geoff

"Cox, Roger" <Roger.Cox@netapp.com> wrote on 01/24/2005 12:32:03 PM:

> As an implementor, I found 2518 to be an excellent specification.
> But sometimes, even though the authors knew what they meant, I
> didn't know what they meant. Any time the authors of a spec undergo
> any confusion or disagreement about the meaning of their spec, or
> discover such confusion among the readers of that spec, they've
> received a hint that the specification is not as clear as they might
> have thought, and therefore vulnerable to interoperability problems.
>  
> It seems to me that if the time and effort to clarify the meaning
> have been spent, it is an enourmous waste not to make that
> clarification available to potential implementors.
>  
>   -- Roger
> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]
> Sent: Monday, January 24, 2005 9:00 AM
> To: WebDAV WG
> Subject: Re: ETags?
>
> I agree with Elias and Julian about the excellence of Roy's point,
> and would point out that in my opinion, it applies to most/all
> of the other requests for "guidance" in the binding spec for the
> behavior of functionality defined in other specifications.
>
> Cheers,
> Geoff
>
> Elias wrote on 01/22/2005 10:38:02 PM:
>
> > Thanks Roy, that's an excellent point that I hadn't considered. For the
> > record, I am no longer opposed to the spec remaining silent on the issue.
> > ________________________________
> >
> > Roy T. Fielding wrote:
> >
> > >
> > > On Jan 21, 2005, at 2:44 PM, Elias Sinderson wrote:
> > >
> > >>> [...] Including a single sentence which states that clients can't
> > >>> necessarily depend on live properties being the same on different
> > >>> bindings to a given resource.
> > >>
> > >>
> > >> ... doesn't seem like an undue amount of verbiage in the spec.
> > >
> > >
> > > It does to me, and I guess an explanation is in order.  Let's
> > > say that a given live property definition does specify that its
> > > value must remain the same on different bindings to the same
> > > resource.  In that case, the client can depend on them being
> > > the same and that simple little addition creates an unnecessary
> > > contradiction between what should have been orthogonal
> > > specifications.  There is no reason for the binding specification
> > > to make blanket statements when there are no conditions that hold
> > > for all live properties -- that is why we have property definitions.
> > >
> > > Developers don't need any more guidance here.  What they need are
> > > shorter specifications so that they don't have to waste their time
> > > digging through meaningless tripe just to understand the interface.
> > >
> > > ....Roy
> > >
> >
> > --=_alternative 00623D9D85256F93_=-- From w3c-dist-auth-request@w3.org Tue Jan 25 04:16:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12630 for ; Tue, 25 Jan 2005 04:16:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CtMkz-000803-Pp for w3c-dist-auth-dist@listhub.w3.org; Tue, 25 Jan 2005 09:13:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CtMky-0007zP-WA for w3c-dist-auth@listhub.w3.org; Tue, 25 Jan 2005 09:13:05 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CtMky-0003aX-L5 for w3c-dist-auth@w3.org; Tue, 25 Jan 2005 09:13:04 +0000 Received: (qmail invoked by alias); 25 Jan 2005 09:12:32 -0000 Received: from p54856E36.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.110.54) by mail.gmx.net (mp020) with SMTP; 25 Jan 2005 10:12:32 +0100 X-Authenticated: #1915285 Message-ID: <41F60D7B.6060705@gmx.de> Date: Tue, 25 Jan 2005 10:12:27 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> In-Reply-To: <41F31C1A.3080508@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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F60D7B.6060705@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9337 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 25 Jan 2005 09:13:05 +0000 Content-Transfer-Encoding: 7bit Elias Sinderson wrote: > > Thanks Roy, that's an excellent point that I hadn't considered. For the > record, I am no longer opposed to the spec remaining silent on the issue. Ok, for the record: as Roy has explained to us, the current language is actively incorrect and harmful, so the first step is to remove it. I'm open to suggestions about anything else we can do. Note that these suggestions should be made in the form of actual specification text. If we can get a consensus about one proposal, I'll be happy to make that change. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Jan 26 16:56:38 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24751 for ; Wed, 26 Jan 2005 16:56:38 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ctv7i-0007aV-Pn for w3c-dist-auth-dist@listhub.w3.org; Wed, 26 Jan 2005 21:54:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Ctv7c-0007Yr-AN for w3c-dist-auth@listhub.w3.org; Wed, 26 Jan 2005 21:54:44 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.34) id 1Ctv7R-00067S-Tn for w3c-dist-auth@w3.org; Wed, 26 Jan 2005 21:54:34 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j0QLsCAE011172 for ; Wed, 26 Jan 2005 13:54:13 -0800 (PST) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 26 Jan 2005 13:54:12 -0800 Received: from [17.207.15.105] (baumjo.apple.com [17.207.15.105]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id j0QLsA9J006524 for ; Wed, 26 Jan 2005 13:54:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: w3c-dist-auth@w3.org From: John Baumgarten Date: Wed, 26 Jan 2005 13:54:10 -0800 X-Mailer: Apple Mail (2.619) Received-SPF: pass (lisa.w3.org: domain of jbaumgarten@apple.com designates 17.254.13.23 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/CF2C4910-6FE4-11D9-B18A-000A95A69B20@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9338 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 Jan 2005 21:54:50 +0000 Content-Transfer-Encoding: 7bit All- I've searched through the mail archives and 2518 and 2518bis-06, so forgive me if this is a well-known issue. After a lock-null has been converted to a either a collection or "regular" resource via a MKCOL or PUT, respectively, should the resulting resource still be locked? -Jake John S "Jake" Baumgarten Apple .Mac Backend Server Engineering jbaumgarten@apple.com Cupertino CA 95014 USA www.apple.com From w3c-dist-auth-request@w3.org Wed Jan 26 17:39:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29171 for ; Wed, 26 Jan 2005 17:39:18 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Ctvnx-0005G7-UL for w3c-dist-auth-dist@listhub.w3.org; Wed, 26 Jan 2005 22:38:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Ctvnx-0005FS-50 for w3c-dist-auth@listhub.w3.org; Wed, 26 Jan 2005 22:38:29 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Ctvnw-0005mh-Q8 for w3c-dist-auth@w3.org; Wed, 26 Jan 2005 22:38:29 +0000 Received: (qmail invoked by alias); 26 Jan 2005 22:37:55 -0000 Received: from p54856FAD.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.111.173) by mail.gmx.net (mp003) with SMTP; 26 Jan 2005 23:37:55 +0100 X-Authenticated: #1915285 Message-ID: <41F81BBF.7030104@gmx.de> Date: Wed, 26 Jan 2005 23:37:51 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baumgarten 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 (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/41F81BBF.7030104@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9339 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 26 Jan 2005 22:38:29 +0000 Content-Transfer-Encoding: 7bit John Baumgarten wrote: > > All- > > I've searched through the mail archives and 2518 and 2518bis-06, so > forgive me if this is a well-known issue. > > After a lock-null has been converted to a either a collection or > "regular" resource via a MKCOL or PUT, respectively, should the > resulting resource still be locked? In RFC2518: yes. That's the whole point. In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped URL creates an empty and locked (non-collection) resource. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jan 27 16:58:18 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04203 for ; Thu, 27 Jan 2005 16:58:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuHc8-0002Uq-Up for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Jan 2005 21:55:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuHc4-0002Ta-AC for w3c-dist-auth@listhub.w3.org; Thu, 27 Jan 2005 21:55:40 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CuHc3-0003Jm-VM for w3c-dist-auth@w3.org; Thu, 27 Jan 2005 21:55:40 +0000 Received: (qmail invoked by alias); 27 Jan 2005 21:55:06 -0000 Received: from pD9E510B9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.185) by mail.gmx.net (mp003) with SMTP; 27 Jan 2005 22:55:06 +0100 X-Authenticated: #1915285 Message-ID: <41F96330.1070002@gmx.de> Date: Thu, 27 Jan 2005 22:54:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: WebDAV WG References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> In-Reply-To: <41F60D7B.6060705@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/41F96330.1070002@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9340 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Jan 2005 21:55:44 +0000 Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Elias Sinderson wrote: > >> >> Thanks Roy, that's an excellent point that I hadn't considered. For >> the record, I am no longer opposed to the spec remaining silent on the >> issue. > > > Ok, for the record: as Roy has explained to us, the current language is > actively incorrect and harmful, so the first step is to remove it. > > I'm open to suggestions about anything else we can do. Note that these > suggestions should be made in the form of actual specification text. If > we can get a consensus about one proposal, I'll be happy to make that > change. OK, as I haven't heard anything new (in particular no concrete proposal for specification text) I'm closing the issue for now (see ). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Jan 27 19:00:27 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13064 for ; Thu, 27 Jan 2005 19:00:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuJXC-0000ci-M3 for w3c-dist-auth-dist@listhub.w3.org; Thu, 27 Jan 2005 23:58:46 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuJXB-0000at-NU for w3c-dist-auth@listhub.w3.org; Thu, 27 Jan 2005 23:58:45 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuJX1-0008Lj-9g for w3c-dist-auth@w3.org; Thu, 27 Jan 2005 23:58:35 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0RNwdaa001860 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jan 2005 15:58:40 -0800 In-Reply-To: <41F96330.1070002@gmx.de> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> <41F96330.1070002@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Lisa Dusseault Date: Thu, 27 Jan 2005 15:58:32 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9341 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Jan 2005 23:58:46 +0000 Content-Transfer-Encoding: 7bit I am still in favour of the language that was there: > Consistent with [RFC2518] the value of a dead property MUST be, and > the value of a live property SHOULD be, independent of the number of > bindings to its host resource or of the path submitted to PROPFIND. Also, I propose additional language for ETags: "The value of the 'getetag' property (and thus the value of the ETag for a resource at that point in time) MAY change when a new binding is added to a resource. However, the value MUST be the same for that resource independent of the path submitted to PROPFIND." Lisa On Jan 27, 2005, at 1:54 PM, Julian Reschke wrote: > > Julian Reschke wrote: >> Elias Sinderson wrote: >>> >>> Thanks Roy, that's an excellent point that I hadn't considered. For >>> the record, I am no longer opposed to the spec remaining silent on >>> the issue. >> Ok, for the record: as Roy has explained to us, the current language >> is actively incorrect and harmful, so the first step is to remove it. >> I'm open to suggestions about anything else we can do. Note that >> these suggestions should be made in the form of actual specification >> text. If we can get a consensus about one proposal, I'll be happy to >> make that change. > > OK, as I haven't heard anything new (in particular no concrete > proposal for specification text) I'm closing the issue for now (see > latest.html#rfc.issue.2.6_bindings_vs_properties>). > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Jan 27 19:07:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13434 for ; Thu, 27 Jan 2005 19:07:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuJea-0004dw-F2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 00:06:24 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuJea-0004dM-5f for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 00:06:24 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuJeZ-0007MU-UJ for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 00:06:24 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S06Laa002392 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 27 Jan 2005 16:06:21 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <6c51b5d867a56b424ab742a28d6abec2@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: WebDAV WG From: Lisa Dusseault Date: Thu, 27 Jan 2005 16:06:14 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Meeting in Minneapolis X-Archived-At: http://www.w3.org/mid/6c51b5d867a56b424ab742a28d6abec2@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9342 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 00:06:24 +0000 Content-Transfer-Encoding: 7bit We've requested a meeting slot in Minneapolis. We're really hoping to make this meeting valuable to finish off the bindings issues and unblock/resume/relaunch the work on RFC2518bis. The schedule for the Minneapolis meeting is going to be finalized earlier than usual this year, to make it easier for people to plan to attend. General meeting info: http://www.ietf.org/meetings/IETF-62.html Lisa From w3c-dist-auth-request@w3.org Thu Jan 27 19:07:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13534 for ; Thu, 27 Jan 2005 19:07:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuJfC-0004rd-PH for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 00:07:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuJfC-0004r9-H9 for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 00:07:02 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuJfC-0007SL-9C for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 00:07:02 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S06Lab002392 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 27 Jan 2005 16:07:00 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) To: WebDAV WG Message-Id: <262d3bd914fb960eafd37604c5381510@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-16--285400171 From: Lisa Dusseault Date: Thu, 27 Jan 2005 16:06:58 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Fwd: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/262d3bd914fb960eafd37604c5381510@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9343 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 00:07:02 +0000 --Apple-Mail-16--285400171 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit By the way, I agree with this wording. I would be even happier if it also required the server to allow LOCK on any binding to refresh the lock already existing. Can we add that? The title of the bug is general ("Bindings needs to completely describe how bindings interact with locks.") because when I entered it, I could see some undefined interactions and suspected there might be more. At this point, I am not aware of any more undefined interactions, so if we satisfy the interaction between LOCK/UNLOCK and multiple bindings, I suggest we close the bug. We can also make the bug title more specific so that if somebody comes up with a new undefined interaction between locking and bindings we'd encourage them to open a new bug. Lisa Begin forwarded message: > From: bugzilla@soe.ucsc.edu > Date: January 18, 2005 11:35:08 PM PST > To: lisa@osafoundation.org > Subject: [Bug 2] Bindings needs to completely describe how bindings > interact with locks. > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 > > > > > > ------- Additional Comments From julian.reschke@greenbytes.de > 2005-01-18 23:35 ------- > Suggested additional text bei Joe Hildebrand, Chuck Fay and Julian > Reschke: > > 2.x UNLOCK and Bindings > > Due to the specific language used in section 8.11 of [RFC2518], it > might > be thought that an UNLOCK request to a locked resource would unlock > just > the particular binding expressed by the Request-URI, rather than the > resource identified by that URI. This is not the case, however. > Section 6 of [RFC2518] clearly states that locks are on resources, not > URIs, so the server MUST allow UNLOCK to be used to unlock a locked > resource through any binding to that resource. The authors of this > specification anticipate and recommend that future revisions of > [RFC2518] maintain this behavior. > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. --Apple-Mail-16--285400171 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit By the way, I agree with this wording. I would be even happier if it also required the server to allow LOCK on any binding to refresh the lock already existing. Can we add that? The title of the bug is general ("Bindings needs to completely describe how bindings interact with locks.") because when I entered it, I could see some undefined interactions and suspected there might be more. At this point, I am not aware of any more undefined interactions, so if we satisfy the interaction between LOCK/UNLOCK and multiple bindings, I suggest we close the bug. We can also make the bug title more specific so that if somebody comes up with a new undefined interaction between locking and bindings we'd encourage them to open a new bug. Lisa Begin forwarded message: 0000,0000,0000From: bugzilla@soe.ucsc.edu 0000,0000,0000Date: January 18, 2005 11:35:08 PM PST 0000,0000,0000To: lisa@osafoundation.org 0000,0000,0000Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks. http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-18 23:35 ------- Suggested additional text bei Joe Hildebrand, Chuck Fay and Julian Reschke: 2.x UNLOCK and Bindings Due to the specific language used in section 8.11 of [RFC2518], it might be thought that an UNLOCK request to a locked resource would unlock just the particular binding expressed by the Request-URI, rather than the resource identified by that URI. This is not the case, however. Section 6 of [RFC2518] clearly states that locks are on resources, not URIs, so the server MUST allow UNLOCK to be used to unlock a locked resource through any binding to that resource. The authors of this specification anticipate and recommend that future revisions of [RFC2518] maintain this behavior. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. --Apple-Mail-16--285400171-- From w3c-dist-auth-request@w3.org Thu Jan 27 20:16:17 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19432 for ; Thu, 27 Jan 2005 20:16:17 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuKis-0008AM-UQ for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 01:14:54 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuKir-00087u-FU for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 01:14:53 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1CuKir-0003iz-1l for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 01:14:53 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CuKio-0001uO-2x; Thu, 27 Jan 2005 17:14:50 -0800 In-Reply-To: <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> <41F96330.1070002@gmx.de> <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDAV WG From: "Roy T. Fielding" Date: Thu, 27 Jan 2005 17:14:52 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9344 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 01:14:54 +0000 Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 3:58 PM, Lisa Dusseault wrote: > Also, I propose additional language for ETags: > > "The value of the 'getetag' property (and thus the value of the ETag > for a resource at that point in time) MAY change when a new binding is > added to a resource. However, the value MUST be the same for that > resource independent of the path submitted to PROPFIND." Absolutely not. It effectively forbids the use of etags that contain such info as the URI used to access the entity. ETags are specific to representations, not an identifier for resources. ....Roy From w3c-dist-auth-request@w3.org Thu Jan 27 20:27:40 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20339 for ; Thu, 27 Jan 2005 20:27:40 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuKuY-0003Rx-Hk for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 01:26:58 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuKuY-0003RT-8V for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 01:26:58 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuKuY-00062C-1B for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 01:26:58 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S1Qraa009420 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jan 2005 17:26:54 -0800 In-Reply-To: <03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> <41F96330.1070002@gmx.de> <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> <03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3a02e4f1ba9747c679c2a579f4a55d10@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDAV WG From: Lisa Dusseault Date: Thu, 27 Jan 2005 17:26:46 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/3a02e4f1ba9747c679c2a579f4a55d10@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9345 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 01:26:58 +0000 Content-Transfer-Encoding: 7bit Ok, then "The value of the 'getetag' property (and thus the value of the ETag for a resource at that point in time) MAY change when a new binding is added to a resource. Also, the value of the 'getetag' property MAY be different for a single resource depending on which binding path is submitted to the PROPFIND request. Lisa On Jan 27, 2005, at 5:14 PM, Roy T. Fielding wrote: > On Jan 27, 2005, at 3:58 PM, Lisa Dusseault wrote: >> Also, I propose additional language for ETags: >> >> "The value of the 'getetag' property (and thus the value of the ETag >> for a resource at that point in time) MAY change when a new binding >> is added to a resource. However, the value MUST be the same for that >> resource independent of the path submitted to PROPFIND." > > Absolutely not. It effectively forbids the use of etags that > contain such info as the URI used to access the entity. ETags > are specific to representations, not an identifier for resources. > > ....Roy > From w3c-dist-auth-request@w3.org Thu Jan 27 20:30:24 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20573 for ; Thu, 27 Jan 2005 20:30:24 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuKxM-0004Tc-0o for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 01:29:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuKxL-0004T8-Nn for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 01:29:51 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuKxB-0004Re-BB for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 01:29:41 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CuKxJ-00008U-DJ; Thu, 27 Jan 2005 17:29:49 -0800 In-Reply-To: <3a02e4f1ba9747c679c2a579f4a55d10@osafoundation.org> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> <41F96330.1070002@gmx.de> <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> <03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com> <3a02e4f1ba9747c679c2a579f4a55d10@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B6A1EC2-70CC-11D9-AD7B-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDAV WG From: "Roy T. Fielding" Date: Thu, 27 Jan 2005 17:29:51 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (lisa.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/1B6A1EC2-70CC-11D9-AD7B-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9346 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 01:29:52 +0000 Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: > Ok, then > > "The value of the 'getetag' property (and thus the value of the ETag > for a resource at that point in time) MAY change when a new binding is > added to a resource. Also, the value of the 'getetag' property MAY be > different for a single resource depending on which binding path is > submitted to the PROPFIND request. No, the getetag property and the ETag value have no relation whatsoever with the bindings specification or its methods, and there is no reason whatsoever to add meaningless statements to reiterate that fact. ....Roy From w3c-dist-auth-request@w3.org Thu Jan 27 20:36:07 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20935 for ; Thu, 27 Jan 2005 20:36:06 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuL2n-0006Xk-Gg for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 01:35:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuL2n-0006X3-6K for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 01:35:29 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuL2c-0004wy-OF for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 01:35:18 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S1ZOaa010048 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jan 2005 17:35:25 -0800 In-Reply-To: <1B6A1EC2-70CC-11D9-AD7B-000D93324AD6@gbiv.com> References: <41EF1D37.4030200@cse.ucsc.edu> <41F17A4C.40904@gmx.de> <41F183F6.3000904@cse.ucsc.edu> <41F185C5.8090805@cse.ucsc.edu> <41F31C1A.3080508@cse.ucsc.edu> <41F60D7B.6060705@gmx.de> <41F96330.1070002@gmx.de> <783b70313b776b35c27aeeb2dcc3fbab@osafoundation.org> <03417DD6-70CA-11D9-AD7B-000D93324AD6@gbiv.com> <3a02e4f1ba9747c679c2a579f4a55d10@osafoundation.org> <1B6A1EC2-70CC-11D9-AD7B-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <427cba2a9371176bd089bc397d420a73@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , WebDAV WG From: Lisa Dusseault Date: Thu, 27 Jan 2005 17:35:04 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/427cba2a9371176bd089bc397d420a73@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9347 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 01:35:29 +0000 Content-Transfer-Encoding: 7bit Well as you can see Roy, we disagree. I would have been fairly likely to implement a client that assumed that the ETag would be the same for all bindings to a resource, because the servers I've worked on and worked with happened to work that way. Sometimes what an implementer knows can blind them to what could be. Lisa On Jan 27, 2005, at 5:29 PM, Roy T. Fielding wrote: > On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: > >> Ok, then >> >> "The value of the 'getetag' property (and thus the value of the ETag >> for a resource at that point in time) MAY change when a new binding >> is added to a resource. Also, the value of the 'getetag' property MAY >> be different for a single resource depending on which binding path is >> submitted to the PROPFIND request. > > No, the getetag property and the ETag value have no relation > whatsoever with the bindings specification or its methods, > and there is no reason whatsoever to add meaningless statements > to reiterate that fact. > > ....Roy > From w3c-dist-auth-request@w3.org Thu Jan 27 21:18:08 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24316 for ; Thu, 27 Jan 2005 21:18:08 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuLgl-0003tP-Qd for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 02:16:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuLgl-0003sq-6f for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 02:16:47 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuLga-00022I-Rt for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 02:16:36 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0S2GG7F014770 for ; Thu, 27 Jan 2005 21:16:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0S2GF1P225060 for ; Thu, 27 Jan 2005 21:16:15 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0S2GFod019388 for ; Thu, 27 Jan 2005 21:16:15 -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 j0S2GFbx019384 for ; Thu, 27 Jan 2005 21:16:15 -0500 In-Reply-To: <1B6A1EC2-70CC-11D9-AD7B-000D93324AD6@gbiv.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 27 Jan 2005 21:16:17 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/27/2005 21:16:15, Serialize complete at 01/27/2005 21:16:15 Content-Type: multipart/alternative; boundary="=_alternative 000C7ACC85256F97_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.142 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF7EE39668.7EED0CD1-ON85256F97.000C3E97-85256F97.000C7ACD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9348 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 02:16:47 +0000 This is a multipart message in MIME format. --=_alternative 000C7ACC85256F97_= Content-Type: text/plain; charset="US-ASCII" I completely agree with Roy. If something needs to be clarified about the behavior of etags, post a bug against the spec which defines the behavior of etags (which is not the binding specification). Cheers, Geoff Roy wrote on 01/27/2005 08:29:51 PM: > > On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: > > > Ok, then > > > > "The value of the 'getetag' property (and thus the value of the ETag > > for a resource at that point in time) MAY change when a new binding is > > added to a resource. Also, the value of the 'getetag' property MAY be > > different for a single resource depending on which binding path is > > submitted to the PROPFIND request. > > No, the getetag property and the ETag value have no relation > whatsoever with the bindings specification or its methods, > and there is no reason whatsoever to add meaningless statements > to reiterate that fact. > > ....Roy > > --=_alternative 000C7ACC85256F97_= Content-Type: text/html; charset="US-ASCII"
I completely agree with Roy.  

If something needs to be clarified about the behavior of etags,
post a bug against the spec which defines the behavior of etags
(which is not the binding specification).

Cheers,
Geoff

Roy wrote on 01/27/2005 08:29:51 PM:

>
> On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote:
>
> > Ok, then
> >
> > "The value of the 'getetag' property (and thus the value of the ETag
> > for a resource at that point in time) MAY change when a new binding is
> > added to a resource. Also, the value of the 'getetag' property MAY be
> > different for a single resource depending on which binding path is
> > submitted to the PROPFIND request.
>
> No, the getetag property and the ETag value have no relation
> whatsoever with the bindings specification or its methods,
> and there is no reason whatsoever to add meaningless statements
> to reiterate that fact.
>
> ....Roy
>
>
--=_alternative 000C7ACC85256F97_=-- From w3c-dist-auth-request@w3.org Thu Jan 27 21:32:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25382 for ; Thu, 27 Jan 2005 21:32:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuLus-0000Qu-CY for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 02:31:22 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuLus-0000QQ-5T for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 02:31:22 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuLur-0001VY-UN for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 02:31:22 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0S2VFaa014650 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Jan 2005 18:31:16 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: " webdav" From: Lisa Dusseault Date: Thu, 27 Jan 2005 18:31:00 -0800 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/d8d16842d7e13f22802cf737a0a989bd@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9349 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 02:31:22 +0000 Content-Transfer-Encoding: 7bit Yes, but as I explained in this email -- http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html -- the bindings draft introduces the possibility for client behavior which could be harmful to interoperability unless the way that ETags interact with bindings is defined. Since bindings first introduces this possibility, that's our best choice for a document in which to resolve that potential interoperability problem. Lisa On Jan 27, 2005, at 6:16 PM, Geoffrey M Clemm wrote: > I completely agree with Roy. > > If something needs to be clarified about the behavior of etags, > post a bug against the spec which defines the behavior of etags > (which is not the binding specification). > > Cheers, > Geoff > > Roy wrote on 01/27/2005 08:29:51 PM: > >> >> On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: >> >>> Ok, then >>> >>> "The value of the 'getetag' property (and thus the value of the ETag >>> for a resource at that point in time) MAY change when a new binding >>> is > >>> added to a resource. Also, the value of the 'getetag' property MAY be >>> different for a single resource depending on which binding path is >>> submitted to the PROPFIND request. >> >> No, the getetag property and the ETag value have no relation >> whatsoever with the bindings specification or its methods, >> and there is no reason whatsoever to add meaningless statements >> to reiterate that fact. >> >> ....Roy >> >> From w3c-dist-auth-request@w3.org Thu Jan 27 21:34:29 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25709 for ; Thu, 27 Jan 2005 21:34:29 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuLxM-00019C-AH for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 02:33:56 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuLxM-00018i-3J for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 02:33:56 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by bart.w3.org with esmtp (Exim 4.34) id 1CuLxL-0001s9-V0 for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 02:33:56 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0S2XPFM017167 for ; Thu, 27 Jan 2005 21:33:25 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0S2XP1P264430 for ; Thu, 27 Jan 2005 21:33:25 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0S2XPRq004578 for ; Thu, 27 Jan 2005 21:33: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 j0S2XOlf004575 for ; Thu, 27 Jan 2005 21:33:24 -0500 In-Reply-To: <427cba2a9371176bd089bc397d420a73@osafoundation.org> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 27 Jan 2005 21:33:25 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/27/2005 21:33:24, Serialize complete at 01/27/2005 21:33:24 Content-Type: multipart/alternative; boundary="=_alternative 000E0C6D85256F97_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF9CC6D676.FAF5114F-ON85256F97.000D2119-85256F97.000E0C8E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9350 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 02:33:56 +0000 This is a multipart message in MIME format. --=_alternative 000E0C6D85256F97_= Content-Type: text/plain; charset="US-ASCII" I do not believe that any amount of guidance in the specification will solve the problem of an implementor that assumes that implementations they are familiar with define the interoperable semantics of a feature, rather than looking to see what the appropriate RFC says. The only effective solution for this problem is to teach those implementors to actually base their implementation on the specification. Since this means they actually will have to read the specification, the best way for us to support that solution is to keep the specification clear and avoid any bloat resulting from extraneous text. In fact, sprinkling "guidance" through a variety of specifications just encourages such implementors to not go to the defining specification, but rather to just assume that they "got it" from the partial information provided by some guidance they happened to run across. Cheers, Geoff Lisa wrote on 01/27/2005 08:35:04 PM: > > Well as you can see Roy, we disagree. I would have been fairly likely > to implement a client that assumed that the ETag would be the same for > all bindings to a resource, because the servers I've worked on and > worked with happened to work that way. > > Sometimes what an implementer knows can blind them to what could be. > > Lisa > > On Jan 27, 2005, at 5:29 PM, Roy T. Fielding wrote: > > > On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: > > > >> Ok, then > >> > >> "The value of the 'getetag' property (and thus the value of the ETag > >> for a resource at that point in time) MAY change when a new binding > >> is added to a resource. Also, the value of the 'getetag' property MAY > >> be different for a single resource depending on which binding path is > >> submitted to the PROPFIND request. > > > > No, the getetag property and the ETag value have no relation > > whatsoever with the bindings specification or its methods, > > and there is no reason whatsoever to add meaningless statements > > to reiterate that fact. > > > > ....Roy > > > > --=_alternative 000E0C6D85256F97_= Content-Type: text/html; charset="US-ASCII"
I do not believe that any amount of guidance in the specification
will solve the problem of an implementor that assumes that
implementations they are familiar with define the interoperable
semantics of a feature, rather than looking to see what the
appropriate RFC says.

The only effective solution for this problem is to teach those implementors
to actually base their implementation on the specification.  Since this
means they actually will have to read the specification, the best way for us to
support that solution is to keep the specification clear and avoid
any bloat resulting from extraneous text.  In fact, sprinkling
"guidance" through a variety of specifications just encourages such
implementors to not go to the defining specification, but rather to
just assume that they "got it" from the partial information provided
by some guidance they happened to run across.

Cheers,
Geoff


Lisa wrote on 01/27/2005 08:35:04 PM:
>
> Well as you can see Roy, we disagree.  I would have been fairly likely
> to implement a client that assumed that the ETag would be the same for
> all bindings to a resource, because the servers I've worked on and
> worked with happened to work that way.
>
> Sometimes what an implementer knows can blind them to what could be.
>
> Lisa
>
> On Jan 27, 2005, at 5:29 PM, Roy T. Fielding wrote:
>
> > On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote:
> >
> >> Ok, then
> >>
> >> "The value of the 'getetag' property (and thus the value of the ETag
> >> for a resource at that point in time) MAY change when a new binding
> >> is added to a resource. Also, the value of the 'getetag' property MAY
> >> be different for a single resource depending on which binding path is
> >> submitted to the PROPFIND request.
> >
> > No, the getetag property and the ETag value have no relation
> > whatsoever with the bindings specification or its methods,
> > and there is no reason whatsoever to add meaningless statements
> > to reiterate that fact.
> >
> > ....Roy
> >
>
>
--=_alternative 000E0C6D85256F97_=-- From w3c-dist-auth-request@w3.org Thu Jan 27 22:28:28 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29071 for ; Thu, 27 Jan 2005 22:28:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuMn1-00049T-Pz for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 03:27:19 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuMn0-00048z-NN for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 03:27:18 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1CuMn0-0003v8-Hz for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 03:27:18 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CuMmy-0008J4-Gd; Thu, 27 Jan 2005 19:27:16 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83D8695D-70DC-11D9-AD7B-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , " webdav" From: "Roy T. Fielding" Date: Thu, 27 Jan 2005 19:27:19 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/83D8695D-70DC-11D9-AD7B-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9351 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 03:27:19 +0000 Content-Transfer-Encoding: 7bit On Jan 27, 2005, at 6:31 PM, Lisa Dusseault wrote: > Yes, but as I explained in this email -- > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html > > -- the bindings draft introduces the possibility for client behavior > which could be harmful to interoperability unless the way that ETags > interact with bindings is defined. And has been explained in multiple responses, bindings does not introduce such behavior -- it is present in any implementation that allows such things as Alias configurations -- and there is absolutely nothing that bindings can say about it that isn't already in the definition of etag in RFC 2616. > Since bindings first introduces this possibility, that's our best > choice for a document in which to resolve that potential > interoperability problem. There is no interoperability problem. You are imagining that there might be an interoperability problem if the client developer makes an egregious mistake in assuming the implementation behind the interface defined by HTTP. Quite frankly, that is not our problem. ....Roy From w3c-dist-auth-request@w3.org Thu Jan 27 22:29:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29175 for ; Thu, 27 Jan 2005 22:29:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuMo9-0004Tl-K2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 03:28:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuMo9-0004TC-6P for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 03:28:29 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by bart.w3.org with esmtp (Exim 4.34) id 1CuMo9-00043g-0a for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 03:28:29 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0S3RwFM015165 for ; Thu, 27 Jan 2005 22:27:58 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0S3Rw1P279648 for ; Thu, 27 Jan 2005 22:27:58 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0S3RwiM012486 for ; Thu, 27 Jan 2005 22:27:58 -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 j0S3Rwa6012480 for ; Thu, 27 Jan 2005 22:27:58 -0500 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Thu, 27 Jan 2005 22:27:54 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/27/2005 22:27:57, Serialize complete at 01/27/2005 22:27:57 Content-Type: multipart/alternative; boundary="=_alternative 0013095785256F97_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.144 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/OF64167FA6.718A3AEC-ON85256F97.0012E44C-85256F97.00130959@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9352 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 03:28:29 +0000 This is a multipart message in MIME format. --=_alternative 0013095785256F97_= Content-Type: text/plain; charset="US-ASCII" I understand your position. I just disagree with it, for the reasons that I (and Roy and Julian) have explained in our email. Cheers, Geoff Lisa wrote on 01/27/2005 09:31:00 PM: > > Yes, but as I explained in this email -- > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html > > -- the bindings draft introduces the possibility for client behavior > which could be harmful to interoperability unless the way that ETags > interact with bindings is defined. > > Since bindings first introduces this possibility, that's our best > choice for a document in which to resolve that potential > interoperability problem. > > Lisa > > On Jan 27, 2005, at 6:16 PM, Geoffrey M Clemm wrote: > > > I completely agree with Roy. > > > > If something needs to be clarified about the behavior of etags, > > post a bug against the spec which defines the behavior of etags > > (which is not the binding specification). > > > > Cheers, > > Geoff > > > > Roy wrote on 01/27/2005 08:29:51 PM: > > > >> > >> On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote: > >> > >>> Ok, then > >>> > >>> "The value of the 'getetag' property (and thus the value of the ETag > >>> for a resource at that point in time) MAY change when a new binding > >>> is > > > >>> added to a resource. Also, the value of the 'getetag' property MAY be > >>> different for a single resource depending on which binding path is > >>> submitted to the PROPFIND request. > >> > >> No, the getetag property and the ETag value have no relation > >> whatsoever with the bindings specification or its methods, > >> and there is no reason whatsoever to add meaningless statements > >> to reiterate that fact. > >> > >> ....Roy > >> > >> > > --=_alternative 0013095785256F97_= Content-Type: text/html; charset="US-ASCII"
I understand your position.  I just disagree with it, for the
reasons that I (and Roy and Julian) have explained in our email.

Cheers,
Geoff

Lisa wrote on 01/27/2005 09:31:00 PM:

>
> Yes, but as I explained in this email --
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html
>
> -- the bindings draft introduces the possibility for client behavior
> which could be harmful to interoperability unless the way that ETags
> interact with bindings is defined.
>
> Since bindings first introduces this possibility, that's our best
> choice for a document in which to resolve that potential
> interoperability problem.
>
> Lisa
>
> On Jan 27, 2005, at 6:16 PM, Geoffrey M Clemm wrote:
>
> > I completely agree with Roy.
> >
> > If something needs to be clarified about the behavior of etags,
> > post a bug against the spec which defines the behavior of etags
> > (which is not the binding specification).
> >
> > Cheers,
> > Geoff
> >
> > Roy wrote on 01/27/2005 08:29:51 PM:
> >
> >>
> >> On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote:
> >>
> >>> Ok, then
> >>>
> >>> "The value of the 'getetag' property (and thus the value of the ETag
> >>> for a resource at that point in time) MAY change when a new binding
> >>> is
> >
> >>> added to a resource. Also, the value of the 'getetag' property MAY be
> >>> different for a single resource depending on which binding path is
> >>> submitted to the PROPFIND request.
> >>
> >> No, the getetag property and the ETag value have no relation
> >> whatsoever with the bindings specification or its methods,
> >> and there is no reason whatsoever to add meaningless statements
> >> to reiterate that fact.
> >>
> >> ....Roy
> >>
> >>
>
>
--=_alternative 0013095785256F97_=-- From w3c-dist-auth-request@w3.org Fri Jan 28 04:01:01 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09070 for ; Fri, 28 Jan 2005 04:01:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuRyA-0004Nq-3k for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 08:59:10 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuRy9-0004NJ-AN for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 08:59:09 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CuRxy-0005ro-Ot for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 08:58:59 +0000 Received: (qmail invoked by alias); 28 Jan 2005 08:58:36 -0000 Received: from pD9E510B9.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.16.185) by mail.gmx.net (mp029) with SMTP; 28 Jan 2005 09:58:36 +0100 X-Authenticated: #1915285 Message-ID: <41F9FEB8.9070507@gmx.de> Date: Fri, 28 Jan 2005 09:58:32 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> In-Reply-To: <262d3bd914fb960eafd37604c5381510@osafoundation.org> 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-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41F9FEB8.9070507@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9353 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 08:59:10 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > By the way, I agree with this wording. I would be even happier if it > also required the server to allow LOCK on any binding to refresh the > lock already existing. Can we add that? In theory, we *can* state everything that is correct. In practice, the set of additional statements we can make is infinite, so it would be nice if you could describe why anyone would come to the impression that LOCK refresh is in any way different than other methods. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 06:11:13 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18566 for ; Fri, 28 Jan 2005 06:11:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuTzw-0000so-0X for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 11:09:08 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuTzv-0000s9-8B for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 11:09:07 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CuTzu-0002kw-Rr for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 11:09:07 +0000 Received: (qmail invoked by alias); 28 Jan 2005 11:08:32 -0000 Received: from p50825E9D.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.157) by mail.gmx.net (mp029) with SMTP; 28 Jan 2005 12:08:32 +0100 X-Authenticated: #1915285 Message-ID: <41FA1D29.3050902@gmx.de> Date: Fri, 28 Jan 2005 12:08:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) 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 X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Microsoft releases a WebFolder client update, available for all platforms X-Archived-At: http://www.w3.org/mid/41FA1D29.3050902@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9354 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 11:09:08 +0000 Content-Transfer-Encoding: 7bit Hi, KB article: Download link: Entry in my version tracker: I haven't had time yet to do regression tests with the new release; feedback about what works now (and what still doesn't :-) appreciated. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 10:34:06 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09429 for ; Fri, 28 Jan 2005 10:34:05 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuY70-0001jw-6z for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 15:32:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuY6z-0001ir-AY for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 15:32:41 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuY6z-000898-32 for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 15:32:41 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SFWVaa032588 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jan 2005 07:32:33 -0800 In-Reply-To: <83D8695D-70DC-11D9-AD7B-000D93324AD6@gbiv.com> References: <83D8695D-70DC-11D9-AD7B-000D93324AD6@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95c9c95a73af12e1d7f2b77d2aa3e4b3@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , " webdav" From: Lisa Dusseault Date: Fri, 28 Jan 2005 07:32:24 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: ETags? X-Archived-At: http://www.w3.org/mid/95c9c95a73af12e1d7f2b77d2aa3e4b3@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9355 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 15:32:42 +0000 Content-Transfer-Encoding: 7bit Thanks for continuing with this, but I think there's still a slight misunderstanding somewhere. Of course you are correct that any implementation that allows functionality like bindings under the cover can have multiple URLs to the same resource, and the BIND spec doesn't introduce that. I understand that, and I can see how that would leave the situation materially unchanged (although I can't see how clarification would be harmful). What the BIND spec does is it adds the ability for a client to detect unambiguously that two different URLs are bindings to the same resource. BIND introduces the possibility that a client may behave differently with respect to two URLs when it knows that they map to the same resource. So by implementing RFC2616 alone, a client clearly has no option other than to cache one ETag per URL (and per variant, version, etc). Now by implementing BIND, a client might believe that it can deal more directly with the resource because we've now provided the client a way to identify the resource. --- Apparently I need to address the issue of why some client might believe they can cache 1 ETag per resource. Looking at RFC2518: "However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags.". -- This implies that ETag is about a resource. " Every state token or ETag is either current, and hence describes the state of a resource, or is not current, and does not describe the state of a resource. The boolean operation of matching a state token or ETag to the current state of a resource thus resolves to a true or false value." -- This declares that an ETag describes the state of a resource. "The getetag property MUST be defined on any DAV compliant resource that returns the Etag header." -- As with much other text about properties in RFC2518, this clearly defines that the property relates to the resource. Looking at RFC2616: "Entity tags are used for comparing two or more entities from the same requested resource." and "The entity tag MAY be used for comparison with other entities from the same resource." -- and with BIND, the client can now compare with entities from another binding to the same resource. Conclusion: At least one reader finds from reading specification text that it implies that ETags are consistent for a resource across bindings. While I would slightly prefer BIND to make my conclusion clear to readers (would make synchronization easier), I would find it acceptable if BIND made Roy's answer clear in the spec. We just need to come down on it on one side or another, and put that in the spec. Lisa On Jan 27, 2005, at 7:27 PM, Roy T. Fielding wrote: > On Jan 27, 2005, at 6:31 PM, Lisa Dusseault wrote: >> Yes, but as I explained in this email -- >> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html >> >> -- the bindings draft introduces the possibility for client behavior >> which could be harmful to interoperability unless the way that ETags >> interact with bindings is defined. > > And has been explained in multiple responses, bindings does not > introduce such behavior -- it is present in any implementation > that allows such things as Alias configurations -- and there > is absolutely nothing that bindings can say about it that isn't > already in the definition of etag in RFC 2616. > >> Since bindings first introduces this possibility, that's our best >> choice for a document in which to resolve that potential >> interoperability problem. > > There is no interoperability problem. You are imagining that there > might be an interoperability problem if the client developer makes > an egregious mistake in assuming the implementation behind the > interface defined by HTTP. Quite frankly, that is not our problem. > > ....Roy > From w3c-dist-auth-request@w3.org Fri Jan 28 12:36:00 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21786 for ; Fri, 28 Jan 2005 12:36:00 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cua19-0005v4-5V for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 17:34:47 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cua18-0005ua-CE for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 17:34:46 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Cua18-0005K9-4M for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 17:34:46 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SHYj1U028746; Fri, 28 Jan 2005 09:34:45 -0800 Date: Fri, 28 Jan 2005 09:34:45 -0800 Message-Id: <200501281734.j0SHYj1U028746@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200501281734.j0SHYj1U028746@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9356 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 17:34:47 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From lisa@osafoundation.org 2005-01-28 09:34 ------- I can't quite get over not dealing with these interactions completely. However it's probably all too complicated and too much work to add to the Bind draft. Thus, I suggest we add text to Bind to say that the interactions between Bind and DeltaV functionality are not defined, and that servers may vary in how they resolve these undefined interactions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Jan 28 12:47:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22708 for ; Fri, 28 Jan 2005 12:47:32 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuaCg-0002Rk-9X for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 17:46:42 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuaCg-0002RG-39 for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 17:46:42 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1CuaCf-0007UI-Ro for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 17:46:42 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SHkWaa009863 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jan 2005 09:46:35 -0800 In-Reply-To: <41F9FEB8.9070507@gmx.de> References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Lisa Dusseault Date: Fri, 28 Jan 2005 09:46:26 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/1e71f7300a8e350572d66b4600ff4f67@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9357 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 17:46:42 +0000 Content-Transfer-Encoding: 7bit On Jan 28, 2005, at 12:58 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> By the way, I agree with this wording. I would be even happier if it >> also required the server to allow LOCK on any binding to refresh the >> lock already existing. Can we add that? > > In theory, we *can* state everything that is correct. In practice, the > set of additional statements we can make is infinite, so it would be > nice if you could describe why anyone would come to the impression > that LOCK refresh is in any way different than other methods. I really don't see where you're getting the "in practice the set is infinite" conclusion. In theory it's infinite, but in practice it's finite. All the issues that I currently consider unresolved were raised over six months ago. There are only three bugs open on Bind in bugzilla: - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 -- this was raised in an email sent Nov 18 2003 ("Bindings and GULP again") and also raised March 17 2004 ("Issues remaining with the Bind draft") - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71-- this was raised Nov 30 2004 ("Bindings and Permissions") but it's only an elaboration of an issue raised March 18 2004 ("Should REBIND preserve locks, other live properties") - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 -- this was raised March 17 2004 ("Issues remaining with the Bind draft") -- however I suggest we resolve this by explicitly saying in Bind that the interactions with DeltaV remain undefined. We're also currently discussing an issue recently re-raised by Brian, on how ETags might behave with multiple bindings, but on some investigation I see it was originally raised March 22 2004 ("Re: Issues remaining with the Bind draft") Now that I review the email history here I see only three more issues that I think are still unresolved: - What event does creationdate refer to (creation of binding A, B or resource): raised March 17 2004 ("Issues remaining with the Bind draft") - Does REBIND change the getlastmodified or getetag property values: raised March 17 2004 ("Issues remaining with the Bind draft") - How does copying bindings work: raised March 24 2004 ("COPY of a binding onto another binding of same resource") Far from being infinite, no substantively new issues have been added to this list since March of 2004. Adding text to resolve all these issues could take as much as a page added to the Bind spec and then we'd be done (as far as I'm concerned) and we'd have a good spec. Lisa (BTW I'll open new bugs to track the three issues I listed last -- unless I've overlooked some resolution, of course ) From w3c-dist-auth-request@w3.org Fri Jan 28 12:47:35 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22725 for ; Fri, 28 Jan 2005 12:47:34 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuaD2-0002YY-H2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 17:47:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuaD2-0002Xw-AP for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 17:47:04 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CuaD2-0007X4-2z for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 17:47:04 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SHl4e3028771; Fri, 28 Jan 2005 09:47:04 -0800 Date: Fri, 28 Jan 2005 09:47:04 -0800 Message-Id: <200501281747.j0SHl4e3028771@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200501281747.j0SHl4e3028771@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9358 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 17:47:04 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-28 09:47 ------- What we could say is that BIND doesn't make any statements about how DeltaV servers work or should work. I'm not sure why stating that we don't state something makes the spec better in any way, though. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Jan 28 12:56:04 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23715 for ; Fri, 28 Jan 2005 12:56:04 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuaL4-0004rP-IN for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 17:55:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuaL4-0004qv-CV for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 17:55:22 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuaKt-0003dx-T7 for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 17:55:12 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SHtLOe028802; Fri, 28 Jan 2005 09:55:21 -0800 Date: Fri, 28 Jan 2005 09:55:21 -0800 Message-Id: <200501281755.j0SHtLOe028802@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200501281755.j0SHtLOe028802@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9359 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 17:55:22 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 ------- Additional Comments From lisa@osafoundation.org 2005-01-28 09:55 ------- Well, in part it's a "cover our ass" kind of action to say that something is explicitly not dealt with. It tells reviewers (eg. the IESG) what is and isn't in scope, and if interactions with DeltaV aren't in scope, then the spec can still be considered to be complete. Also this kind of statement is a big warning sign to people implementing both DeltaV and Bind. It tells them to be careful, they're walking into uncharted territory and they really need to carefully consider each conclusion they draw from reading the two specs, because nobody's explained yet how they work together in the details. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Jan 28 13:17:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26189 for ; Fri, 28 Jan 2005 13:17:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuafI-0002QL-Q7 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 18:16:16 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuafI-0002Pr-89 for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 18:16:16 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CuafH-0003a7-U6 for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 18:16:16 +0000 Received: (qmail invoked by alias); 28 Jan 2005 18:15:43 -0000 Received: from p50825E9D.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.157) by mail.gmx.net (mp027) with SMTP; 28 Jan 2005 19:15:43 +0100 X-Authenticated: #1915285 Message-ID: <41FA814E.3080508@gmx.de> Date: Fri, 28 Jan 2005 19:15:42 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> In-Reply-To: <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41FA814E.3080508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9360 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 18:16:16 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > On Jan 28, 2005, at 12:58 AM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >> >>> By the way, I agree with this wording. I would be even happier if it >>> also required the server to allow LOCK on any binding to refresh the >>> lock already existing. Can we add that? >> >> >> In theory, we *can* state everything that is correct. In practice, the >> set of additional statements we can make is infinite, so it would be >> nice if you could describe why anyone would come to the impression >> that LOCK refresh is in any way different than other methods. > > > I really don't see where you're getting the "in practice the set is > infinite" conclusion. In theory it's infinite, but in practice it's > finite. All the issues that I currently consider unresolved were raised > over six months ago. I'll disagree, but that's not relevant here. Last Call is to get people reviewing the spec, so if people do that it's in general A Good Thing. > There are only three bugs open on Bind in bugzilla: > - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 -- this was > raised in an email sent Nov 18 2003 ("Bindings and GULP again") and also > raised March 17 2004 ("Issues remaining with the Bind draft") The problem here is the vague requirement to be "Bindings needs to completely describe how bindings interact with locks". Stating concrete cases where the interactions indeed aren't defined would be much more helpful. > - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71-- this was > raised Nov 30 2004 ("Bindings and Permissions") but it's only an > elaboration of an issue raised March 18 2004 ("Should REBIND preserve > locks, other live properties") It would be helpful if you could look at the answer that was entered () and comment on that. As far as I can tell, this is not a BIND issue so it should be closed. If you disagree, please follow up on my answer. > - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 -- this was > raised March 17 2004 ("Issues remaining with the Bind draft") -- however > I suggest we resolve this by explicitly saying in Bind that the > interactions with DeltaV remain undefined. No, they aren't "undefined". There are some scenarios where the specs (intentionally) do not require any specific server behaviour, but that doesn't mean that the topic in general is undefined. > We're also currently discussing an issue recently re-raised by Brian, on > how ETags might behave with multiple bindings, but on some investigation > I see it was originally raised March 22 2004 ("Re: Issues remaining with > the Bind draft") > > Now that I review the email history here I see only three more issues > that I think are still unresolved: > - What event does creationdate refer to (creation of binding A, B or > resource): raised March 17 2004 ("Issues remaining with the Bind draft") Answered in (follows from RFC2518's definition of DAV:getlastmodified). > - Does REBIND change the getlastmodified or getetag property values: > raised March 17 2004 ("Issues remaining with the Bind draft") Same. > - How does copying bindings work: raised March 24 2004 ("COPY of a > binding onto another binding of same resource") This was answered in , and as far as I can tell, you never followed up on that reply. Please understand that unless somebody who asks a question follows up on the answer, we obviously assume that the question was answered and that there is no open issue. > Far from being infinite, no substantively new issues have been added to > this list since March of 2004. Adding text to resolve all these issues > could take as much as a page added to the Bind spec and then we'd be > done (as far as I'm concerned) and we'd have a good spec. Well, last time you said half a page would be enough :-) Anyway, I'll suugest again that you actually make concrete proposals about what the spec should say, and then the WG can decide whether these statements are actually correct and belong into the spec. > Lisa > > (BTW I'll open new bugs to track the three issues I listed last -- > unless I've overlooked some resolution, of course ) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 13:19:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26292 for ; Fri, 28 Jan 2005 13:19:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cuai1-000324-Hq for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 18:19:05 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cuai1-00031R-C2 for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 18:19:05 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cuahq-0006v2-SH for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 18:18:55 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SIJ4ST028845; Fri, 28 Jan 2005 10:19:04 -0800 Date: Fri, 28 Jan 2005 10:19:04 -0800 Message-Id: <200501281819.j0SIJ4ST028845@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 5] Bindings and DeltaV aren't fully interspecified X-Archived-At: http://www.w3.org/mid/200501281819.j0SIJ4ST028845@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9361 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 18:19:05 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=5 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-28 10:19 ------- For the record: I disagree with the statement that BIND/DeltaV interactions are undefined. From BIND's point of view, it's perfectly ok that BIND will fail on certain resources, as a matter of fact we even have a precondition defined for that -- DAV:binding-allowed (). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Jan 28 13:29:14 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27082 for ; Fri, 28 Jan 2005 13:29:13 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cuar8-0005kV-RK for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 18:28:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cuar8-0005jw-LD for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 18:28:30 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cuaqy-0008Jq-5O for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 18:28:20 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SISU8t028871; Fri, 28 Jan 2005 10:28:30 -0800 Date: Fri, 28 Jan 2005 10:28:30 -0800 Message-Id: <200501281828.j0SISU8t028871@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 71] Clarify what servers may and may not do with privileges when BIND is used X-Archived-At: http://www.w3.org/mid/200501281828.j0SISU8t028871@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 18:28:30 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71 ------- Additional Comments From lisa@osafoundation.org 2005-01-28 10:28 ------- I can't say this isn't an issue for MOVE as well. So perhaps we do need a bug for RFC 2744 or RFC2518 or both. However, let's keep the discussion to BIND and REBIND alone -- we're now defining these. As a client implementor now, I can tell you it would be really great to rely on some server behavior when using BIND or REBIND to create or move a binding. Can we at least discuss this? I can throw up a straw man proposal. How about: "When a client uses BIND or REBIND to create/modify a binding to an existing resource, the server has three options: treat this as a new resource and overwrite the resource ACL with the permissions that would be inherited in the location of the new binding, treat this as an existing resource and do no ACL inheritance, or take a middle path and use ACL inheritance in the new location by adding the permissions granted to the ACLs already on the resource. A server SHOULD follow the last approach, as being the approach assumed to be closest to the user's desired model, where a resource bound to multiple URLs ought to be available to principals who would be able to access that URL had it been bound using PUT." ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Fri Jan 28 13:38:33 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28028 for ; Fri, 28 Jan 2005 13:38:33 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cuazz-00018p-QS for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 18:37:39 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cuazz-00018L-Ke for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 18:37:39 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1Cuazz-00080f-Cq for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 18:37:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0SIbcHY028897; Fri, 28 Jan 2005 10:37:38 -0800 Date: Fri, 28 Jan 2005 10:37:38 -0800 Message-Id: <200501281837.j0SIbcHY028897@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 71] Clarify what servers may and may not do with privileges when BIND is used X-Archived-At: http://www.w3.org/mid/200501281837.j0SIbcHY028897@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 18:37:39 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71 ------- Additional Comments From julian.reschke@greenbytes.de 2005-01-28 10:37 ------- Just because BIND is the spec we're currently finishing doesn't mean that it's a good idea to put all possible WebDAV-related clarifications into it. In this particular case, again, the answer is: this has nothing to do with BIND. The same question can be asked for MOVE. That being said: RFC3744 is very clear about the fact that ACLs are defined on the resource (), and that servers have some freedom in what they do with namespace operations (). I think that's all that currently can be said. If you want to recommend a more predictable behaviour, I think the right approach is to put that into a separate spec and to try to get community support for 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@w3.org Fri Jan 28 13:47:57 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28792 for ; Fri, 28 Jan 2005 13:47:57 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cub97-0004vL-2g for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 18:47:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cub96-0004uj-Rn for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 18:47:04 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by bart.w3.org with esmtp (Exim 4.34) id 1Cub96-0001OR-Ji for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 18:47:04 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SIkgaa016487 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jan 2005 10:46:44 -0800 In-Reply-To: <41FA814E.3080508@gmx.de> References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> <41FA814E.3080508@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Lisa Dusseault Date: Fri, 28 Jan 2005 10:46:37 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (bart.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9364 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 18:47:05 +0000 Content-Transfer-Encoding: 7bit >> - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 -- this was >> raised in an email sent Nov 18 2003 ("Bindings and GULP again") and >> also raised March 17 2004 ("Issues remaining with the Bind draft") > > The problem here is the vague requirement to be "Bindings needs to > completely describe how bindings interact with locks". Stating > concrete cases where the interactions indeed aren't defined would be > much more helpful. We've narrowed this down to a pretty small list of actual concrete cases, some of which are already dealt with: - we described how servers MUST allow UNLOCK on any binding - I *think* the interactions with lockdiscovery are OK now but I worry about whether clients will see unexpected URLs in that property - remaining is only to define how servers MUST handle lock refresh requests. --> I'll add this to the bug. > >> - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71-- this was >> raised Nov 30 2004 ("Bindings and Permissions") but it's only an >> elaboration of an issue raised March 18 2004 ("Should REBIND preserve >> locks, other live properties") > > It would be helpful if you could look at the answer that was entered > () and > comment on that. As far as I can tell, this is not a BIND issue so it > should be closed. If you disagree, please follow up on my answer. Done, thanks. > >> - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 -- this was >> raised March 17 2004 ("Issues remaining with the Bind draft") -- >> however I suggest we resolve this by explicitly saying in Bind that >> the interactions with DeltaV remain undefined. > > No, they aren't "undefined". There are some scenarios where the specs > (intentionally) do not require any specific server behaviour, but that > doesn't mean that the topic in general is undefined. Ok, so how about some wordsmithing to fix that? "Many of the interactions between Bind and DeltaV are defined by the requirements in both specifications. However, in cases where the interactions remain ambiguous or open to different implementations, this spec does not address how servers must implement the features." > >> We're also currently discussing an issue recently re-raised by Brian, >> on how ETags might behave with multiple bindings, but on some >> investigation I see it was originally raised March 22 2004 ("Re: >> Issues remaining with the Bind draft") >> Now that I review the email history here I see only three more issues >> that I think are still unresolved: >> - What event does creationdate refer to (creation of binding A, B or >> resource): raised March 17 2004 ("Issues remaining with the Bind >> draft") > > Answered in > 0097.html> (follows from RFC2518's definition of DAV:getlastmodified). That's great, I have no problems with this answer. Now it needs to be put in the specification. > >> - Does REBIND change the getlastmodified or getetag property values: >> raised March 17 2004 ("Issues remaining with the Bind draft") > > Same. I don't think this really answers the question. The answer in that email is "Same as MOVE (which means: usually not)." Even if the answer is that a server MAY change the getlastmodified or getetag property on a REBIND (I think MUST is more appropriate, BTW) the answer still needs to go in the spec. > >> - How does copying bindings work: raised March 24 2004 ("COPY of a >> binding onto another binding of same resource") > > This was answered in > 0143.html>, and as far as I can tell, you never followed up on that > reply. Please understand that unless somebody who asks a question > follows up on the answer, we obviously assume that the question was > answered and that there is no open issue. You're right, I failed to follow up on that one. The assumption that was underlying that problem was that you couldn't MOVE a binding of a resource to overwrite a binding of the same resource even with Overwrite: T. I suspect that some servers could easily forbid that on its own merits, so to speak, and a client that expected that to work would be surprised by the failure. Same thing with COPY -- you say it can work, so the spec should say that rather than let server implementors decide to forbid it. So how about "COPY and MOVE methods, when used with the "Overwrite: T" header, overwrite the destination as described in RFC2518. This behavior SHOULD NOT be different even if the source binding and the destination binding are actually bindings to the same resource." > >> Far from being infinite, no substantively new issues have been added >> to this list since March of 2004. Adding text to resolve all these >> issues could take as much as a page added to the Bind spec and then >> we'd be done (as far as I'm concerned) and we'd have a good spec. > > Well, last time you said half a page would be enough :-) Well I forgot a couple things :) > > Anyway, I'll suugest again that you actually make concrete proposals > about what the spec should say, and then the WG can decide whether > these statements are actually correct and belong into the spec. I have done so. Lisa From w3c-dist-auth-request@w3.org Fri Jan 28 14:08:39 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00879 for ; Fri, 28 Jan 2005 14:08:39 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CubTJ-0004W2-1e for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 19:07:57 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CubTI-0004VU-IF for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 19:07:56 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.34) id 1CubT8-0006Qr-0L for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 19:07:46 +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 j0SJ7MhP014967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Jan 2005 11:07:23 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0SJ7JJr029493 for ; Fri, 28 Jan 2005 11:07:20 -0800 (PST) Mime-Version: 1.0 Message-Id: Date: Fri, 28 Jan 2005 11:07:18 -0800 To: w3c-dist-auth@w3.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.7.0.111621 Received-SPF: none (lisa.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Clarifying text and spec completeness X-Archived-At: http://www.w3.org/mid/p06200703be20377d0b4d@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9365 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 19:07:57 +0000 Having followed the conversation over the past few days, I'm hearing a lot of assertions over where the right place is to include clarifying text and how much text is appropriate in various contexts. Some of those statements seem to have a lot of personal belief and heat tied up in them, to the extent that I am concerned that they do not reflect appropriate collegial treatment of other's opinions. Please be careful to respect each other, even when you disagree. As a bit of AD guidance, let me tell the group that the IESG has in my term rarely asked for the removal explanatory or clarifying text and has quite often asked for an increase in such text. This is a reflection of the increased complexity of some of our standards and the likelihood that those implementing a follow-on standard will not have been those that implemented the original. As a concrete example with bearing on these discussions, while the text related to e-tag handling in the XCAP specifications might, in theory, be entirely derived from other aspects of that spec or the underlying technologies, I and others felt that it would be valuable to make the behavior explicit in the XCAP specs. This was done with explanatory text and appropriate references to the underlying specifications. Making it overt also makes it far easier, to put it bluntly, for us to tell if the spec gets it wrong. That can be handy. I certainly understand the desire not to bloat every specification to include every other specification, and I respect the architectural purity of full functional differentiation. I encourage folks, though, to to focus on the question: "Will including this text increase or reduce the likelihood of implementor producing an interoperable implementation?" If there is a strong reason to believe the answer is "reduce", the text should go. If the answer is even likely to be "increase", though, erring on the side of inclusion does no harm and might do good. regards, Ted Hardie From w3c-dist-auth-request@w3.org Fri Jan 28 14:17:03 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03290 for ; Fri, 28 Jan 2005 14:17:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CubbR-00007C-0l for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 19:16:21 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CubbP-00006Z-Ev for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 19:16:19 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.34) id 1CubbP-0008G4-4g for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 19:16:19 +0000 Received: (qmail invoked by alias); 28 Jan 2005 19:15:46 -0000 Received: from p50825E9D.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.94.157) by mail.gmx.net (mp028) with SMTP; 28 Jan 2005 20:15:46 +0100 X-Authenticated: #1915285 Message-ID: <41FA8F60.6080308@gmx.de> Date: Fri, 28 Jan 2005 20:15:44 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> <41FA814E.3080508@gmx.de> <2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org> In-Reply-To: <2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41FA8F60.6080308@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9366 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 19:16:21 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > ..- > We've narrowed this down to a pretty small list of actual concrete > cases, some of which are already dealt with: > - we described how servers MUST allow UNLOCK on any binding > - I *think* the interactions with lockdiscovery are OK now but I worry > about whether clients will see unexpected URLs in that property As I already said *multiple* times, there are no URLs in that property (except for the lock token URI). > - remaining is only to define how servers MUST handle lock refresh > requests. --> I'll add this to the bug. I disagree that this needs to be undefined. BIND says: "A BIND request does not create a new resource, but simply makes available a new URI for submitting requests to an existing resource. The new URI is indistinguishable from any other URI when submitting a request to a resource. Only one round trip is needed to submit a request to the intended target. Servers are required to enforce the integrity of the relationships between the new URIs and the resources associated with them. Consequently, it may be very costly for servers to support BIND requests that cross server boundaries." () So we would only need to say something if this would be a case where this rule does not apply. > ... > Ok, so how about some wordsmithing to fix that? "Many of the > interactions between Bind and DeltaV are defined by the requirements in > both specifications. However, in cases where the interactions remain > ambiguous or open to different implementations, this spec does not > address how servers must implement the features." I personally think that this is the same as saying nothing, except for a more complex spec to maintain/read/understand and possible confusion by the reader ("what exactly is this trying to tell me?"). >>> We're also currently discussing an issue recently re-raised by >>> Brian, on how ETags might behave with multiple bindings, but on >>> some investigation I see it was originally raised March 22 2004 >>> ("Re: Issues remaining with the Bind draft") >>> Now that I review the email history here I see only three more >>> issues that I think are still unresolved: >>> - What event does creationdate refer to (creation of binding A, B >>> or resource): raised March 17 2004 ("Issues remaining with the Bind >>> draft") >> >> >> Answered in >> > 0097.html> (follows from RFC2518's definition of DAV:getlastmodified). > > > That's great, I have no problems with this answer. Now it needs to be > put in the specification. No, it doesn't. It's already in RFC2518. >>> - Does REBIND change the getlastmodified or getetag property >>> values: raised March 17 2004 ("Issues remaining with the Bind draft") >> >> >> Same. > > > I don't think this really answers the question. The answer in that > email is "Same as MOVE (which means: usually not)." > > Even if the answer is that a server MAY change the getlastmodified or > getetag property on a REBIND (I think MUST is more appropriate, BTW) > the answer still needs to go in the spec. REBIND is like MOVE. RFC2518 doesn't make any requirement about MOVE, so why should BIND make any? Any why would getlastmodified need to change? It certainly doesn't in a file system, for instance. >>> - How does copying bindings work: raised March 24 2004 ("COPY of a >>> binding onto another binding of same resource") >> >> >> This was answered in >> > 0143.html>, and as far as I can tell, you never followed up on that >> reply. Please understand that unless somebody who asks a question >> follows up on the answer, we obviously assume that the question was >> answered and that there is no open issue. > > > You're right, I failed to follow up on that one. > > The assumption that was underlying that problem was that you couldn't > MOVE a binding of a resource to overwrite a binding of the same > resource even with Overwrite: T. I suspect that some servers could > easily forbid that on its own merits, so to speak, and a client that > expected that to work would be surprised by the failure. Same thing > with COPY -- you say it can work, so the spec should say that rather > than let server implementors decide to forbid it. I don't understand. Moving "a" to "a" is a nop. Even if a server does reject that request, the state of the resource and it's bindings will be the same. If you feel this needs clarification, add it to the RFC2518 issues list. > So how about "COPY and MOVE methods, when used with the "Overwrite: T" > header, overwrite the destination as described in RFC2518. This > behavior SHOULD NOT be different even if the source binding and the > destination binding are actually bindings to the same resource." Why would anybody think it is different? I still don't see a problem here that would require additional spec text. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 14:39:31 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05690 for ; Fri, 28 Jan 2005 14:39:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cubwm-0006lT-K2 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 19:38:24 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cubwf-0006ic-So for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 19:38:17 +0000 Received: from kahuna.osafoundation.org ([204.152.186.98]) by lisa.w3.org with esmtp (Exim 4.34) id 1CubwV-0003Rn-DM for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 19:38:07 +0000 Old-X-Envelope-From: lisa@osafoundation.org Old-X-Envelope-To: w3c-dist-auth@w3.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j0SJc9aa022231 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jan 2005 11:38:11 -0800 In-Reply-To: <41FA8F60.6080308@gmx.de> References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> <41FA814E.3080508@gmx.de> <2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org> <41FA8F60.6080308@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0b78524469e7d2800519739c294aee74@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: WebDAV WG From: Lisa Dusseault Date: Fri, 28 Jan 2005 11:38:03 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Received-SPF: pass (lisa.w3.org: domain of lisa@osafoundation.org designates 204.152.186.98 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/0b78524469e7d2800519739c294aee74@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9367 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 19:38:24 +0000 Content-Transfer-Encoding: 7bit On Jan 28, 2005, at 11:15 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> ..- >> We've narrowed this down to a pretty small list of actual concrete >> cases, some of which are already dealt with: >> - we described how servers MUST allow UNLOCK on any binding >> - I *think* the interactions with lockdiscovery are OK now but I >> worry about whether clients will see unexpected URLs in that >> property > > As I already said *multiple* times, there are no URLs in that property > (except for the lock token URI). Sorry I didn't give enough detail there; the "lockroot" goes in there in RFC2518bis, but of course we can clarify that in RFC2518bis. That's why I think that the value of 'lockdiscovery' may be clear enough. > >> - remaining is only to define how servers MUST handle lock refresh >> requests. --> I'll add this to the bug. > > I disagree that this needs to be undefined. BIND says: > > "A BIND request does not create a new resource, but simply makes > available a new URI for submitting requests to an existing resource. > The new URI is indistinguishable from any other URI when submitting a > request to a resource. Only one round trip is needed to submit a > request to the intended target. Servers are required to enforce the > integrity of the relationships between the new URIs and the resources > associated with them. Consequently, it may be very costly for servers > to support BIND requests that cross server boundaries." > > ( latest.html#rfc.section.1.p.6>) > > So we would only need to say something if this would be a case where > this rule does not apply. Actually, I think that language is misleading. Naturally, the new URI is distinguishable from any other URI when submitting certain requests, the most obvious of which is UNBIND. > >> ... >> Ok, so how about some wordsmithing to fix that? "Many of the >> interactions between Bind and DeltaV are defined by the requirements >> in both specifications. However, in cases where the interactions >> remain ambiguous or open to different implementations, this spec >> does not address how servers must implement the features." > > I personally think that this is the same as saying nothing, except for > a more complex spec to maintain/read/understand and possible confusion > by the reader ("what exactly is this trying to tell me?"). All right, how about "The interactions between Bind and DeltaV are largely defined by the requirements in each specification. However, further clarifications are out of the scope of this document." Is that simple enough? > >>>> We're also currently discussing an issue recently re-raised by >>>> Brian, on how ETags might behave with multiple bindings, but on >>>> some investigation I see it was originally raised March 22 2004 >>>> ("Re: Issues remaining with the Bind draft") >>>> Now that I review the email history here I see only three more >>>> issues that I think are still unresolved: >>>> - What event does creationdate refer to (creation of binding A, B >>>> or resource): raised March 17 2004 ("Issues remaining with the >>>> Bind draft") >>> >>> >>> Answered in >>> >> 0097.html> (follows from RFC2518's definition of >>> DAV:getlastmodified). >> That's great, I have no problems with this answer. Now it needs to >> be put in the specification. > > No, it doesn't. It's already in RFC2518. Great. Then we just need to say that: "A BIND request MUST NOT change the value of the getlastmodified property of a resource" --> Repeat requirement for UNBIND and REBIND or phrase in one sentence depending on how you want to organize the spec. > >>>> - Does REBIND change the getlastmodified or getetag property >>>> values: raised March 17 2004 ("Issues remaining with the Bind >>>> draft") >>> >>> >>> Same. >> I don't think this really answers the question. The answer in that >> email is "Same as MOVE (which means: usually not)." >> Even if the answer is that a server MAY change the getlastmodified or >> getetag property on a REBIND (I think MUST is more appropriate, BTW) >> the answer still needs to go in the spec. > > REBIND is like MOVE. RFC2518 doesn't make any requirement about MOVE, > so why should BIND make any? Any why would getlastmodified need to > change? It certainly doesn't in a file system, for instance. I don't consider the answer that "RFC2518 is incomplete" to be a good argument for leaving Bind incomplete. We can also raise an issue for RFC2518bis. As to why getlastmodified might change, well it depends what the server implementor considers to be the state of the resource. > >>>> - How does copying bindings work: raised March 24 2004 ("COPY of a >>>> binding onto another binding of same resource") >>> >>> >>> This was answered in >>> >> 0143.html>, and as far as I can tell, you never followed up on that >>> reply. Please understand that unless somebody who asks a question >>> follows up on the answer, we obviously assume that the question was >>> answered and that there is no open issue. >> You're right, I failed to follow up on that one. >> The assumption that was underlying that problem was that you couldn't >> MOVE a binding of a resource to overwrite a binding of the same >> resource even with Overwrite: T. I suspect that some servers could >> easily forbid that on its own merits, so to speak, and a client that >> expected that to work would be surprised by the failure. Same thing >> with COPY -- you say it can work, so the spec should say that rather >> than let server implementors decide to forbid it. > > I don't understand. Moving "a" to "a" is a nop. Even if a server does > reject that request, the state of the resource and it's bindings will > be the same. > > If you feel this needs clarification, add it to the RFC2518 issues > list. This is something that servers might treat differently in the presence of bind-like features, which is why I suggest it for Bind. Lisa From w3c-dist-auth-request@w3.org Fri Jan 28 15:10:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08477 for ; Fri, 28 Jan 2005 15:10:01 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CucQb-0001WS-V7 for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 20:09:13 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CucQb-0001Vq-Iw for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 20:09:13 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CucQb-00027u-4o for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 20:09:13 +0000 Received: (qmail invoked by alias); 28 Jan 2005 20:08:40 -0000 Received: from p54856984.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.105.132) by mail.gmx.net (mp007) with SMTP; 28 Jan 2005 21:08:40 +0100 X-Authenticated: #1915285 Message-ID: <41FA9BC6.4030607@gmx.de> Date: Fri, 28 Jan 2005 21:08:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: <262d3bd914fb960eafd37604c5381510@osafoundation.org> <41F9FEB8.9070507@gmx.de> <1e71f7300a8e350572d66b4600ff4f67@osafoundation.org> <41FA814E.3080508@gmx.de> <2a20d4d594f9dae7eff7a06fad57b7f8@osafoundation.org> <41FA8F60.6080308@gmx.de> <0b78524469e7d2800519739c294aee74@osafoundation.org> In-Reply-To: <0b78524469e7d2800519739c294aee74@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks. X-Archived-At: http://www.w3.org/mid/41FA9BC6.4030607@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9368 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 20:09:13 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Jan 28, 2005, at 11:15 AM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >> >>> ..- >>> We've narrowed this down to a pretty small list of actual concrete >>> cases, some of which are already dealt with: >>> - we described how servers MUST allow UNLOCK on any binding >>> - I *think* the interactions with lockdiscovery are OK now but I >>> worry about whether clients will see unexpected URLs in that property >> >> >> As I already said *multiple* times, there are no URLs in that >> property (except for the lock token URI). > > > Sorry I didn't give enough detail there; the "lockroot" goes in there > in RFC2518bis, but of course we can clarify that in RFC2518bis. That's > why I think that the value of 'lockdiscovery' may be clear enough. Well, thanks for agreeing that BIND doesn't need to clarify something that doesn't exist yet (as it is only part of RFC2518bis). >>> - remaining is only to define how servers MUST handle lock refresh >>> requests. --> I'll add this to the bug. >> >> >> I disagree that this needs to be undefined. BIND says: >> >> "A BIND request does not create a new resource, but simply makes >> available a new URI for submitting requests to an existing resource. >> The new URI is indistinguishable from any other URI when submitting a >> request to a resource. Only one round trip is needed to submit a >> request to the intended target. Servers are required to enforce the >> integrity of the relationships between the new URIs and the resources >> associated with them. Consequently, it may be very costly for servers >> to support BIND requests that cross server boundaries." >> >> (> latest.html#rfc.section.1.p.6>) >> >> So we would only need to say something if this would be a case where >> this rule does not apply. > > > Actually, I think that language is misleading. Naturally, the new URI > is distinguishable from any other URI when submitting certain requests, > the most obvious of which is UNBIND. Not at all, check the definition for UNBIND (): "The UNBIND method modifies the collection identified by the Request-URI, by removing the binding identified by the segment specified in the UNBIND body." > All right, how about "The interactions between Bind and DeltaV are > largely defined by the requirements in each specification. However, > further clarifications are out of the scope of this document." > > Is that simple enough? I don't think this is helpful, but if you can get a rough consensus for that change, we can do it. >>> That's great, I have no problems with this answer. Now it needs to >>> be put in the specification. >> >> >> No, it doesn't. It's already in RFC2518. > > > Great. Then we just need to say that: > "A BIND request MUST NOT change the value of the getlastmodified > property of a resource" RFC2518 doesn't say that, nor should BIND. In particular, WebDAV implementations that derive ETags from the lastmod filestamp in the filesystem usually must touch the file in order to ensure proper ETag semantics. >> REBIND is like MOVE. RFC2518 doesn't make any requirement about MOVE, >> so why should BIND make any? Any why would getlastmodified need to >> change? It certainly doesn't in a file system, for instance. > > > I don't consider the answer that "RFC2518 is incomplete" to be a good > argument for leaving Bind incomplete. We can also raise an issue for > RFC2518bis. I didn't say RFC2518 is "incomplete". It just doesn't make any requirement, and as far as I can tell, it shouldn't. > ... >>>> This was answered in >>>> >>> 0143.html>, and as far as I can tell, you never followed up on >>>> that reply. Please understand that unless somebody who asks a >>>> question follows up on the answer, we obviously assume that the >>>> question was answered and that there is no open issue. >>> >>> You're right, I failed to follow up on that one. >>> The assumption that was underlying that problem was that you >>> couldn't MOVE a binding of a resource to overwrite a binding of the >>> same resource even with Overwrite: T. I suspect that some >>> servers could easily forbid that on its own merits, so to speak, >>> and a client that expected that to work would be surprised by the >>> failure. Same thing with COPY -- you say it can work, so the spec >>> should say that rather than let server implementors decide to >>> forbid it. >> >> >> I don't understand. Moving "a" to "a" is a nop. Even if a server does >> reject that request, the state of the resource and it's bindings will >> be the same. >> >> If you feel this needs clarification, add it to the RFC2518 issues list. > > > This is something that servers might treat differently in the presence > of bind-like features, which is why I suggest it for Bind. What does the presence of "bind-like" features have to do with that? Please explain. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 15:21:43 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09798 for ; Fri, 28 Jan 2005 15:21:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cucc0-0005Fe-WD for w3c-dist-auth-dist@listhub.w3.org; Fri, 28 Jan 2005 20:21:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cucc0-0005FA-L6 for w3c-dist-auth@listhub.w3.org; Fri, 28 Jan 2005 20:21:00 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1Cucbq-0002M4-2V for w3c-dist-auth@w3.org; Fri, 28 Jan 2005 20:20:50 +0000 Received: (qmail invoked by alias); 28 Jan 2005 20:20:27 -0000 Received: from p54856984.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.105.132) by mail.gmx.net (mp020) with SMTP; 28 Jan 2005 21:20:27 +0100 X-Authenticated: #1915285 Message-ID: <41FA9E89.5010503@gmx.de> Date: Fri, 28 Jan 2005 21:20:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie 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 (lisa.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Clarifying text and spec completeness X-Archived-At: http://www.w3.org/mid/41FA9E89.5010503@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9369 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 28 Jan 2005 20:21:00 +0000 Content-Transfer-Encoding: 7bit Hi Ted, in general I agree, but I'd like to add two points: - Adding guidance or clarification can be dangerous, if it isn't done carefully. I speak from experience, having added two clarifications in the previous drafts that turned out to be simply incorrect (thanks to Geoff and Roy catching these). - Many of the clarifications that people ask for have nothing to do with BIND, but with the base spec (RFC2518). Rather than discussing these things for BIND, I'd much prefer to get BIND out of the door, and then to invest our time into RFC2518bis (where those things really belong), which hasn't made a lot of progress in the last year. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Jan 28 19:53:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08558 for ; Fri, 28 Jan 2005 19:53:26 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1Cugpl-0004E5-4s for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Jan 2005 00:51:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cugpk-0004Db-0q for w3c-dist-auth@listhub.w3.org; Sat, 29 Jan 2005 00:51:28 +0000 Received: from wproxy.gmail.com ([64.233.184.206]) by lisa.w3.org with esmtp (Exim 4.34) id 1CugpZ-0008Ne-Kb for w3c-dist-auth@w3.org; Sat, 29 Jan 2005 00:51:17 +0000 Received: by wproxy.gmail.com with SMTP id 37so781821wra for ; Fri, 28 Jan 2005 16:50:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WDGwB1gt0PxUHb34PinTRXPqkRTzr6MY44fAnWigKlpX9wxdRq7wj+NKuuB/2AVHz1o9Hs0AePvW12QGFxeknnwq8ctPgJ+TLxB9GM2hVXZxqFi9WmG2mGV5UOjJOLthv+wwDyhUSCyMsGKGOQ5YuvKfPNIjwoII8qlSEvxRAS4= Received: by 10.54.28.75 with SMTP id b75mr196474wrb; Fri, 28 Jan 2005 16:50:56 -0800 (PST) Received: by 10.54.8.26 with HTTP; Fri, 28 Jan 2005 16:50:56 -0800 (PST) Message-ID: <488030720501281650450266cb@mail.gmail.com> Date: Fri, 28 Jan 2005 16:50:56 -0800 From: John Reese Reply-To: John Reese To: Julian Reschke Cc: w3c-dist-auth@w3.org In-Reply-To: <41F81BBF.7030104@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F81BBF.7030104@gmx.de> Received-SPF: pass (lisa.w3.org: domain of john.reese@gmail.com designates 64.233.184.206 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/488030720501281650450266cb@mail.gmail.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9370 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jan 2005 00:51:29 +0000 Content-Transfer-Encoding: 7bit On Wed, 26 Jan 2005 23:37:51 +0100, Julian Reschke wrote: > > John Baumgarten wrote: > > > > All- > > > > I've searched through the mail archives and 2518 and 2518bis-06, so > > forgive me if this is a well-known issue. > > > > After a lock-null has been converted to a either a collection or > > "regular" resource via a MKCOL or PUT, respectively, should the > > resulting resource still be locked? > > In RFC2518: yes. That's the whole point. > > In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped > URL creates an empty and locked (non-collection) resource. > > Best regards, Julian And what happens if you MOVE or COPY a resource onto a lock-null resource (in RFC 2518)? I found this hard to deduce based from the RFC. In 2518bis, I guess I have the same question -- on the new, empty, locked resource, a PUT to overwrite the content retains the LOCK. But do locks remain if a resource is overwritten by a MOVE or COPY? From w3c-dist-auth-request@w3.org Fri Jan 28 20:22:52 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10201 for ; Fri, 28 Jan 2005 20:22:51 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuhJJ-0004o3-HD for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Jan 2005 01:22:01 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuhJJ-0004nZ-5m for w3c-dist-auth@listhub.w3.org; Sat, 29 Jan 2005 01:22:01 +0000 Received: from scorpio.lunarpages.com ([64.235.234.122]) by bart.w3.org with esmtp (Exim 4.34) id 1CuhJI-0005zY-T5 for w3c-dist-auth@w3.org; Sat, 29 Jan 2005 01:22:01 +0000 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1CuhJG-0004Qu-DI; Fri, 28 Jan 2005 17:21:58 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2D14932C-7194-11D9-AD7B-000D93324AD6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: w3c-dist-auth@w3.org From: "Roy T. Fielding" Date: Fri, 28 Jan 2005 17:22:00 -0800 To: Ted Hardie X-Mailer: Apple Mail (2.619) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - w3.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com Received-SPF: none (bart.w3.org: domain of fielding@gbiv.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Clarifying text and spec completeness X-Archived-At: http://www.w3.org/mid/2D14932C-7194-11D9-AD7B-000D93324AD6@gbiv.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9371 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jan 2005 01:22:01 +0000 Content-Transfer-Encoding: 7bit On Jan 28, 2005, at 11:07 AM, Ted Hardie wrote: > Having followed the conversation over the past few days, I'm hearing > a lot of assertions over where the right place is to include clarifying > text and how much text is appropriate in various contexts. Some of > those statements seem to have a lot of personal belief and heat > tied up in them, to the extent that I am concerned that they do not > reflect appropriate collegial treatment of other's opinions. Please > be careful to respect each other, even when you disagree. Ted, while I agree with your advice, it is also inappropriate for a working group chair to insist that their own comments take priority over the opinion of the document authors and stated opinions of the people reviewing the documents on the mailing list. While such might be a reasonable position for a technical error or security-related issue in the specification, it is not appropriate for a matter of editorial preference. When the IETF process is ignored, discussion will inevitably begin to heat. > As a bit of AD guidance, let me tell the group that the IESG has in my > term > rarely asked for the removal explanatory or clarifying text and has > quite often asked for an increase in such text. This is a reflection > of the increased complexity of some of our standards and the > likelihood that those implementing a follow-on standard will not > have been those that implemented the original. The IESG should not allow independent specifications to define the behavior of other protocols, particularly when those other protocols are at a higher level in the standards process. They certainly did not allow me to fix some of the bugs in MIME while I was defining HTTP. > As a concrete example with bearing on these discussions, while the text > related to e-tag handling in the XCAP specifications might, in theory, > be entirely > derived from other aspects of that spec or the underlying > technologies, I and others > felt that it would be valuable to make the behavior explicit in the > XCAP specs. > This was done with explanatory text and appropriate references to the > underlying specifications. Making it overt also makes it far easier, > to put it > bluntly, for us to tell if the spec gets it wrong. That can be handy. Sorry Ted, but that is an excellent example. The XCAP specification is so long that I hadn't bothered to read it, which is a pity given that it is entirely dependent on two specifications for which I did most of the authoring. We should have learned that mistake from RFC 2616. I'll note, having just looked at draft-ietf-simple-xcap-05 Section 7.10, the description of etag makes it impossible for XCAP documents to be managed by modern content management applications (like those based on JSR 170) that are already based on XML content trees. In other words, your "valuable" explicit behavior is both wrong and damaging to XCAP deployment and should never have been placed in that spec. I'll also point out that use of "/~~/" as "syntactic sugar" is both unnecessary and a violation of basic URI design principles. Likewise, AUIDs are redundant to the information already supplied by the media type and XML namespace. Furthermore, use of Qnames as identifiers (Section 6.3) outside of XML parsing is an architectural error unless the document specification also guarantees that namespace prefixes remain constant (the namespace prefix has no meaning external to the parser tree and is therefore frequently translated upon storage into a registered prefix name, which may differ from the prefix used on PUT). Finally, the grammar for node-selector uses characters that are not allowed by RFC 3986 to appear in any URI and the suggestion that they be percent-encoded because of that is just laughable -- a far more sensible idea would be to use a syntax that is compatible with http URIs in the first place. And, of course, it is so nice to know that XCAP is restricted to HTTP/1.1, since that ties it to a specific version of a specific transfer protocol and we all know that will never change, right? Garbage. The same protocol could have been defined by a generic mapping of any application/*+xml document to path segments in URI syntax; 5 pages max and independent of any specific transfer protocol or XML Schema. The whole point of splitting orthogonal protocols into orthogonal specifications is to reduce complexity and coupling -- so that the technologies can be defined and evolved independently. XCAP fails that miserably and will be a nightmare to maintain over time. Cheers, Roy T. Fielding Chief Scientist, Day Software From w3c-dist-auth-request@w3.org Fri Jan 28 20:52:43 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12190 for ; Fri, 28 Jan 2005 20:52:43 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuhmB-00066b-0N for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Jan 2005 01:51:51 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuhmA-00065p-1m for w3c-dist-auth@listhub.w3.org; Sat, 29 Jan 2005 01:51:50 +0000 Received: from ithilien.qualcomm.com ([129.46.51.59]) by bart.w3.org with esmtp (Exim 4.34) id 1Cuhm9-0002B4-Oa for w3c-dist-auth@w3.org; Sat, 29 Jan 2005 01:51:49 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0T1pDeD005084; Fri, 28 Jan 2005 17:51:14 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j0T1pAJr000623; Fri, 28 Jan 2005 17:51:11 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <2D14932C-7194-11D9-AD7B-000D93324AD6@gbiv.com> References: <2D14932C-7194-11D9-AD7B-000D93324AD6@gbiv.com> Date: Fri, 28 Jan 2005 17:51:08 -0800 To: "Roy T. Fielding" From: Ted Hardie Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-PMX-Version: 4.7.0.111621 Received-SPF: none (bart.w3.org: domain of hardie@qualcomm.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Clarifying text and spec completeness X-Archived-At: http://www.w3.org/mid/p06200706be2097ae96e2@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9372 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jan 2005 01:51:51 +0000 Roy, Some responses inline. At 5:22 PM -0800 1/28/05, Roy T. Fielding wrote: > >Ted, while I agree with your advice, it is also inappropriate for >a working group chair to insist that their own comments take >priority over the opinion of the document authors and stated >opinions of the people reviewing the documents on the mailing list. >While such might be a reasonable position for a technical error or >security-related issue in the specification, it is not appropriate >for a matter of editorial preference. When the IETF process is >ignored, discussion will inevitably begin to heat. One of the charges the IETF gives to a working group is to ensure that the work meets the charter. If the working group chair or chairs believe it doesn't meet the charter (an implementable, interoperable spec covering subject $FOO being a common charge), it is her/his/their job to push. Getting pushed back is a part of the job too. Failing to be collegial in one's behavior during all of this pushing is not one of options. So, everyone, please push carefully. >>As a bit of AD guidance, let me tell the group that the IESG has in my term >>rarely asked for the removal explanatory or clarifying text and has >>quite often asked for an increase in such text. This is a reflection >>of the increased complexity of some of our standards and the >>likelihood that those implementing a follow-on standard will not >>have been those that implemented the original. > >The IESG should not allow independent specifications to define the >behavior of other protocols, particularly when those other protocols >are at a higher level in the standards process. They certainly did >not allow me to fix some of the bugs in MIME while I was defining HTTP. This is absolutely correct. But having a spec point to or excerpt those specs to get guidance in front of the implementors does not define those protocols, it highlights relevant issues. That's not a redefinition. >>As a concrete example with bearing on these discussions, while the text >>related to e-tag handling in the XCAP specifications might, in >>theory, be entirely >>derived from other aspects of that spec or the underlying >>technologies, I and others >>felt that it would be valuable to make the behavior explicit in the >>XCAP specs. >>This was done with explanatory text and appropriate references to the >>underlying specifications. Making it overt also makes it far >>easier, to put it >>bluntly, for us to tell if the spec gets it wrong. That can be handy. > >Sorry Ted, but that is an excellent example. The XCAP specification >is so long that I hadn't bothered to read it, which is a pity >given that it is entirely dependent on two specifications for which >I did most of the authoring. We should have learned that mistake >from RFC 2616. > >I'll note, having just looked at draft-ietf-simple-xcap-05 >Section 7.10, the description of etag makes it impossible for >XCAP documents to be managed by modern content management >applications (like those based on JSR 170) that are already >based on XML content trees. In other words, your "valuable" >explicit behavior is both wrong and damaging to XCAP deployment >and should never have been placed in that spec. We should have this discussion on the SIMPLE mailing list, where specific behavior for e-Tags was discussed extensively. I believe that the behavior they have specified is a restricted profile of the permitted behaviors for e-Tags; that, at least, is the intent. If you can demonstrate that the behavior they have specified is *not permitted* by the base spec, then please say so to the authors/IESG now. The document is not yet out in the wild. That said, I also believe we have to take specs and look at their applicability as we evaluate them; some aspects of the work of the IETF is to build building blocks of very general applicability and some is to build protocols with narrow ranges of application. XCAP was created for a very specific set of deployments, and in those deployments the behavior specified not only makes sense, the WG saw it as pretty close to optimal. What scare me is the presumption that XCAP will be generalizable, and that people will believe it is a more general content management system. The same choices that made sense for managing a buddy list for a cell phone client are lousy for managing a full-fledged XML data store. But that doesn't make the first one a task we shouldn't take on. regards, Ted Hardie From w3c-dist-auth-request@w3.org Sat Jan 29 04:09:02 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23751 for ; Sat, 29 Jan 2005 04:09:02 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuoZe-0004zo-8o for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Jan 2005 09:07:22 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuoZd-0004yl-Bd for w3c-dist-auth@listhub.w3.org; Sat, 29 Jan 2005 09:07:21 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CuoZS-0004un-PW for w3c-dist-auth@w3.org; Sat, 29 Jan 2005 09:07:11 +0000 Received: (qmail invoked by alias); 29 Jan 2005 09:06:48 -0000 Received: from p54856984.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.105.132) by mail.gmx.net (mp026) with SMTP; 29 Jan 2005 10:06:48 +0100 X-Authenticated: #1915285 Message-ID: <41FB5226.6050302@gmx.de> Date: Sat, 29 Jan 2005 10:06:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Reese CC: w3c-dist-auth@w3.org References: <41F81BBF.7030104@gmx.de> <488030720501281650450266cb@mail.gmail.com> In-Reply-To: <488030720501281650450266cb@mail.gmail.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: lock-null's Still Locked after MKCOL or PUT conversion? X-Archived-At: http://www.w3.org/mid/41FB5226.6050302@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9373 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jan 2005 09:07:22 +0000 Content-Transfer-Encoding: 7bit John Reese wrote: > On Wed, 26 Jan 2005 23:37:51 +0100, Julian Reschke > wrote: > >>John Baumgarten wrote: >> >>>All- >>> >>>I've searched through the mail archives and 2518 and 2518bis-06, so >>>forgive me if this is a well-known issue. >>> >>>After a lock-null has been converted to a either a collection or >>>"regular" resource via a MKCOL or PUT, respectively, should the >>>resulting resource still be locked? >> >>In RFC2518: yes. That's the whole point. >> >>In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped >>URL creates an empty and locked (non-collection) resource. >> >>Best regards, Julian > > > And what happens if you MOVE or COPY a resource onto a lock-null > resource (in RFC 2518)? I found this hard to deduce based from the > RFC. MOVE with Overwrite implicitly deletes the resource, so it will be gone (with it's lock): . The behaviour for COPY will depend on whether the server implements RFC2518's definition () or RFC3253's clarification (). In the latter case (if you supply the lock token), the resource will be updated, staying locked. > In 2518bis, I guess I have the same question -- on the new, empty, > locked resource, a PUT to overwrite the content retains the LOCK. But > do locks remain if a resource is overwritten by a MOVE or COPY? Same answers. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Jan 29 09:07:15 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11628 for ; Sat, 29 Jan 2005 09:07:15 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CutDg-0001Ge-V9 for w3c-dist-auth-dist@listhub.w3.org; Sat, 29 Jan 2005 14:05:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CutDg-0001G5-1b for w3c-dist-auth@listhub.w3.org; Sat, 29 Jan 2005 14:05:00 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by lisa.w3.org with esmtp (Exim 4.34) id 1CutDV-0005c2-Iy for w3c-dist-auth@w3.org; Sat, 29 Jan 2005 14:04:49 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0TE4TXB027689 for ; Sat, 29 Jan 2005 09:04:29 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0TE4T0l266864 for ; Sat, 29 Jan 2005 09:04:29 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0TE4Thj006631 for ; Sat, 29 Jan 2005 09:04:29 -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 j0TE4TpM006627 for ; Sat, 29 Jan 2005 09:04:29 -0500 In-Reply-To: <41FB5226.6050302@gmx.de> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sat, 29 Jan 2005 09:04:24 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/29/2005 09:04:28, Serialize complete at 01/29/2005 09:04:28 Content-Type: multipart/alternative; boundary="=_alternative 004D4F4185256F98_=" Received-SPF: pass (lisa.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Perils of "guidance" (was Re: lock-null's Still Locked after MKCOL or PUT conversion?) X-Archived-At: http://www.w3.org/mid/OFB6AF96C4.6891A806-ON85256F98.004A8702-85256F98.004D4F44@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9374 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jan 2005 14:05:00 +0000 This is a multipart message in MIME format. --=_alternative 004D4F4185256F98_= Content-Type: text/plain; charset="US-ASCII" This situation with lock-null resources is a good illustration of the perils of placing "guidance" on how to use a given feature in specifications that don't define that feature. In 2518bis, we are adjusting the behavior that results when you apply LOCK to an unmapped URI, because of interoperability problems with the "lock-null resource" approach defined in RFC-2518. If all of our other specifications (e.g., DeltaV and ACL) carefully gave guidance on how to handle lock-null resources (and there are far more problematic interactions between DeltaV and ACL with lock-null resources, than there are between BIND and locking or etags), we would have a huge mess on our hands when RFC-2518bis was released. It is that kind of experience that cause the authors of the BIND specification to keep pushing back strongly on placing in a specification guidance on features defined in other specifications, especially for aspects of those features currently under design discussion (such as whether or not you have to apply UNLOCK to the URL to which the LOCK was originally applied). And to be clear, there certainly is the need for documents that give implementation guidance to implementors (and with the internet, there are a variety of inexpensive mechanisms for distributing that information), but putting that guidance in the specification itself is extremely harmful. It would be very easy (and very tempting) for the authors that are largely exhausted by this process to just agree to put in random bits of this kind of guidance even though we know it is harmful, but it would be wrong and remiss of us to do so. I believe the recent support from Roy has demonstrated that there are experienced and successful protocol designers that agree with the position taken by the authors. It used to be the case that the chair of the WebDAV working group gave guidance and suggestions, but ultimately respected the judgement and experience of the authors. Ah, those were the days (:-). Cheers, Geoff Julian wrote on 01/29/2005 04:06:46 AM: > > John Reese wrote: > > On Wed, 26 Jan 2005 23:37:51 +0100, Julian Reschke > > wrote: > > > >>John Baumgarten wrote: > >> > >>>All- > >>> > >>>I've searched through the mail archives and 2518 and 2518bis-06, so > >>>forgive me if this is a well-known issue. > >>> > >>>After a lock-null has been converted to a either a collection or > >>>"regular" resource via a MKCOL or PUT, respectively, should the > >>>resulting resource still be locked? > >> > >>In RFC2518: yes. That's the whole point. > >> > >>In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped > >>URL creates an empty and locked (non-collection) resource. > >> > >>Best regards, Julian > > > > > > And what happens if you MOVE or COPY a resource onto a lock-null > > resource (in RFC 2518)? I found this hard to deduce based from the > > RFC. > > MOVE with Overwrite implicitly deletes the resource, so it will be gone > (with it's lock): > . > > The behaviour for COPY will depend on whether the server implements > RFC2518's definition > () or > RFC3253's clarification > (). In > the latter case (if you supply the lock token), the resource will be > updated, staying locked. > > > In 2518bis, I guess I have the same question -- on the new, empty, > > locked resource, a PUT to overwrite the content retains the LOCK. But > > do locks remain if a resource is overwritten by a MOVE or COPY? > > Same answers. > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 004D4F4185256F98_= Content-Type: text/html; charset="US-ASCII"
This situation with lock-null resources is a good illustration
of the perils of placing "guidance" on how to use a given feature
in specifications that don't define that feature.

In 2518bis, we are adjusting the behavior that results when you
apply LOCK to an unmapped URI, because of interoperability problems
with the "lock-null resource" approach defined in RFC-2518.

If all of our other specifications (e.g., DeltaV and ACL) carefully
gave guidance on how to handle lock-null resources (and there are
far more problematic interactions between DeltaV and ACL with
lock-null resources, than there are between BIND and locking or etags),
we would have a huge mess on our hands when RFC-2518bis was released.

It is that kind of experience that cause the authors of the BIND
specification to keep pushing back strongly on placing in a
specification guidance on features defined in
other specifications, especially for aspects of those features
currently under design discussion (such as whether or not you have
to apply UNLOCK to the URL to which the LOCK was originally applied).

And to be clear, there certainly is the need for documents that
give implementation guidance to implementors (and with the internet,
there are a variety of inexpensive mechanisms for distributing
that information), but putting that guidance in the specification
itself is extremely harmful.

It would be very easy (and very tempting) for the authors that are
largely exhausted by this process to just agree to put in random
bits of this kind of guidance even though we know it is harmful,
but it would be wrong and remiss of us to do so.

I believe the recent support from Roy has demonstrated that there are
experienced and successful protocol designers that agree with the
position taken by the authors.  It used to be the case that the
chair of the WebDAV working group gave guidance and suggestions,
but ultimately respected the judgement and experience of the authors.  
Ah, those were the days (:-).

Cheers,
Geoff

Julian wrote on 01/29/2005 04:06:46 AM:
>
> John Reese wrote:
> > On Wed, 26 Jan 2005 23:37:51 +0100, Julian Reschke
> > <julian.reschke@gmx.de> wrote:
> >
> >>John Baumgarten wrote:
> >>
> >>>All-
> >>>
> >>>I've searched through the mail archives and 2518 and 2518bis-06, so
> >>>forgive me if this is a well-known issue.
> >>>
> >>>After a lock-null has been converted to a either a collection or
> >>>"regular" resource via a MKCOL or PUT, respectively, should the
> >>>resulting resource still be locked?
> >>
> >>In RFC2518: yes. That's the whole point.
> >>
> >>In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped
> >>URL creates an empty and locked (non-collection) resource.
> >>
> >>Best regards, Julian
> >
> >
> > And what happens if you MOVE or COPY a resource onto a lock-null
> > resource (in RFC 2518)?  I found this hard to deduce based from the
> > RFC.
>
> MOVE with Overwrite implicitly deletes the resource, so it will be gone
> (with it's lock):
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.9.3>.
>
> The behaviour for COPY will depend on whether the server implements
> RFC2518's definition
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.8.4>) or
> RFC3253's clarification
> (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.7>). In
> the latter case (if you supply the lock token), the resource will be
> updated, staying locked.
>
> > In 2518bis, I guess I have the same question -- on the new, empty,
> > locked resource, a PUT to overwrite the content retains the LOCK.  But
> > do locks remain if a resource is overwritten by a MOVE or COPY?
>
> Same answers.
>
> Best regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 004D4F4185256F98_=-- From w3c-dist-auth-request@w3.org Sun Jan 30 10:13:21 2005 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09044 for ; Sun, 30 Jan 2005 10:13:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvGk6-0001Aq-Gb for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Jan 2005 15:12:02 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CvGk6-0001AM-AP for w3c-dist-auth@listhub.w3.org; Sun, 30 Jan 2005 15:12:02 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by bart.w3.org with esmtp (Exim 4.34) id 1CvGk6-0003d4-2x for w3c-dist-auth@w3.org; Sun, 30 Jan 2005 15:12:02 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0UFC0v5009561; Sun, 30 Jan 2005 07:12:00 -0800 Date: Sun, 30 Jan 2005 07:12:00 -0800 Message-Id: <200501301512.j0UFC0v5009561@ietf.cse.ucsc.edu> From: bugzilla@soe.ucsc.edu To: w3c-dist-auth@w3.org X-Bugzilla-Reason: QAContact Received-SPF: none (bart.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 72] Review references section X-Archived-At: http://www.w3.org/mid/200501301512.j0UFC0v5009561@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Jan 2005 15:12:02 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=72 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.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@w3.org Sun Jan 30 10:53:17 2005 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11774 for ; Sun, 30 Jan 2005 10:53:16 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvHNa-0006dG-Se for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Jan 2005 15:52:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CvHNZ-0006cm-U4 for w3c-dist-auth@listhub.w3.org; Sun, 30 Jan 2005 15:52:49 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CvHNP-00086E-B9 for w3c-dist-auth@w3.org; Sun, 30 Jan 2005 15:52:39 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0UFqncl009712; Sun, 30 Jan 2005 07:52:49 -0800 Date: Sun, 30 Jan 2005 07:52:49 -0800 Message-Id: <200501301552.j0UFqncl009712@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 74] New: Remove UUID generation instructions X-Archived-At: http://www.w3.org/mid/200501301552.j0UFqncl009712@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9377 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Jan 2005 15:52:50 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=74 Summary: Remove UUID generation instructions Product: WebDAV-RFC2518-bis Version: -06 Platform: Other OS/Version: other Status: NEW Severity: minor Priority: P2 Component: Appendix B. Appendices AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de QAContact: w3c-dist-auth@w3.org Instead, informatively refer to draft-mealling-urn-uuid, section 4. (see also ) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. From w3c-dist-auth-request@w3.org Sun Jan 30 11:00:56 2005 Received: from frink.w3.org (Debian-exim@frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09046 for ; Sun, 30 Jan 2005 10:13:21 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvGjp-00016L-S3 for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Jan 2005 15:11:45 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CvGjo-00015n-Ui for w3c-dist-auth@listhub.w3.org; Sun, 30 Jan 2005 15:11:44 +0000 Received: from ietf.cse.ucsc.edu ([128.114.52.130]) by lisa.w3.org with esmtp (Exim 4.34) id 1CvGje-0003D1-D6 for w3c-dist-auth@w3.org; Sun, 30 Jan 2005 15:11:34 +0000 Received: (from hunkim@localhost) by ietf.cse.ucsc.edu (8.12.8/8.11.4) id j0UFBhKl009545; Sun, 30 Jan 2005 07:11:43 -0800 Date: Sun, 30 Jan 2005 07:11:43 -0800 Message-Id: <200501301511.j0UFBhKl009545@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-Original-To: w3c-dist-auth@w3.org Subject: [Bug 73] "Changes" section missing X-Archived-At: http://www.w3.org/mid/200501301511.j0UFBhKl009545@ietf.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9375 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Jan 2005 15:11:45 +0000 http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact| |w3c-dist-auth@w3.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@w3.org Sun Jan 30 19:09:23 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15419 for ; Sun, 30 Jan 2005 19:09:23 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvOr8-00033F-DL for w3c-dist-auth-dist@listhub.w3.org; Sun, 30 Jan 2005 23:51:50 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CvOr7-00032c-Du for w3c-dist-auth@listhub.w3.org; Sun, 30 Jan 2005 23:51:49 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by lisa.w3.org with esmtp (Exim 4.34) id 1CvOqw-00044p-TI for w3c-dist-auth@w3.org; Sun, 30 Jan 2005 23:51:39 +0000 Received: from [IPv6:::1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.ossinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D952YJG3; Sun, 30 Jan 2005 16:44:31 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <70da38bd1900f693245cb119d503e608@jabber.com> Content-Transfer-Encoding: quoted-printable Cc: " webdav" From: Joe Hildebrand Date: Sun, 30 Jan 2005 16:51:12 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.619.2) Received-SPF: none (lisa.w3.org: domain of jhildebrand@jabber.com does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Perils of "guidance" (was Re: lock-null's Still Locked after MKCOL or PUT conversion?) X-Archived-At: http://www.w3.org/mid/70da38bd1900f693245cb119d503e608@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 30 Jan 2005 23:51:50 +0000 Content-Transfer-Encoding: quoted-printable > And to be clear, there certainly is the need for documents that > give implementation guidance to implementors (and with the internet, > there are a variety of inexpensive mechanisms for distributing > that information), but putting that guidance in the specification > itself is extremely harmful. Perhaps we should go ahead and start an implementation guide wiki (or=20 similar), so that the "guidance" texts have a place to live, so that=20 people feel like those clarifications won't get lost if they aren't in=20= the spec. Those who want a more explicit spec won't like this, since the text=20 will clearly be non-normative, and there will be two places to go to=20 figure out what to implement. However, if it means that implementors=20 don't have to solve the puzzle box themselves (if they know where to=20 look), maybe that would be good enough. > It would be very easy (and very tempting) for the authors that are > largely exhausted by this process to just agree to put in random > bits of this kind of guidance even though we know it is harmful, > but it would be wrong and remiss of us to do so. And I'm sure that folks who are concerned about the potential for=20 interop problems feel similarly. Let's see if we can't explore some=20 ways to work together with each other without having to resort to the=20 assumption that bad faith exists. As I've said recently, standards-making is both a technical *and* a=20 political process. Finding a way to achieve consensus, while not=20 giving up on core convictions such as these requires copious amounts of=20= maturity, camaraderie, or self-deprecating humor. > I believe the recent support from Roy has demonstrated that there are > experienced and successful protocol designers that agree with the > position taken by the authors. =A0It used to be the case that the > chair of the WebDAV working group gave guidance and suggestions, > but ultimately respected the judgement and experience of the authors. = =A0 > Ah, those were the days (:-). Um, this last bit may have strayed slightly from the collegiate tone=20 that Ted was just trying to coax us towards. Anything else I could=20 stay would push us even further from that ideal. --=20 Joe Hildebrand Denver, CO, USA From w3c-dist-auth-request@w3.org Sun Jan 30 21:09:29 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22699 for ; Sun, 30 Jan 2005 21:09:28 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvQyn-00060q-SW for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Jan 2005 02:07:53 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CvQym-000603-QS for w3c-dist-auth@listhub.w3.org; Mon, 31 Jan 2005 02:07:52 +0000 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by bart.w3.org with esmtp (Exim 4.34) id 1CvQym-00067o-M5 for w3c-dist-auth@w3.org; Mon, 31 Jan 2005 02:07:52 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id j0V27LXB014502 for ; Sun, 30 Jan 2005 21:07:21 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0V27LQX192812 for ; Sun, 30 Jan 2005 21:07:21 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j0V27Le8014244 for ; Sun, 30 Jan 2005 21:07:21 -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 j0V27L12014241 for ; Sun, 30 Jan 2005 21:07:21 -0500 In-Reply-To: <70da38bd1900f693245cb119d503e608@jabber.com> To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Sun, 30 Jan 2005 21:07:26 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 01/30/2005 21:07:20, Serialize complete at 01/30/2005 21:07:20 Content-Type: multipart/alternative; boundary="=_alternative 000BA8A185256F9A_=" Received-SPF: pass (bart.w3.org: domain of geoffrey.clemm@us.ibm.com designates 32.97.182.145 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Perils of "guidance" (was Re: lock-null's Still Locked after MKCOL or PUT conversion?) X-Archived-At: http://www.w3.org/mid/OF82ECBFCC.2D595637-ON85256F9A.000B306E-85256F9A.000BA8A4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9379 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Jan 2005 02:07:53 +0000 This is a multipart message in MIME format. --=_alternative 000BA8A185256F9A_= Content-Type: text/plain; charset="US-ASCII" I'd like to thank Joe for his continued patience and good humor. I will try harder in the future to emulate his good example (:-). Cheers, Geoff Joe Hildebrand wrote on 01/30/2005 06:51:12 PM: > > And to be clear, there certainly is the need for documents that > > give implementation guidance to implementors (and with the internet, > > there are a variety of inexpensive mechanisms for distributing > > that information), but putting that guidance in the specification > > itself is extremely harmful. > > Perhaps we should go ahead and start an implementation guide wiki (or > similar), so that the "guidance" texts have a place to live, so that > people feel like those clarifications won't get lost if they aren't in > the spec. --=_alternative 000BA8A185256F9A_= Content-Type: text/html; charset="US-ASCII"
I'd like to thank Joe for his continued patience and good humor.
I will try harder in the future to emulate his good example (:-).

Cheers,
Geoff

Joe Hildebrand <jhildebrand@jabber.com> wrote on 01/30/2005 06:51:12 PM:

> > And to be clear, there certainly is the need for documents that
> > give implementation guidance to implementors (and with the internet,
> > there are a variety of inexpensive mechanisms for distributing
> > that information), but putting that guidance in the specification
> > itself is extremely harmful.
>
> Perhaps we should go ahead and start an implementation guide wiki (or
> similar), so that the "guidance" texts have a place to live, so that
> people feel like those clarifications won't get lost if they aren't in
> the spec.

 --=_alternative 000BA8A185256F9A_=-- From w3c-dist-auth-request@w3.org Mon Jan 31 07:26:30 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21128 for ; Mon, 31 Jan 2005 07:26:30 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvabN-00028a-9g for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Jan 2005 12:24:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CvabM-000286-3m for w3c-dist-auth@listhub.w3.org; Mon, 31 Jan 2005 12:24:20 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.34) id 1CvabB-0001dS-DL for w3c-dist-auth@w3.org; Mon, 31 Jan 2005 12:24:09 +0000 Received: (qmail invoked by alias); 31 Jan 2005 12:23:47 -0000 Received: from p50825184.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.81.132) by mail.gmx.net (mp008) with SMTP; 31 Jan 2005 13:23:47 +0100 X-Authenticated: #1915285 Message-ID: <41FE2352.9080604@gmx.de> Date: Mon, 31 Jan 2005 13:23:46 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: Geoffrey M Clemm , webdav References: <70da38bd1900f693245cb119d503e608@jabber.com> In-Reply-To: <70da38bd1900f693245cb119d503e608@jabber.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.20 as permitted sender) X-Original-To: w3c-dist-auth@w3.org Subject: Re: Perils of "guidance" (was Re: lock-null's Still Locked after MKCOL or PUT conversion?) X-Archived-At: http://www.w3.org/mid/41FE2352.9080604@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Jan 2005 12:24:21 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Perhaps we should go ahead and start an implementation guide wiki (or > similar), so that the "guidance" texts have a place to live, so that > people feel like those clarifications won't get lost if they aren't in > the spec. Funny enough, we *do* have a Wiki running on webdav.org (), installed by Greg Stein. We could give that one a try. > Those who want a more explicit spec won't like this, since the text will > clearly be non-normative, and there will be two places to go to figure > out what to implement. However, if it means that implementors don't > have to solve the puzzle box themselves (if they know where to look), > maybe that would be good enough. Also, discussion and collaboration over there may end in text that can go into potential spec errata, spec revisions or new documents. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Jan 31 12:32:26 2005 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26747 for ; Mon, 31 Jan 2005 12:32:25 -0500 (EST) Received: from lists by frink.w3.org with local (Exim 4.34) id 1CvfO0-0004cJ-DQ for w3c-dist-auth-dist@listhub.w3.org; Mon, 31 Jan 2005 17:30:52 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CvfNz-0004bl-E7 for w3c-dist-auth@listhub.w3.org; Mon, 31 Jan 2005 17:30:51 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by lisa.w3.org with esmtp (Exim 4.34) id 1CvfNo-00037U-QZ for w3c-dist-auth@w3.org; Mon, 31 Jan 2005 17:30:40 +0000 Received: from tycho (dhcp-59-157.cse.ucsc.edu [128.114.59.157]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j0VHUnmw015069 for ; Mon, 31 Jan 2005 09:30:49 -0800 (PST) Message-Id: <200501311730.j0VHUnmw015069@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'webdav'" Date: Mon, 31 Jan 2005 09:30:43 -0800 Organization: UC Santa Cruz MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUGC8PXNvG50xyXSWm7WlXOeQtNCgBpIf6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Received-SPF: none (lisa.w3.org: domain of ejw@cs.ucsc.edu does not designate permitted sender hosts) X-Original-To: w3c-dist-auth@w3.org Subject: On clarification text in specifications X-Archived-At: http://www.w3.org/mid/200501311730.j0VHUnmw015069@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 31 Jan 2005 17:30:52 +0000 Content-Transfer-Encoding: 7bit The goal of writing protocol specifications is to create an on-demand communicative experience conveying sufficient knowledge about the data models, behavior, and on-the-wire marshalling of protocol elements such that an implementor can create a protocol implementation that is correct with respect to the specification, and is interoperable with other implementations. To the best of my knowledge, there is no research on the effectiveness of RFCs at communicating a protocol specification. As a result, there is simply no factual basis for either side of the argument concerning adding, or not adding, clarification text. The largely anecdotal evidence supports both sides. RFCs are long, and generally getting longer, leading to more shallow review. As a result, we should keep them as short as possible, with little or no clarification text. On the other side, even the most successful protocols have interoperability issues. It is my understanding that upwards of 25% of the code base of FTP protocol libraries is dedicated to handling interoperability issues with specific implementations. The IETF process itself has been developed assuming that interoperability problems are inevitable in implementations of RFCs, and need to be worked out over time. Arguments from first principles can also support both sides. Given a protocol that provides a clear description of its data model, behavior, and on-the-wire marshalling, an implementor should be possible to use logical implication to determine protocol behavior in all circumstances. Hence, no clarification text should be necessary, since in the extreme one would list all possible implications. Even when backing off from the extreme, it is difficult to pick a criteria for which implications to explicitly include, and which ones to omit. At present our specifications are only partially written using formal languages, and there are no explicitly defined logical implication rules for operating on specification assertions. As a result, it is *not* reasonable to assume that even careful readers will be using the same set of implication rules to answer questions about the specification. In fact, given the lack of formally expressed implication rules, there is no way to determine if different implication sets would lead to conflicting conclusions about the specification. In this situation, the best proxy for such knowledge is a situation where experienced protocol specifiers draw different conclusions about protocol behavior. Since these experts have some form of interal mechanism for making implications from protocol assertions, lack of agreement is indicative of a situation where the application of different implication rule sets lead to contradictory conclusions in the specification. In such situations, it is useful to add clarification text to disambiguate the outcomes of applying contradictory implication chains. Since protocol specifiers can reasonably have differing opinions on the value of clarifying text, what is a reasonable rule of thumb working groups can use to determine when to include clarification text? Ted Hardie's guidance here is right-on. If you have a situation where: 1) Expert opinion in a working group is divided after significant discussion, or 2) It took expert opinion considerable effort to develop a consensus understanding of a non-normative behavior, ... then ... *) If adding clarification text seems likely to increase interoperability, it should be included. If it seems likely to have no effect, or decrease interoperability, omit it. Additionally, any added text should be judged to be worth the cost in additional specification length. That is, if you have reasonable evidence supporting the conclusion there is an implication chain conflict among experienced readers, then if you can develop clear language clarifying the issue, it should be included. Since many implications are straightforward, and do not lead to disagreement, this criteria acts to discourage widespread inclusion of clarification text. Furthermore, any addition should weight its cost in terms of adding specification length. A multi-page example to settle a minor point is probably not a good tradeoff. One or two sentences to clarify a point is likely a reasonable tradeoff. Finally, it should be recalled that interoperability problems are fantastically expensive. Changing a single interoperability problem in the field can take years, and require significant engineering time across multiple organizations. If we as protocol specifiers can eliminate such errors, we save other engineers much time and money, and save end users from frustration and delay. - Jim