From w3c-dist-auth-request@frink.w3.org Fri Jun 3 14:27: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 OAA20816 for ; Fri, 3 Jun 2005 14:27:41 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DeGr2-0007Qr-JW for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Jun 2005 18:25:12 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DeGqy-0007Pk-JI for w3c-dist-auth@listhub.w3.org; Fri, 03 Jun 2005 18:25:08 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.50) id 1DeGqu-00015i-5B for w3c-dist-auth@w3.org; Fri, 03 Jun 2005 18:25:08 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j53IOxCK016230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Jun 2005 11:25:00 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j53IOYFH021176 for ; Fri, 3 Jun 2005 11:24:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 3 Jun 2005 11:24:32 -0700 To: w3c-dist-auth@w3.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-W3C-Hub-Spam-Status: No, score=-0.4 X-W3C-Scan-Sig: lisa.w3.org 1DeGqu-00015i-5B ebf6abfa02799300e0800667252e0541 X-Original-To: w3c-dist-auth@w3.org Subject: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/p06210201bec65037d8e1@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9649 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Jun 2005 18:25:12 +0000 Howdy, I've gotten a very small number of comments back to this either on-list or in private; if you have a comment, even a short "My level of interest is ....", I would appreciate your taking the time to send it. thanks, Ted At 1:12 PM -0700 5/27/05, Ted Hardie wrote: >Several folks have asked where the discussion of the updated >role of the WG Chair is documented. This is an output of the >PROTO team in the General area, and it is documented in >http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt. > >Though this is not yet an RFC, the IESG agreed to work using >these rules on an interim basis in February, and Scott Hollenbeck >announced that the APPs area would be using it at the most >recent Minneapolis IETF. As most of you know, I was not at >the meeting because of family commitments, but he did so >with my full agreement. > >Though this updates the methodologies by which a working group >chair and AD split the work of shepherding, it in some ways >codifies the way good working groups have always worked--active >working group chairs have always been involved in assuring that >adequate review inside and outside the working group has been >completed, that issues raised in Last Call or in IESG deliberation >are handled, and so. It has also long been the case that the >IESG's reading of RFC 2418 on the role of the WG chair has seen >a Working Group chair as responsible for assuring the community >that a document put forward to meet a working group milestone >is appropriate to the task (see Section 6.1). Chairs can do that >in multiple ways, but their own technical judgement is always >expected to form a part of that assessment. It is entirely appropriate >for a chair to state a technical problem with a spec and expect >the working group and editors to either resolve the problem or >document why the problem isn't an issue (usually in the spec). > >In cases where the working group chair has to call whether or not >there is working group consensus on a particular resolution to >a technical issue raised in this way, we can run into problems. >The usual way of doing that is to have at least two chairs, so that >one can handle the process call for technical issues raised by >the other. That strategy has been in place for this group since >I came on as AD, though I have to say a series of time commitment >issues has made it very hard to implement: Jim had very few cycles >at the time he stepped down; Patrik had to withdraw very shortly >after agreeing to take the role; Joe has had issues with his organization >supporting the time required. Joe attempted to augment the usual >mechanism by implementing a ticketing system, but those using >it seem to have plural opinions even on what it takes to close a ticket >so that it takes more, rather than less, effort to use it effectively. > >The forward progress in the face of that strategy's failure has not >been great. >At this point, I want to reiterate that Lisa's actions as Chair have been >both within my expectations as the AD for the group and that they have >had my support; we have discussed the working group's progress >on many occasions and the actions she and her co-chairs have taken >have had gone forward with my knowledge and consent. >She would be the first, I believe, to agree we have a problem in making >forward progress. She's also had the brunt of trying to resolve it, >and I thank her for her efforts. > >The question I have now is how to make that progress >when the existing strategy has failed multiple times. We can change >chairs, of course, and this might help clarify the process role vs. >the contributor roles. I am concerned, though, that is will not >be enough given the very small size of the working group's active >membership. Judging rough consensus on a technical topic among >only a few people when even one disagrees is tricky; if you solve >that problem by ensuring that the chair has sufficient technical >depth in the subject to adjudicate, you are back exactly where we >are now. > >We can decide that the problem of size does not admit of solution, >and we can shut down the working group. This leaves a lot of >WebDav's published specs augmented by unpublished "lore" that >is needed to get things done. I'm not thrilled by that, but if >there is no way to get further, we may have to do it. I will >be very reluctant to accept individual submissions for the >standards track on WebDav core issues if we go this route, >since that forces the IESG to resolve issues the WG could >not. It might happen, but it would take work on the >part of the proposers that is probably easier to accomplish >in a working group setting. > >We can also try to radically limit what the working group is trying >to accomplish and set out a firm deadline, after which the working >group MUST shut down. This helps focus energy and may encourage >folks who cannot commit to long term energy to commit to the short >term working group program. If we go this route, I strongly suggest >the working group consider a very draconian approach to reaching >compromise. One example I have seen outside the IETF that worked >was to say that if an issue could not be resolved within a set period >of time, the whole document involved sank to the bottom of the >WG's agenda--so everyone is clear that the failure to compromise >may mean that the document does not get out at all. This >requires a great deal of discipline and forces everyone to ask >a new question ("Is this issue big enough that the document should >not go forward at all if it is not fixed"). It can, however, work to >get out the documents for which the WG is close to consensus >and to focus work on others. > >I'd like to see the working group discuss these or other future paths. >I do remind folks to remain professional in their discussion and >that ad hominem comments are not tolerated; please think constructively >about what *you* can do to move us forward and especially about >what commitments *you* can take on. > regards, > Ted Hardie > as Area Advisor. From w3c-dist-auth-request@frink.w3.org Fri Jun 3 14:32: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 OAA21107 for ; Fri, 3 Jun 2005 14:32:44 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DeGxh-0001YS-4l for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Jun 2005 18:32:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DeGxe-0001Xu-MP for w3c-dist-auth@listhub.w3.org; Fri, 03 Jun 2005 18:32:02 +0000 Received: from agminet04.oracle.com ([141.146.126.231]) by bart.w3.org with esmtp (Exim 4.50) id 1DeGxe-0001yX-4Z for w3c-dist-auth@w3.org; Fri, 03 Jun 2005 18:32:02 +0000 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j53IVtFQ021024; Fri, 3 Jun 2005 13:31:55 -0500 Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j53IVtva012319; Fri, 3 Jun 2005 12:31:55 -0600 Received: from [192.168.1.105] (dhcp-amer-csvpn-gw2-141-144-72-8.vpn.oracle.com [141.144.72.8]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j53IVsvT012259; Fri, 3 Jun 2005 12:31:54 -0600 Message-ID: <42A0A21B.5010208@oracle.com> Date: Fri, 03 Jun 2005 11:31:55 -0700 From: Eric Sedlar User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: bart.w3.org 1DeGxe-0001yX-4Z ed5533e35f97338ee586a8e93e2928af X-Original-To: w3c-dist-auth@w3.org Subject: Re: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/42A0A21B.5010208@oracle.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9650 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Jun 2005 18:32:05 +0000 Content-Transfer-Encoding: 7bit We'd certainly like to see the WG complete the specs it has been working on. We are planning on implementing other DAV specs in our next database release. Quota and BIND are certainly very nice to standardize as well. Thanks, Eric Sedlar Architect XML Database / Server Technologies Oracle Corporation Ted Hardie wrote: > > Howdy, > I've gotten a very small number of comments back > to this either on-list or in private; if you have a comment, > even a short "My level of interest is ....", I would appreciate > your taking the time to send it. > thanks, > Ted > > > At 1:12 PM -0700 5/27/05, Ted Hardie wrote: > >> Several folks have asked where the discussion of the updated >> role of the WG Chair is documented. This is an output of the >> PROTO team in the General area, and it is documented in >> http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt. >> >> >> Though this is not yet an RFC, the IESG agreed to work using >> these rules on an interim basis in February, and Scott Hollenbeck >> announced that the APPs area would be using it at the most >> recent Minneapolis IETF. As most of you know, I was not at >> the meeting because of family commitments, but he did so >> with my full agreement. >> >> Though this updates the methodologies by which a working group >> chair and AD split the work of shepherding, it in some ways >> codifies the way good working groups have always worked--active >> working group chairs have always been involved in assuring that >> adequate review inside and outside the working group has been >> completed, that issues raised in Last Call or in IESG deliberation >> are handled, and so. It has also long been the case that the >> IESG's reading of RFC 2418 on the role of the WG chair has seen >> a Working Group chair as responsible for assuring the community >> that a document put forward to meet a working group milestone >> is appropriate to the task (see Section 6.1). Chairs can do that >> in multiple ways, but their own technical judgement is always >> expected to form a part of that assessment. It is entirely appropriate >> for a chair to state a technical problem with a spec and expect >> the working group and editors to either resolve the problem or >> document why the problem isn't an issue (usually in the spec). >> >> In cases where the working group chair has to call whether or not >> there is working group consensus on a particular resolution to >> a technical issue raised in this way, we can run into problems. >> The usual way of doing that is to have at least two chairs, so that >> one can handle the process call for technical issues raised by >> the other. That strategy has been in place for this group since >> I came on as AD, though I have to say a series of time commitment >> issues has made it very hard to implement: Jim had very few cycles >> at the time he stepped down; Patrik had to withdraw very shortly >> after agreeing to take the role; Joe has had issues with his >> organization >> supporting the time required. Joe attempted to augment the usual >> mechanism by implementing a ticketing system, but those using >> it seem to have plural opinions even on what it takes to close a ticket >> so that it takes more, rather than less, effort to use it effectively. >> >> The forward progress in the face of that strategy's failure has not >> been great. >> At this point, I want to reiterate that Lisa's actions as Chair have >> been >> both within my expectations as the AD for the group and that they have >> had my support; we have discussed the working group's progress >> on many occasions and the actions she and her co-chairs have taken >> have had gone forward with my knowledge and consent. >> She would be the first, I believe, to agree we have a problem in making >> forward progress. She's also had the brunt of trying to resolve it, >> and I thank her for her efforts. >> >> The question I have now is how to make that progress >> when the existing strategy has failed multiple times. We can change >> chairs, of course, and this might help clarify the process role vs. >> the contributor roles. I am concerned, though, that is will not >> be enough given the very small size of the working group's active >> membership. Judging rough consensus on a technical topic among >> only a few people when even one disagrees is tricky; if you solve >> that problem by ensuring that the chair has sufficient technical >> depth in the subject to adjudicate, you are back exactly where we >> are now. >> >> We can decide that the problem of size does not admit of solution, >> and we can shut down the working group. This leaves a lot of >> WebDav's published specs augmented by unpublished "lore" that >> is needed to get things done. I'm not thrilled by that, but if >> there is no way to get further, we may have to do it. I will >> be very reluctant to accept individual submissions for the >> standards track on WebDav core issues if we go this route, >> since that forces the IESG to resolve issues the WG could >> not. It might happen, but it would take work on the >> part of the proposers that is probably easier to accomplish >> in a working group setting. >> >> We can also try to radically limit what the working group is trying >> to accomplish and set out a firm deadline, after which the working >> group MUST shut down. This helps focus energy and may encourage >> folks who cannot commit to long term energy to commit to the short >> term working group program. If we go this route, I strongly suggest >> the working group consider a very draconian approach to reaching >> compromise. One example I have seen outside the IETF that worked >> was to say that if an issue could not be resolved within a set period >> of time, the whole document involved sank to the bottom of the >> WG's agenda--so everyone is clear that the failure to compromise >> may mean that the document does not get out at all. This >> requires a great deal of discipline and forces everyone to ask >> a new question ("Is this issue big enough that the document should >> not go forward at all if it is not fixed"). It can, however, work to >> get out the documents for which the WG is close to consensus >> and to focus work on others. >> >> I'd like to see the working group discuss these or other future paths. >> I do remind folks to remain professional in their discussion and >> that ad hominem comments are not tolerated; please think constructively >> about what *you* can do to move us forward and especially about >> what commitments *you* can take on. >> regards, >> Ted Hardie >> as Area Advisor. > > > From w3c-dist-auth-request@frink.w3.org Fri Jun 3 14:52: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 OAA22524 for ; Fri, 3 Jun 2005 14:52:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DeHGX-0007eE-MG for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Jun 2005 18:51:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DeHGS-0007dK-Jp; Fri, 03 Jun 2005 18:51:28 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by bart.w3.org with esmtp (Exim 4.50) id 1DeHGR-0004iS-TC; Fri, 03 Jun 2005 18:51:28 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j53IpRgM010762; Fri, 3 Jun 2005 14:51:27 -0400 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 j53IpROp235994; Fri, 3 Jun 2005 14:51:27 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j53IpR6k016184; Fri, 3 Jun 2005 14:51:27 -0400 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 j53IpRGh016178; Fri, 3 Jun 2005 14:51:27 -0400 In-Reply-To: <42A0A21B.5010208@oracle.com> To: Eric Sedlar Cc: Ted Hardie , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 3 Jun 2005 14:51:33 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/03/2005 14:51:27, Serialize complete at 06/03/2005 14:51:27 Content-Type: multipart/alternative; boundary="=_alternative 0067971D85257015_=" X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: bart.w3.org 1DeHGR-0004iS-TC ea7e6e7f8642cad83979012607b72c9c X-Original-To: w3c-dist-auth@w3.org Subject: Re: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/OFC5B28217.D42D04B3-ON85257015.00673612-85257015.00679722@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9651 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Jun 2005 18:51:33 +0000 This is a multipart message in MIME format. --=_alternative 0067971D85257015_= Content-Type: text/plain; charset="US-ASCII" I agree with Eric. We are adding WebDAV access to a variety of our repositories, and plan on using the BIND protocol. We also are eager to see the locking protocol officially cleaned up. Cheers, Geoff Eric wrote on 06/03/2005 02:31:55 PM: > > We'd certainly like to see the WG complete the specs it has been working > on. We are > planning on implementing other DAV specs in our next database release. > Quota and BIND > are certainly very nice to standardize as well. > > Thanks, > > Eric Sedlar > Architect > XML Database / Server Technologies > Oracle Corporation > > > Ted Hardie wrote: > > > > > Howdy, > > I've gotten a very small number of comments back > > to this either on-list or in private; if you have a comment, > > even a short "My level of interest is ....", I would appreciate > > your taking the time to send it. > > thanks, > > Ted > > > > > > At 1:12 PM -0700 5/27/05, Ted Hardie wrote: > > > >> Several folks have asked where the discussion of the updated > >> role of the WG Chair is documented. This is an output of the > >> PROTO team in the General area, and it is documented in > >> http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc- > shepherding-05.txt. > >> > >> > >> Though this is not yet an RFC, the IESG agreed to work using > >> these rules on an interim basis in February, and Scott Hollenbeck > >> announced that the APPs area would be using it at the most > >> recent Minneapolis IETF. As most of you know, I was not at > >> the meeting because of family commitments, but he did so > >> with my full agreement. > >> > >> Though this updates the methodologies by which a working group > >> chair and AD split the work of shepherding, it in some ways > >> codifies the way good working groups have always worked--active > >> working group chairs have always been involved in assuring that > >> adequate review inside and outside the working group has been > >> completed, that issues raised in Last Call or in IESG deliberation > >> are handled, and so. It has also long been the case that the > >> IESG's reading of RFC 2418 on the role of the WG chair has seen > >> a Working Group chair as responsible for assuring the community > >> that a document put forward to meet a working group milestone > >> is appropriate to the task (see Section 6.1). Chairs can do that > >> in multiple ways, but their own technical judgement is always > >> expected to form a part of that assessment. It is entirely appropriate > >> for a chair to state a technical problem with a spec and expect > >> the working group and editors to either resolve the problem or > >> document why the problem isn't an issue (usually in the spec). > >> > >> In cases where the working group chair has to call whether or not > >> there is working group consensus on a particular resolution to > >> a technical issue raised in this way, we can run into problems. > >> The usual way of doing that is to have at least two chairs, so that > >> one can handle the process call for technical issues raised by > >> the other. That strategy has been in place for this group since > >> I came on as AD, though I have to say a series of time commitment > >> issues has made it very hard to implement: Jim had very few cycles > >> at the time he stepped down; Patrik had to withdraw very shortly > >> after agreeing to take the role; Joe has had issues with his > >> organization > >> supporting the time required. Joe attempted to augment the usual > >> mechanism by implementing a ticketing system, but those using > >> it seem to have plural opinions even on what it takes to close a ticket > >> so that it takes more, rather than less, effort to use it effectively. > >> > >> The forward progress in the face of that strategy's failure has not > >> been great. > >> At this point, I want to reiterate that Lisa's actions as Chair have > >> been > >> both within my expectations as the AD for the group and that they have > >> had my support; we have discussed the working group's progress > >> on many occasions and the actions she and her co-chairs have taken > >> have had gone forward with my knowledge and consent. > >> She would be the first, I believe, to agree we have a problem in making > >> forward progress. She's also had the brunt of trying to resolve it, > >> and I thank her for her efforts. > >> > >> The question I have now is how to make that progress > >> when the existing strategy has failed multiple times. We can change > >> chairs, of course, and this might help clarify the process role vs. > >> the contributor roles. I am concerned, though, that is will not > >> be enough given the very small size of the working group's active > >> membership. Judging rough consensus on a technical topic among > >> only a few people when even one disagrees is tricky; if you solve > >> that problem by ensuring that the chair has sufficient technical > >> depth in the subject to adjudicate, you are back exactly where we > >> are now. > >> > >> We can decide that the problem of size does not admit of solution, > >> and we can shut down the working group. This leaves a lot of > >> WebDav's published specs augmented by unpublished "lore" that > >> is needed to get things done. I'm not thrilled by that, but if > >> there is no way to get further, we may have to do it. I will > >> be very reluctant to accept individual submissions for the > >> standards track on WebDav core issues if we go this route, > >> since that forces the IESG to resolve issues the WG could > >> not. It might happen, but it would take work on the > >> part of the proposers that is probably easier to accomplish > >> in a working group setting. > >> > >> We can also try to radically limit what the working group is trying > >> to accomplish and set out a firm deadline, after which the working > >> group MUST shut down. This helps focus energy and may encourage > >> folks who cannot commit to long term energy to commit to the short > >> term working group program. If we go this route, I strongly suggest > >> the working group consider a very draconian approach to reaching > >> compromise. One example I have seen outside the IETF that worked > >> was to say that if an issue could not be resolved within a set period > >> of time, the whole document involved sank to the bottom of the > >> WG's agenda--so everyone is clear that the failure to compromise > >> may mean that the document does not get out at all. This > >> requires a great deal of discipline and forces everyone to ask > >> a new question ("Is this issue big enough that the document should > >> not go forward at all if it is not fixed"). It can, however, work to > >> get out the documents for which the WG is close to consensus > >> and to focus work on others. > >> > >> I'd like to see the working group discuss these or other future paths. > >> I do remind folks to remain professional in their discussion and > >> that ad hominem comments are not tolerated; please think constructively > >> about what *you* can do to move us forward and especially about > >> what commitments *you* can take on. > >> regards, > >> Ted Hardie > >> as Area Advisor. > > > > > > > > --=_alternative 0067971D85257015_= Content-Type: text/html; charset="US-ASCII"
I agree with Eric.  We are adding WebDAV access to a variety of our repositories, and plan on using the BIND protocol.  We also are eager to see the locking protocol officially cleaned up.

Cheers,
Geoff

Eric wrote on 06/03/2005 02:31:55 PM:

>
> We'd certainly like to see the WG complete the specs it has been working
> on.  We are
> planning on implementing other DAV specs in our next database release.  
> Quota and BIND
> are certainly very nice to standardize as well.
>
> Thanks,
>
>   Eric Sedlar
>   Architect
>   XML Database / Server Technologies
>   Oracle Corporation
>
>
> Ted Hardie wrote:
>
> >
> > Howdy,
> >     I've gotten a very small number of comments back
> > to this either on-list or in private; if you have a comment,
> > even a short "My level of interest is ....", I would appreciate
> > your taking the time to send it.
> >             thanks,
> >                 Ted
> >
> >
> > At 1:12 PM -0700 5/27/05, Ted Hardie wrote:
> >
> >> Several folks have asked where the discussion of the updated
> >> role of the WG Chair is documented.  This is an output of the
> >> PROTO team in the General area, and it is documented in
> >> http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-
> shepherding-05.txt.
> >>
> >>
> >> Though this is not yet an RFC, the IESG agreed to work using
> >> these rules on an interim basis in February, and Scott Hollenbeck
> >> announced that the APPs area would be using it at the most
> >> recent Minneapolis IETF.  As most of you know, I was not at
> >> the meeting because of family commitments, but he did so
> >> with my full agreement.
> >>
> >> Though this updates the methodologies by which a working group
> >> chair and AD split the work of shepherding, it in some ways
> >> codifies the way good working groups have always worked--active
> >> working group chairs have always been involved in assuring that
> >> adequate review inside and outside the working group has been
> >> completed, that issues raised in Last Call or in IESG deliberation
> >> are handled, and so.  It has also long been the case that the
> >> IESG's reading of RFC 2418 on the role of the WG chair has seen
> >> a Working Group chair as responsible for assuring the community
> >> that a document put forward to meet a working group milestone
> >> is appropriate to the task (see Section 6.1).  Chairs can do that
> >> in multiple ways, but their own technical judgement is always
> >> expected to form a part of that assessment.  It is entirely appropriate
> >> for a chair to state a technical problem  with a spec and expect
> >> the working group and editors to either resolve the problem or
> >> document why the problem isn't an issue (usually in the spec).
> >>
> >> In cases where the working group chair has to call whether or not
> >> there is working group consensus on a particular resolution to
> >> a technical issue raised in this way, we can run into problems.
> >> The usual way of doing that is to have at least two chairs, so that
> >> one can handle the process call for technical issues raised by
> >> the other.   That strategy has been in place for this group since
> >> I came on as AD, though I have to say a series of time commitment
> >> issues has made it very hard to implement:  Jim had very few cycles
> >> at the time he stepped down; Patrik had to withdraw very shortly
> >> after agreeing to take the role; Joe has had issues with his
> >> organization
> >> supporting the time required.  Joe attempted to augment the usual
> >> mechanism by implementing a ticketing system, but those using
> >> it seem to have plural opinions even on what it takes to close a ticket
> >> so that it takes more, rather than less, effort to use it effectively.
> >>
> >> The forward progress in the face of that strategy's failure has not
> >> been great.
> >> At this point, I want to reiterate that Lisa's actions as Chair have
> >> been
> >> both within my expectations as the AD for the group and that they have
> >> had my support; we have discussed the working group's progress
> >> on many occasions and the actions she and her co-chairs have taken
> >> have had gone forward with my knowledge and consent.
> >> She would be the first, I believe, to agree we have a problem in making
> >> forward progress.  She's also had the brunt of trying to resolve it,
> >> and I thank her for her efforts.
> >>
> >> The question I have now is how to make that progress
> >> when the existing strategy has failed multiple times.  We can change
> >> chairs, of course, and this might help clarify the process role vs.
> >> the contributor roles.  I am concerned, though, that is will not
> >> be enough given the very small size of the working group's active
> >> membership.  Judging rough consensus on a technical topic among
> >> only a few people when even one disagrees is tricky; if you solve
> >> that problem by ensuring that the chair has sufficient technical
> >> depth in the subject to adjudicate, you are back exactly where we
> >> are now.
> >>
> >> We can decide that the problem of size does not admit of solution,
> >> and we can shut down the working group.  This leaves a lot of
> >> WebDav's published specs augmented by unpublished "lore" that
> >> is needed to get things done.   I'm not thrilled by that, but if
> >> there is no way to get further, we may have to do it.  I will
> >> be very reluctant to accept individual submissions for the
> >> standards track on WebDav core issues if we go this route,
> >> since that forces the IESG to resolve issues the WG could
> >> not.  It might happen, but it would take work on the
> >> part of the proposers that is probably easier to accomplish
> >> in a working group setting.
> >>
> >> We can also try to radically limit what the working group is trying
> >> to accomplish and set out a firm deadline, after which the working
> >> group MUST shut down.  This helps focus energy and may encourage
> >> folks who cannot commit to long term energy to commit to the short
> >> term working group program.  If we go this route, I strongly suggest
> >> the working group consider a very draconian approach to reaching
> >> compromise.  One example I have seen outside the IETF that worked
> >> was to say that if an issue could not be resolved within a set period
> >> of time, the whole document involved sank to the bottom of the
> >> WG's agenda--so everyone is clear that the failure to compromise
> >> may mean that the document does not get out at all.  This
> >> requires a great deal of discipline and forces everyone to ask
> >> a new question ("Is this issue big enough that the document should
> >> not go forward at all if it is not fixed").  It can, however, work to
> >> get out the documents for which the WG is close to consensus
> >> and to focus work on others.
> >>
> >> I'd like to see the working group discuss these or other future paths.
> >> I do remind folks to remain professional in their discussion and
> >> that ad hominem comments are not tolerated; please think constructively
> >> about what *you* can do to move us forward and especially about
> >> what commitments *you* can take on.
> >>             regards,
> >>                 Ted Hardie
> >>                 as Area Advisor.
> >
> >
> >
>
>
--=_alternative 0067971D85257015_=-- From w3c-dist-auth-request@frink.w3.org Fri Jun 3 17:18: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 RAA15445 for ; Fri, 3 Jun 2005 17:18:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DeJX1-0002iI-NH for w3c-dist-auth-dist@listhub.w3.org; Fri, 03 Jun 2005 21:16:43 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DeJWw-0002hF-PS for w3c-dist-auth@listhub.w3.org; Fri, 03 Jun 2005 21:16:38 +0000 Received: from mail-out3.apple.com ([17.254.13.22]) by bart.w3.org with esmtp (Exim 4.50) id 1DeJWu-0006pN-2L for w3c-dist-auth@w3.org; Fri, 03 Jun 2005 21:16:38 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j53LGZ2O029672 for ; Fri, 3 Jun 2005 14:16:35 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 3 Jun 2005 14:16:34 -0700 Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j53LGWQr025094; Fri, 3 Jun 2005 14:16:33 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit From: Jim Luther Date: Fri, 3 Jun 2005 14:16:31 -0700 To: Ted Hardie X-Mailer: Apple Mail (2.728) X-W3C-Hub-Spam-Status: No, score=-0.0 X-W3C-Scan-Sig: bart.w3.org 1DeJWu-0006pN-2L 59f69d14e20378e9f65d77fc9294e2ef X-Original-To: w3c-dist-auth@w3.org Subject: Re: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/E43129B3-6DB5-4F76-9EBC-92B4C378C8BF@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9652 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 03 Jun 2005 21:16:43 +0000 Content-Transfer-Encoding: 7bit We already have a variant of Quota implemented in .Mac iDisk server and the Mac OS X WebDAV file system and plan to conform to the real Quota spec. BIND would allow us to implement hard links in our WebDAV file system, but that's not really that useful. More useful would be support for Redirect resources which would look like symlinks to file system clients. We've been asked to support symlinks in the WebDAV file system many times. The only other HTTP extension method we are interested in is PATCH (which was discussed on the HTTP mailing list for a while) because the lack of a way to modify part of a resource is a big performance problem for a WebDAV file system. Jim Luther Apple On Jun 3, 2005, at 11:24 AM, Ted Hardie wrote: > > Howdy, > I've gotten a very small number of comments back > to this either on-list or in private; if you have a comment, > even a short "My level of interest is ....", I would appreciate > your taking the time to send it. > thanks, > Ted > > > At 1:12 PM -0700 5/27/05, Ted Hardie wrote: > >> Several folks have asked where the discussion of the updated >> role of the WG Chair is documented. This is an output of the >> PROTO team in the General area, and it is documented in >> http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc- >> shepherding-05.txt. >> >> Though this is not yet an RFC, the IESG agreed to work using >> these rules on an interim basis in February, and Scott Hollenbeck >> announced that the APPs area would be using it at the most >> recent Minneapolis IETF. As most of you know, I was not at >> the meeting because of family commitments, but he did so >> with my full agreement. >> >> Though this updates the methodologies by which a working group >> chair and AD split the work of shepherding, it in some ways >> codifies the way good working groups have always worked--active >> working group chairs have always been involved in assuring that >> adequate review inside and outside the working group has been >> completed, that issues raised in Last Call or in IESG deliberation >> are handled, and so. It has also long been the case that the >> IESG's reading of RFC 2418 on the role of the WG chair has seen >> a Working Group chair as responsible for assuring the community >> that a document put forward to meet a working group milestone >> is appropriate to the task (see Section 6.1). Chairs can do that >> in multiple ways, but their own technical judgement is always >> expected to form a part of that assessment. It is entirely >> appropriate >> for a chair to state a technical problem with a spec and expect >> the working group and editors to either resolve the problem or >> document why the problem isn't an issue (usually in the spec). >> >> In cases where the working group chair has to call whether or not >> there is working group consensus on a particular resolution to >> a technical issue raised in this way, we can run into problems. >> The usual way of doing that is to have at least two chairs, so that >> one can handle the process call for technical issues raised by >> the other. That strategy has been in place for this group since >> I came on as AD, though I have to say a series of time commitment >> issues has made it very hard to implement: Jim had very few cycles >> at the time he stepped down; Patrik had to withdraw very shortly >> after agreeing to take the role; Joe has had issues with his >> organization >> supporting the time required. Joe attempted to augment the usual >> mechanism by implementing a ticketing system, but those using >> it seem to have plural opinions even on what it takes to close a >> ticket >> so that it takes more, rather than less, effort to use it >> effectively. >> >> The forward progress in the face of that strategy's failure has >> not been great. >> At this point, I want to reiterate that Lisa's actions as Chair >> have been >> both within my expectations as the AD for the group and that they >> have >> had my support; we have discussed the working group's progress >> on many occasions and the actions she and her co-chairs have taken >> have had gone forward with my knowledge and consent. >> She would be the first, I believe, to agree we have a problem in >> making >> forward progress. She's also had the brunt of trying to resolve it, >> and I thank her for her efforts. >> >> The question I have now is how to make that progress >> when the existing strategy has failed multiple times. We can change >> chairs, of course, and this might help clarify the process role vs. >> the contributor roles. I am concerned, though, that is will not >> be enough given the very small size of the working group's active >> membership. Judging rough consensus on a technical topic among >> only a few people when even one disagrees is tricky; if you solve >> that problem by ensuring that the chair has sufficient technical >> depth in the subject to adjudicate, you are back exactly where we >> are now. >> >> We can decide that the problem of size does not admit of solution, >> and we can shut down the working group. This leaves a lot of >> WebDav's published specs augmented by unpublished "lore" that >> is needed to get things done. I'm not thrilled by that, but if >> there is no way to get further, we may have to do it. I will >> be very reluctant to accept individual submissions for the >> standards track on WebDav core issues if we go this route, >> since that forces the IESG to resolve issues the WG could >> not. It might happen, but it would take work on the >> part of the proposers that is probably easier to accomplish >> in a working group setting. >> >> We can also try to radically limit what the working group is trying >> to accomplish and set out a firm deadline, after which the working >> group MUST shut down. This helps focus energy and may encourage >> folks who cannot commit to long term energy to commit to the short >> term working group program. If we go this route, I strongly suggest >> the working group consider a very draconian approach to reaching >> compromise. One example I have seen outside the IETF that worked >> was to say that if an issue could not be resolved within a set period >> of time, the whole document involved sank to the bottom of the >> WG's agenda--so everyone is clear that the failure to compromise >> may mean that the document does not get out at all. This >> requires a great deal of discipline and forces everyone to ask >> a new question ("Is this issue big enough that the document should >> not go forward at all if it is not fixed"). It can, however, work to >> get out the documents for which the WG is close to consensus >> and to focus work on others. >> >> I'd like to see the working group discuss these or other future >> paths. >> I do remind folks to remain professional in their discussion and >> that ad hominem comments are not tolerated; please think >> constructively >> about what *you* can do to move us forward and especially about >> what commitments *you* can take on. >> regards, >> Ted Hardie >> as Area Advisor. >> > > > From w3c-dist-auth-request@frink.w3.org Mon Jun 6 20:24:18 2005 Received: from frink.w3.org ([128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07779 for ; Mon, 6 Jun 2005 20:24:18 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DfRp6-0002DT-Lb for w3c-dist-auth-dist@listhub.w3.org; Tue, 07 Jun 2005 00:20:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DfRp2-0001qY-EC for w3c-dist-auth@listhub.w3.org; Tue, 07 Jun 2005 00:20:00 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.50) id 1DfRp1-00062J-UO for w3c-dist-auth@w3.org; Tue, 07 Jun 2005 00:20:00 +0000 Received: from tycho (dhcp-59-204.cse.ucsc.edu [128.114.59.204]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j570Jwgt026007 for ; Mon, 6 Jun 2005 17:19:58 -0700 (PDT) Message-Id: <200506070019.j570Jwgt026007@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: Date: Mon, 6 Jun 2005 17:19:34 -0700 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: AcVoad0WSMJz2yWhSyaNvfQYMhsXVgCi4FAw X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: bart.w3.org 1DfRp1-00062J-UO 8083a8f0837ec3da5f819993ba12a1c9 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/200506070019.j570Jwgt026007@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9653 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 07 Jun 2005 00:20:04 +0000 Content-Transfer-Encoding: 7bit My recommendation for a future direction for the working group is: * Move Bind and Quota to the IESG for consideration as Proposed Standards by July 15. These specs. are essentially complete right now. * Work on completing 2518bis by December 31. Plan on shipping whatever version of 2518bis exists as of early January, 2006. Issues that are important, and pain-causing, will be addressed by then. Those that aren't as important may or may not, depending on the willingness of the WG to address them. - An important aspect of finishing 2518bis is adopting a process for considering and resolving issues in a priority ordered and timely fashion. * If work on 2518bis is going well, complete Redirect. Otherwise, encourage work as an individual submission. * Have the chairs be active in communicating current goals and progress to the working group. * In any event, have the WG close in early January 2006. Nine and a half years is really enough :-) I am willing and able to actively contribute to this effort in whatever way is most helpful to the WG. - Jim From w3c-dist-auth-request@frink.w3.org Mon Jun 13 10:56:05 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 KAA19615 for ; Mon, 13 Jun 2005 10:56:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DhqJf-0004CT-Vu for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 14:53:31 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DhqJZ-0004BJ-RM for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 14:53:25 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by bart.w3.org with esmtp (Exim 4.50) id 1DhqJW-0004BB-Rz for w3c-dist-auth@w3c.org; Mon, 13 Jun 2005 14:53:25 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id B9C43142264 for ; Mon, 13 Jun 2005 07:50:51 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31977-07 for ; Mon, 13 Jun 2005 07:50:51 -0700 (PDT) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id EFE75142262 for ; Mon, 13 Jun 2005 07:50:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <5d5341ae26a9488d7c24bcf7175a57b8@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Webdav WG From: Lisa Dusseault Date: Mon, 13 Jun 2005 07:53:19 -0700 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1DhqJW-0004BB-Rz c6de8cfc1dcb420d7705524d8850ad36 X-Original-To: w3c-dist-auth@w3.org Subject: Stepping down X-Archived-At: http://www.w3.org/mid/5d5341ae26a9488d7c24bcf7175a57b8@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9654 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 14:53:31 +0000 Content-Transfer-Encoding: 7bit After four years as WebDAV WG chair, it's time for me to step down. My day job at OSAF involves much more of an emphasis on calendaring and messaging and doesn't leave time for me to be both chair and editor of RFC 2518bis. Luckily, Ted & I have managed to find a new chair and so I know that I'll be leaving the WG in good hands. I will however, be staying on as RFC 2518bis editor and I look forward to working with the rest of the group. Lisa From w3c-dist-auth-request@frink.w3.org Mon Jun 13 14:55: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 OAA09167 for ; Mon, 13 Jun 2005 14:55:25 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dhu3z-0002YG-Hg for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 18:53:35 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Dhtrx-0007Sl-KN for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 18:41:09 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by lisa.w3.org with esmtp (Exim 4.50) id 1Dhtru-0003KW-Kw for w3c-dist-auth@w3c.org; Mon, 13 Jun 2005 18:41:09 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DIf0CK026896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 11:41:01 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DIevt1008311; Mon, 13 Jun 2005 11:40:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 13 Jun 2005 11:40:56 -0700 To: w3c-dist-auth@w3c.org From: Ted Hardie Cc: Scott Hollenbeck Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1Dhtru-0003KW-Kw ab6023a833f07d19330d92fd6531e0df X-Original-To: w3c-dist-auth@w3.org Subject: New Chair and game plan. X-Archived-At: http://www.w3.org/mid/p06210203bed3833003b8@%5B129.46.227.161%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9655 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 18:53:35 +0000 Howdy, First off, I'd like to thank Lisa and Joe for their service as chairs of the working group. I very much appreciate the time and effort they've put in, and I'm glad that they'll be available as working group participants full time now. During the discussion of the working group's future, several folks active in the group volunteered to serve in various capacities; I'd like to thank them as well. At this point in its life cycle, my feeling is that the working group has a small enough number of active editors/reviewers/implementors, that it makes more sense to concentrate the active members on those roles. For the Chair role, I think the group needs someone who has a strong sense of how to manage the IETF process and how to gauge consensus within it, but whose technical role is limited to identifying areas in the specs where new readers might have difficulty following the intent. This is sometimes called a "process chair" or an "outside chair", but I think my own mental model is that of a baseball "closer"--a pitcher you bring in to handle a small number of outs near the end of the game. I've asked Cullen Jennings, who also serves as Chair for BEHAVE and IPTEL, to take on this role, and he's agreed. During the discussions with Cullen, one of the most important questions was how close to the end of the game we think we are. Here, I believe Jim Whitehead has said it best--the group has a small number of projects that can be completed in about a six month time frame. In order to make that more concrete, Cullen and I would like to set forth the following work plan: 0) The big deliverable is RFC 2518bis, and though this work plan contains other deliverables, they can be sacrificed to the independent-submission tracks to get 2518bis out. 1) Institute clean-slate new WG Last Calls on any drafts that have already been last called or are otherwise asserted to be done (BIND, QUOTA, REDIRECT). 2) Doc bugs in those get fixed immediately, along with any technical issues for which there is essentially immediate consensus. 3) If any big-picture issues arise or technical matters that cannot be resolved quickly, the doc for which the issue exists will go to the end of the working agenda. It will get further working group attention only when 2518bis is out of the WGs hands. 4) At the end of the WG Last Calls for these documents, the working group will go into a concentrated period of work on 2518bis. An issues list will be maintained by Cullen, who is responsible as Chair for calling consensus on when an issue has been resolved. The editors will be expected to make rapid changes in response to issues-list decisions. 5) The working group will probably not use face-to-face meetings during this period, but it may host jabber chats or conference calls for the working group or design/editing teams assigned to specific sections. Those must be minuted to the WG and decisions ratified through the normal process. The aim is to have the WG enter FIN_WAIT by January of 2006 by having all of its documents at or through IETF Last Call prior to that point. I believe that is possible, with concentration and effort on all of our parts. I hope you will join me both in welcoming Cullen to the team and in committing to the effort that this will require. regards, Ted Hardie From w3c-dist-auth-request@frink.w3.org Mon Jun 13 15:20: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 PAA12709 for ; Mon, 13 Jun 2005 15:20:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DhuTM-000168-Hm for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 19:19:48 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DhuHK-0005qx-TJ for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 19:07:22 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.50) id 1DhuHI-00044y-BX for w3c-dist-auth@w3c.org; Mon, 13 Jun 2005 19:07:22 +0000 Received: from tycho (dhcp-59-204.cse.ucsc.edu [128.114.59.204]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5DHFmsS015900; Mon, 13 Jun 2005 10:15:48 -0700 (PDT) Message-Id: <200506131715.j5DHFmsS015900@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Lisa Dusseault'" , "'Webdav WG'" Date: Mon, 13 Jun 2005 10:15:47 -0700 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: <5d5341ae26a9488d7c24bcf7175a57b8@osafoundation.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVwJ/qUTRzct/LFTcmAdlc6OSJt7gAEwJGQ X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: bart.w3.org 1DhuHI-00044y-BX 796c47d959ed0b0db7a21087bcb6abdf X-Original-To: w3c-dist-auth@w3.org Subject: RE: Stepping down X-Archived-At: http://www.w3.org/mid/200506131715.j5DHFmsS015900@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9656 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 19:19:48 +0000 Content-Transfer-Encoding: 7bit Lisa, I'd like to give you my very deep and sincere thanks for your service as WebDAV Working Group Chair. During your tenure, WebDAV WG has completed several specifications that have been worked on for many years. Through your work on the CalDAV specification, you have demonstrated technical leadership, and a vision for other uses of WebDAV. Thank you! - Jim > After four years as WebDAV WG chair, it's time for me to step > down. My day job at OSAF involves much more of an emphasis on > calendaring and messaging and doesn't leave time for me to be > both chair and editor of RFC 2518bis. Luckily, Ted & I have > managed to find a new chair and so I know that I'll be > leaving the WG in good hands. I will however, be staying on > as RFC 2518bis editor and I look forward to working with the > rest of the group. > > Lisa > From w3c-dist-auth-request@frink.w3.org Mon Jun 13 17:06: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 RAA06332 for ; Mon, 13 Jun 2005 17:06:56 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dhw7U-0001hM-Tf for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 21:05:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DhvvT-0006iD-5r for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 20:52:55 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1DhvvQ-0003Fe-Cv for w3c-dist-auth@w3c.org; Mon, 13 Jun 2005 20:52:55 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 13:52:24 -0700 X-IronPort-AV: i="3.93,195,1115017200"; d="scan'208"; a="278187348:sNHT6710452624" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5DKqKlw012572 for ; Mon, 13 Jun 2005 13:52:20 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 13:54:36 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 13:52:21 -0700 From: Cullen Jennings To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jun 2005 20:54:36.0790 (UTC) FILETIME=[1BEE5960:01C5705A] X-W3C-Hub-Spam-Status: No, score=-0.4 X-W3C-Scan-Sig: lisa.w3.org 1DhvvQ-0003Fe-Cv 372a84643106cf407d0a1208488e71f2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: New Chair and game plan. X-Archived-At: http://www.w3.org/mid/BED34015.3DB20%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9657 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 21:05:20 +0000 Content-Transfer-Encoding: 7bit Thanks for involving me in this and I'm happy to be helping get this work finished as I know there are people that want to use the standards we are defining. I understand how weird it is to have a chair that is not one of the leading technical experts on the subject but I believe I can help get the documents from where they are not to being RFCs. I'm sure no one on this list will be shy about helping me stay on the right path and I'm going to need the help. Email works, my mobile is +1 408 421 9990, IM is cullenfluffyjennings@jabber.org or I can provide IM addressed on any of the other common IM systems. Let me know what you can contribute to get these documents to RFC. Providing a careful read of the documents in the upcoming working group last calls and text on how to fix any issues is always appreciated. Thanks, Cullen On 6/13/05 11:40 AM, "Ted Hardie" wrote: > > Howdy, > > First off, I'd like to thank Lisa and Joe for their service as chairs of > the working group. I very much appreciate the time and effort they've > put in, and I'm glad that they'll be available as working group participants > full time now. > > During the discussion of the working group's future, several folks active > in the group volunteered to serve in various capacities; I'd like to thank > them as well. At this point in its life cycle, my feeling is that the working > group has a small enough number of active editors/reviewers/implementors, > that it makes more sense to concentrate the active members on > those roles. For the Chair role, I think the group needs someone who > has a strong sense of how to manage the IETF process and how to gauge > consensus within it, but whose technical role is limited to identifying areas > in the specs where new readers might have difficulty following the > intent. This is > sometimes called a "process chair" or an "outside chair", but I think my > own mental model is that of a baseball "closer"--a pitcher you bring in > to handle a small number of outs near the end of the game. I've > asked Cullen Jennings, who also serves as Chair for BEHAVE and IPTEL, > to take on this role, and he's agreed. > > During the discussions with Cullen, one of the most important questions was > how close to the end of the game we think we are. Here, I believe Jim > Whitehead has said it best--the group has a small number of projects that > can be completed in about a six month time frame. In order to make that > more concrete, Cullen and I would like to set forth the following work > plan: > > 0) The big deliverable is RFC 2518bis, and though this work plan contains > other deliverables, they can be sacrificed to the independent-submission > tracks to get 2518bis out. > > 1) Institute clean-slate new WG Last Calls on any drafts that have already > been > last called or are otherwise asserted to be done (BIND, QUOTA, REDIRECT). > > 2) Doc bugs in those get fixed immediately, along with any technical > issues for which > there is essentially immediate consensus. > > 3) If any big-picture issues arise or technical matters that cannot be > resolved > quickly, the doc for which the issue exists will go to the end of the working > agenda. It will get further working group attention only when 2518bis is > out of the WGs hands. > > 4) At the end of the WG Last Calls for these documents, the working group will > go into a concentrated period of work on 2518bis. An issues list > will be maintained > by Cullen, who is responsible as Chair for calling consensus on when an issue > has been resolved. The editors will be expected to make rapid changes in > response to issues-list decisions. > > 5) The working group will probably not use face-to-face meetings during this > period, but it may host jabber chats or conference calls for the working group > or design/editing teams assigned to specific sections. Those must be minuted > to the WG and decisions ratified through the normal process. > > The aim is to have the WG enter FIN_WAIT by January of 2006 by having > all of its > documents at or through IETF Last Call prior to that point. I > believe that is possible, > with concentration and effort on all of our parts. I hope you will join me > both in welcoming Cullen to the team and in committing to the effort that > this will require. > regards, > Ted Hardie From w3c-dist-auth-request@frink.w3.org Mon Jun 13 18:23: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 SAA13429 for ; Mon, 13 Jun 2005 18:23:03 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DhxJQ-0002ze-Sw for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 22:21:44 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dhx7L-0006gk-VC for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 22:09:16 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by bart.w3.org with esmtp (Exim 4.50) id 1Dhx7J-0007tJ-EV for w3c-dist-auth@w3.org; Mon, 13 Jun 2005 22:09:15 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 15:08:14 -0700 X-IronPort-AV: i="3.93,196,1115017200"; d="scan'208"; a="278225571:sNHT3703210236" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5DM86lw004992 for ; Mon, 13 Jun 2005 15:08:06 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 15:10:26 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 15:08:10 -0700 From: Cullen Jennings To: WebDav Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jun 2005 22:10:26.0686 (UTC) FILETIME=[B3E161E0:01C57064] X-W3C-Hub-Spam-Status: No, score=-0.4 X-W3C-Scan-Sig: bart.w3.org 1Dhx7J-0007tJ-EV 2617e80fd8a6ea1a4c4f653fdecf0d59 X-Original-To: w3c-dist-auth@w3.org Subject: Upcoming WGLC for documents X-Archived-At: http://www.w3.org/mid/BED351DA.3DB69%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9658 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 22:21:44 +0000 Content-Transfer-Encoding: 7bit Very soon I expect to working group last call BIND, QUOTA, and REDIRECT. I realize there have been previous WGLC but I suspect that many documents and the thinking around them have evolved. It is very difficult to go back through the lists and figure out all the issuers that were ever open and what closed. I know some people may feel like this is extra work, but I think it will be valuable to get a fresh reread of the documents and a complete set of the open issues. I'm going to try and keep track of what the issues are and drive them all to consensus. This can be pretty confusing at times so there are some things that could really help me. Try to separate the comments into two groups of protocol issues and document issues. I think of protocol issues being something where the the document is incorrectly describing how the protocol actually works, or there is a problem with how the protocol works, or the document does not adequately specify how the protocol works. The second group are document issues like the explanation is hard to understand and may result in the incorrect implementations, a BNF does not compile or some XML does not validate against the schema, or there is a formatting problem or typo. It would also be nice to split the issues into big, small, and trivial. I think of big as things that are major issues and going to take time on the list to resolve. Trivial and nits and typos and stuff that is important to fix but really does not need any thought or discussion. Small is everything else :-) Comments along the lines this whole document is garbage are really hard to do anything with at this point in time. So instead of making these, either provide specific things that need fixing (ideally with proposed fixes), or just argue that the document should not be moved forward to an RFC. I can try to gage consensus about if we do or do not want to move a document forward, or if we do or do not want to replace some text with some alternative text. I can't do much with "this document is revolting". Keep separable issues as separate problems instead of mixing several semi-related things all into one large mess. If you do a careful review of the document and don't see anything that needs changing, drop a note to the list anyways just so we know that the document did get some review. Mostly I implore people to do there best to get all of their issues on the list during the WGLC - if the time for the WGLC is too short let me know sooner than later. It is really hard to complete documents if there is a never ending supply of new issues. Many thanks, Cullen From w3c-dist-auth-request@frink.w3.org Mon Jun 13 19:54: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 TAA22367 for ; Mon, 13 Jun 2005 19:54:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dhyjp-0004pF-I3 for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jun 2005 23:53:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DhyXn-0002Ky-Nh for w3c-dist-auth@listhub.w3.org; Mon, 13 Jun 2005 23:40:39 +0000 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.webb.net) by bart.w3.org with esmtp (Exim 4.50) id 1DhyXj-0003DG-4m for w3c-dist-auth@w3c.org; Mon, 13 Jun 2005 23:40:39 +0000 Received: from [127.0.0.1] (gatekeeper-int.jabber.com [10.101.0.11]) by ossex1.webb.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L3XYJ5YY; Mon, 13 Jun 2005 11:44:48 -0600 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 11:55:07 -0600 From: Joe Hildebrand To: Webdav WG , Ted Hardie Message-ID: In-Reply-To: <5d5341ae26a9488d7c24bcf7175a57b8@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: bart.w3.org 1DhyXj-0003DG-4m c24e48d1ad15dfa1dcd93bb8f9630391 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Stepping down X-Archived-At: http://www.w3.org/mid/BED3249B.1CAE%25jhildebrand@jabber.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9659 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 13 Jun 2005 23:53:05 +0000 Content-Transfer-Encoding: 7bit On a similar front, as you all have seen, the rigors of my day job have prevented me from spending as much time on this WG as I thought I would be able to when I became co-chair. Therefore, I'll be stepping down as well. Thanks to everyone for your patience. On 6/13/05 8:53 AM, "Lisa Dusseault" wrote: > > After four years as WebDAV WG chair, it's time for me to step down. My > day job at OSAF involves much more of an emphasis on calendaring and > messaging and doesn't leave time for me to be both chair and editor of > RFC 2518bis. Luckily, Ted & I have managed to find a new chair and > so I know that I'll be leaving the WG in good hands. I will however, be > staying on as RFC 2518bis editor and I look forward to working with > the rest of the group. > > Lisa > -- Joe Hildebrand From w3c-dist-auth-request@frink.w3.org Mon Jun 13 21:01: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 VAA26891 for ; Mon, 13 Jun 2005 21:01:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dhzmo-0001RH-KV for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 01:00:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Dhzml-0001QF-1W for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 01:00:11 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1Dhzmj-000290-2W for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 01:00:13 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2005 17:59:34 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5E0xWlq024111; Mon, 13 Jun 2005 17:59:32 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 18:01:46 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 17:59:30 -0700 From: Cullen Jennings To: WebDav CC: Brian Korver , Lisa Dusseault Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 01:01:46.0802 (UTC) FILETIME=[A34E9920:01C5707C] X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: maggie.w3.org 1Dhzmj-000290-2W eafd1ac25d114a68768b6ffc0e8e1153 X-Original-To: w3c-dist-auth@w3.org Subject: WGLC draft-ietf-webdav-quota-07 X-Archived-At: http://www.w3.org/mid/BED37A02.3DBF9%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9660 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 01:00:14 +0000 Content-Transfer-Encoding: 7bit I would like to start working group last call http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt This WGCL will end on June 27th so please have your comments emailed to this list before then. Thank you, Cullen From w3c-dist-auth-request@frink.w3.org Mon Jun 13 21:02: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 VAA26910 for ; Mon, 13 Jun 2005 21:02:09 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DhzoA-0001Z3-GA for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 01:01:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Dhzo6-0001YS-BB for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 01:01:34 +0000 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by maggie.w3.org with esmtp (Exim 4.50) id 1Dhzo4-0002H8-9V for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 01:01:36 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2005 18:01:19 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5E119lu025835; Mon, 13 Jun 2005 18:01:16 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 18:03:29 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 18:01:13 -0700 From: Cullen Jennings To: WebDav CC: Jim Whitehead , Geoffrey M Clemm , Julian Reschke Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 01:03:29.0318 (UTC) FILETIME=[E0694C60:01C5707C] X-W3C-Hub-Spam-Status: No, score=0.2 X-W3C-Scan-Sig: maggie.w3.org 1Dhzo4-0002H8-9V d412bed0a8a1fc1541e9fecf6ebf16af X-Original-To: w3c-dist-auth@w3.org Subject: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/BED37A69.3DBFA%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9661 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 01:01:38 +0000 Content-Transfer-Encoding: 7bit I would like to start working group last call http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-1 2.txt This WGCL will end on July 4th so please have your comments emailed to this list before then. Thank you, Cullen From w3c-dist-auth-request@frink.w3.org Mon Jun 13 21:03: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 VAA26976 for ; Mon, 13 Jun 2005 21:03:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dhzpc-0001um-68 for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 01:03:08 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DhzpY-0001tB-UC for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 01:03:04 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1DhzpW-0004Ki-Am for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 01:03:04 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 18:03:00 -0700 X-IronPort-AV: i="3.93,196,1115017200"; d="scan'208"; a="278294270:sNHT28073584" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5E12rbw025757; Mon, 13 Jun 2005 18:02:53 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 18:05:12 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 18:02:56 -0700 From: Cullen Jennings To: WebDav CC: Geoffrey M Clemm , Julian Reschke , Jim Whitehead , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 01:05:12.0084 (UTC) FILETIME=[1DAA2540:01C5707D] X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: lisa.w3.org 1DhzpW-0004Ki-Am c007ef7b88cd43c1e0996ae9860b5543 X-Original-To: w3c-dist-auth@w3.org Subject: WGLC draft-ietf-webdav-bind-11 X-Archived-At: http://www.w3.org/mid/BED37AD0.3DBFA%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9662 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 01:03:08 +0000 Content-Transfer-Encoding: 7bit I would like to start working group last call on http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-11.txt This WGCL will end on July 4th so please have your comments emailed to this list before then. Thank you, Cullen From w3c-dist-auth-request@frink.w3.org Mon Jun 13 22:09:05 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 WAA01105 for ; Mon, 13 Jun 2005 22:09:04 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di0pu-0006vm-4j for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 02:07:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Di0po-0006v8-Te for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 02:07:24 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by lisa.w3.org with esmtp (Exim 4.50) id 1Di0pm-0002vf-5x for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 02:07:24 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 1904A142258; Mon, 13 Jun 2005 19:04:47 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07823-03; Mon, 13 Jun 2005 19:04:46 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id F0004142256; Mon, 13 Jun 2005 19:04:45 -0700 (PDT) Message-ID: <42AE3BD6.6090908@osafoundation.org> Date: Mon, 13 Jun 2005 19:07:18 -0700 From: Lisa Dusseault User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Cc: WebDav , Jim Whitehead , Geoffrey M Clemm , Julian Reschke References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: lisa.w3.org 1Di0pm-0002vf-5x 6baf627ae39e915364dd3b0e4ebe77f6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AE3BD6.6090908@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9663 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 02:07:30 +0000 Content-Transfer-Encoding: 7bit The main flaw in the REDIRECT proposal is that there is not enough in the way of plans to implement it. Without a set of independent implementors around to review it, I fear it's too complex or has missed key interoperability issues. To be clear, I do understand that the Web needs and uses redirects, and I see that administrators do create them and that browsers follow redirect status codes. I'm arguing that there isn't a clear need for interoperable authoring of redirect resources, or if there is, it's not met by this specification. Implementors might tell us, for example, that they don't need the ability to modify a redirect (why not just recreate) or that they'd prefer something which could handle redirecting URLs via pattern matching to another set of calculated URLs. There seems to be one organization that implements REDIRECT authoring in a potentially-interoperable way -- I believe that's Julian's organization. I think that's great, and even better that they're interested in publishing the way they do it so that others can do the same. I just don't believe that meets the bar for a standards-track RFC, because we've learned in the IETF that actual implementor review is very important to writing good, clear, simple standards that people need. OSAF-specific stuff: We do not have plans to implement redirect in Cosmo or Chandler (server or client), neither to create redirects, allow them to be created, or add logic to allow for redirects existing on other WebDAV servers. We're more interested, potentially, in using bindings. Lisa Cullen Jennings wrote: >I would like to start working group last call > >http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-1 >2.txt > >This WGCL will end on July 4th so please have your comments emailed to this >list before then. > >Thank you, Cullen > > > > From w3c-dist-auth-request@frink.w3.org Mon Jun 13 23:01: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 XAA06919 for ; Mon, 13 Jun 2005 23:01:37 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di1er-0000hx-7p for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 03:00:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Di1en-0000T1-AK for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 03:00:05 +0000 Received: from dsl081-100-205.den1.dsl.speakeasy.net ([64.81.100.205] helo=harmony.cursive.net) by maggie.w3.org with esmtp (Exim 4.50) id 1Di1ej-00067z-Vh for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 03:00:07 +0000 Received: from [10.99.2.1] (unknown [10.99.2.1]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by harmony.cursive.net (Postfix) with ESMTP id D1EBA67DCB for ; Mon, 13 Jun 2005 20:59:57 -0600 (MDT) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 13 Jun 2005 20:59:25 -0600 From: Joe Hildebrand To: WebDav Message-ID: In-Reply-To: <42AE3BD6.6090908@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1Di1ej-00067z-Vh 87b7b3d405e9f6aba584b10294ba022b X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/BED3A42D.1D86%25joe@cursive.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9664 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 03:00:09 +0000 Content-Transfer-Encoding: 7bit Agree. Plus, there does exist a way, that, while being a hack, does work, and is interoperable: On 6/13/05 8:07 PM, "Lisa Dusseault" wrote: > > > The main flaw in the REDIRECT proposal is that there is not enough in > the way of plans to implement it. Without a set of independent > implementors around to review it, I fear it's too complex or has missed > key interoperability issues. > > To be clear, I do understand that the Web needs and uses redirects, and > I see that administrators do create them and that browsers follow > redirect status codes. I'm arguing that there isn't a clear need for > interoperable authoring of redirect resources, or if there is, it's not > met by this specification. Implementors might tell us, for example, > that they don't need the ability to modify a redirect (why not just > recreate) or that they'd prefer something which could handle redirecting > URLs via pattern matching to another set of calculated URLs. > > There seems to be one organization that implements REDIRECT authoring in > a potentially-interoperable way -- I believe that's Julian's > organization. I think that's great, and even better that they're > interested in publishing the way they do it so that others can do the > same. I just don't believe that meets the bar for a standards-track > RFC, because we've learned in the IETF that actual implementor review is > very important to writing good, clear, simple standards that people need. > > OSAF-specific stuff: We do not have plans to implement redirect in Cosmo > or Chandler (server or client), neither to create redirects, allow them > to be created, or add logic to allow for redirects existing on other > WebDAV servers. We're more interested, potentially, in using bindings. > > Lisa > > > Cullen Jennings wrote: > >> I would like to start working group last call >> >> http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-1 >> 2.txt >> >> This WGCL will end on July 4th so please have your comments emailed to this >> list before then. >> >> Thank you, Cullen >> >> >> >> > > -- Joe Hildebrand From w3c-dist-auth-request@frink.w3.org Tue Jun 14 04:40: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 EAA22875 for ; Tue, 14 Jun 2005 04:40:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di6x0-0003b3-EZ for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 08:39:14 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Di6wv-0003a0-OW for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 08:39:09 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Di6ws-0001wq-Vj for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 08:39:11 +0000 Received: (qmail invoked by alias); 14 Jun 2005 08:39:03 -0000 Received: from p508F9406.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.6] by mail.gmx.net (mp033) with SMTP; 14 Jun 2005 10:39:03 +0200 X-Authenticated: #1915285 Message-ID: <42AE97A4.5010301@gmx.de> Date: Tue, 14 Jun 2005 10:39:00 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1Di6ws-0001wq-Vj dece7da2d2732855d1e8c506e5c7a082 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AE97A4.5010301@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9666 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 08:39:14 +0000 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Agree. Plus, there does exist a way, that, while being a hack, does work, > and is interoperable: > > So how do you do that for a Word document, a PDF or a WebDAV collection? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 14 04:44: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 EAA23119 for ; Tue, 14 Jun 2005 04:44:19 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di71P-0004xI-EZ for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 08:43:47 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Di71L-0004vX-Nu for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 08:43:43 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Di71G-00078m-5b for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 08:43:43 +0000 Received: (qmail invoked by alias); 14 Jun 2005 08:43:36 -0000 Received: from p508F9406.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.6] by mail.gmx.net (mp013) with SMTP; 14 Jun 2005 10:43:36 +0200 X-Authenticated: #1915285 Message-ID: <42AE98B5.1010708@gmx.de> Date: Tue, 14 Jun 2005 10:43:33 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav , Geoffrey M Clemm , Jim Whitehead , ccjason@us.ibm.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Di71G-00078m-5b 665b88284ca72da021f7dfbed399c445 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-bind-11 X-Archived-At: http://www.w3.org/mid/42AE98B5.1010708@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9667 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 08:43:47 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I would like to start working group last call on > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-11.txt > > This WGCL will end on July 4th so please have your comments emailed to this > list before then. > > Thank you, Cullen Thanks Cullen, heres and additional pointer. The issues list contains all issues raised in the first WGLC (in 2000) and since then with pointers to their resolutions. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 14 04:47: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 EAA23285 for ; Tue, 14 Jun 2005 04:47:28 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di74P-0008Rz-Gf for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 08:46:53 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Di74K-0008Qo-Ap for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 08:46:48 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1Di74I-0003BV-Oh for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 08:46:50 +0000 Received: (qmail invoked by alias); 14 Jun 2005 08:46:43 -0000 Received: from p508F9406.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.6] by mail.gmx.net (mp014) with SMTP; 14 Jun 2005 10:46:43 +0200 X-Authenticated: #1915285 Message-ID: <42AE996F.2080203@gmx.de> Date: Tue, 14 Jun 2005 10:46:39 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Cullen Jennings , WebDav , Jim Whitehead , Geoffrey M Clemm References: <42AE3BD6.6090908@osafoundation.org> In-Reply-To: <42AE3BD6.6090908@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1Di74I-0003BV-Oh 519d3eddd7d85e8bb32ded4d8a64f4fa X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AE996F.2080203@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9668 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 08:46:53 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > The main flaw in the REDIRECT proposal is that there is not enough in > the way of plans to implement it. Without a set of independent > implementors around to review it, I fear it's too complex or has missed > key interoperability issues. > ... Forgot to mention: actually it *adresses* interoperability issues, because redirect-type resources already exist on the Web, but RFC2518 fails to describe how to handle them (at least) in PROPFIND responses. Authorability may not be as important, but discovery certainly is. Today, Apache/moddav just hides redirects from WebDAV clients. I think this is a problem that needs to be solved. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 14 05:28: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 EAA22876 for ; Tue, 14 Jun 2005 04:40:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Di6wH-0003Yd-3k for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 08:38:29 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Di6wB-0003Y5-L9 for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 08:38:23 +0000 Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.50) id 1Di6w7-0006GP-Qp for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 08:38:23 +0000 Received: (qmail invoked by alias); 14 Jun 2005 08:38:17 -0000 Received: from p508F9406.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.6] by mail.gmx.net (mp017) with SMTP; 14 Jun 2005 10:38:17 +0200 X-Authenticated: #1915285 Message-ID: <42AE9773.6050908@gmx.de> Date: Tue, 14 Jun 2005 10:38:11 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Cullen Jennings , WebDav , Jim Whitehead , Geoffrey M Clemm References: <42AE3BD6.6090908@osafoundation.org> In-Reply-To: <42AE3BD6.6090908@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: lisa.w3.org 1Di6w7-0006GP-Qp 7485cf80a5ef9a1a389f81d531fe8796 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AE9773.6050908@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9665 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 08:38:29 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > > The main flaw in the REDIRECT proposal is that there is not enough in > the way of plans to implement it. Without a set of independent > implementors around to review it, I fear it's too complex or has missed > key interoperability issues. I do agree that there seems to be more interest in BIND than REDIRECT. On the other hand, I disagree that because of this it can't start at "Proposed" (as Jim W. pointed out some time ago in a similar dicussion for BIND). If the working group feels that it's too early to go to "Proposed", I think "Experimental" would make sense. It would preserve the work that has been done; and if at a later point of time more implementations appear, it can be rev'd up. > To be clear, I do understand that the Web needs and uses redirects, and > I see that administrators do create them and that browsers follow > redirect status codes. I'm arguing that there isn't a clear need for > interoperable authoring of redirect resources, or if there is, it's not > met by this specification. Implementors might tell us, for example, > that they don't need the ability to modify a redirect (why not just > recreate) or that they'd prefer something which could handle redirecting > URLs via pattern matching to another set of calculated URLs. The ability to modify was added based on a Last-Call comment in 2000, and the WG decided to accept it. See . > There seems to be one organization that implements REDIRECT authoring in > a potentially-interoperable way -- I believe that's Julian's > organization. I think that's great, and even better that they're It's SAP (first time I've heard it called "Julian's org", but that sounds nice :-). As a matter of fact, the Xythos client implements some aspects of the protocol as well (discovery but not authorability). > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 14 13:32: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 NAA06951 for ; Tue, 14 Jun 2005 13:32:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DiFFA-0000rX-Cc for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 17:30:32 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DiFF5-0000qx-D4 for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 17:30:27 +0000 Received: from services.cse.ucsc.edu ([128.114.48.10]) by bart.w3.org with esmtp (Exim 4.50) id 1DiFF2-0000Ji-W3 for w3c-dist-auth@w3c.org; Tue, 14 Jun 2005 17:30:27 +0000 Received: from tycho (dhcp-59-204.cse.ucsc.edu [128.114.59.204]) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5EHUGYt006084; Tue, 14 Jun 2005 10:30:18 -0700 (PDT) Message-Id: <200506141730.j5EHUGYt006084@services.cse.ucsc.edu> Reply-To: From: "Jim Whitehead" To: "'Joe Hildebrand'" , "'Webdav WG'" Date: Tue, 14 Jun 2005 10:30:14 -0700 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: Thread-Index: AcVwczJ0GA/sluo9Tp+ELckJV/BBkQAk0xBw X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: bart.w3.org 1DiFF2-0000Ji-W3 aabadb2ef01b2e2944a62271cb730349 X-Original-To: w3c-dist-auth@w3.org Subject: RE: Stepping down X-Archived-At: http://www.w3.org/mid/200506141730.j5EHUGYt006084@services.cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9669 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 17:30:32 +0000 Content-Transfer-Encoding: 7bit Joe, I would like to thank you very much for your efforts as Chair of the WebDAV Working Group. It's due to volunteers such as yourself that the IETF continues to work, and produce high quality specifications. - Jim > On a similar front, as you all have seen, the rigors of my > day job have prevented me from spending as much time on this > WG as I thought I would be able to when I became co-chair. > Therefore, I'll be stepping down as well. From w3c-dist-auth-request@frink.w3.org Tue Jun 14 14:01: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 OAA13426 for ; Tue, 14 Jun 2005 14:01:54 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DiFio-0001u4-1W for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 18:01:10 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DiFWi-0006Ni-AK for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 17:48:40 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by maggie.w3.org with esmtp (Exim 4.50) id 1DiFWf-0006I7-SJ for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 17:48:42 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2D529142266; Tue, 14 Jun 2005 10:45:54 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10313-06; Tue, 14 Jun 2005 10:45:54 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id D87CE142262; Tue, 14 Jun 2005 10:45:53 -0700 (PDT) Message-ID: <42AF1870.5030000@osafoundation.org> Date: Tue, 14 Jun 2005 10:48:32 -0700 From: Lisa Dusseault User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Cc: Cullen Jennings , WebDav , Jim Whitehead , Geoffrey M Clemm References: <42AE3BD6.6090908@osafoundation.org> <42AE996F.2080203@gmx.de> In-Reply-To: <42AE996F.2080203@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1DiFWf-0006I7-SJ 37ca27c9f05f78dd1f2063d01f893350 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AF1870.5030000@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9670 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 18:01:10 +0000 Content-Transfer-Encoding: 7bit I think that hiding redirects from authoring clients may be a perfectly good and reasonably interoperable thing to do. It depends on two things: the model and the need. The model that REDIRECT has is very pure -- that a URL that produces a redirect is a resource. That's not the only model, however. An implementor (client or server) could have a model where a URL that produces a redirect does *not* point to a resource, just like a URL that produces a 404 does not have an associated resource. That model is already reflected in software like mod_rewrite, a module which is quite incompatible with REDIRECT. The "redirect is not a resource" model could still support authorability, for example by adding properties to collections, and the properties could contain redirect rules. The "need" is the practical concern which we've already discussed, but I'd add that if we have a way to author redirects that is incompatible with mod_rewrite and the way administrators actually need to create redirect rules, then we may not have even solved the theoretical need. The fact that SAP (aka Julian's org) implements them as resources is in fact very suggestive. If that's the model you thought of, perhaps it's a better model for interoperability, a more WebDAV-suited model. So now we're back to wanting other implementations to validate that model. Lisa Julian Reschke wrote: > Lisa Dusseault wrote: > >> >> The main flaw in the REDIRECT proposal is that there is not enough in >> the way of plans to implement it. Without a set of independent >> implementors around to review it, I fear it's too complex or has >> missed key interoperability issues. >> ... > > > Forgot to mention: actually it *adresses* interoperability issues, > because redirect-type resources already exist on the Web, but RFC2518 > fails to describe how to handle them (at least) in PROPFIND responses. > > Authorability may not be as important, but discovery certainly is. > Today, Apache/moddav just hides redirects from WebDAV clients. I think > this is a problem that needs to be solved. > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Tue Jun 14 14:14: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 OAA13961 for ; Tue, 14 Jun 2005 14:14:26 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DiFuy-0003wR-09 for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jun 2005 18:13:44 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DiFeV-0007rE-Lx for w3c-dist-auth@listhub.w3.org; Tue, 14 Jun 2005 17:56:43 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by maggie.w3.org with smtp (Exim 4.50) id 1DiFeU-0007Ps-7B for w3c-dist-auth@w3.org; Tue, 14 Jun 2005 17:56:45 +0000 Received: (qmail invoked by alias); 14 Jun 2005 17:56:38 -0000 Received: from p508F9406.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.148.6] by mail.gmx.net (mp018) with SMTP; 14 Jun 2005 19:56:38 +0200 X-Authenticated: #1915285 Message-ID: <42AF1A41.2090409@gmx.de> Date: Tue, 14 Jun 2005 19:56:17 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Cullen Jennings , WebDav , Jim Whitehead , Geoffrey M Clemm References: <42AE3BD6.6090908@osafoundation.org> <42AE996F.2080203@gmx.de> <42AF1870.5030000@osafoundation.org> In-Reply-To: <42AF1870.5030000@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1DiFeU-0007Ps-7B 495cd853b17f91aaaab881e3824d3268 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42AF1A41.2090409@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9671 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 14 Jun 2005 18:13:44 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I think that hiding redirects from authoring clients may be a perfectly > good and reasonably interoperable thing to do. It depends on two > things: the model and the need. So what do you expect to happen when a client attempts a PUT on one of these URIs? A redirect? A new resource being created? If the resource is indeed being created, will it actually be visible, or will the rewrite logic eclipse it? This is the sort of interop problems we have today. > ... Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 14 20:53: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 UAA22995 for ; Tue, 14 Jun 2005 20:53:53 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DiM7y-0005ey-BS for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Jun 2005 00:51:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DiM7t-0005eL-7T for w3c-dist-auth@listhub.w3.org; Wed, 15 Jun 2005 00:51:29 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1DiM7r-0007eD-EA for w3c-dist-auth@w3.org; Wed, 15 Jun 2005 00:51:31 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2005 17:51:23 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5F0pJbw000791 for ; Tue, 14 Jun 2005 17:51:19 -0700 (PDT) Received: from 10.32.130.34 ([10.32.130.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Jun 2005 00:53:37 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 14 Jun 2005 17:51:20 -0700 From: Cullen Jennings To: WebDav Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: maggie.w3.org 1DiM7r-0007eD-EA 06c0f511eb577c884ababbd295f3e117 X-Original-To: w3c-dist-auth@w3.org Subject: Redirect Implementations X-Archived-At: http://www.w3.org/mid/BED4C998.3DF0D%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9672 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Jun 2005 00:51:34 +0000 Content-Transfer-Encoding: 7bit I'm keen to identify any changes required to the document, but to help us figure out what to do with this document once we call it done, I will ask the following? Does anyone have a redirect server implementation? do they have a client implementation? Do they plan to build one some time in the next 12 months? Do the know of others building client or server? I anyone does not feel comfortable replying to the list, I will attempt to keep any private replies I receive private other than posting to the list the aggregate number of replies that indicating they would have a client or server. Cullen PS. This may be a lame question to ask when we have a small number of participants, but what the heck, I'm trying to figure out what provides useful information for making decision in this WG and what does not. From w3c-dist-auth-request@frink.w3.org Wed Jun 15 05:05: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 FAA24146 for ; Wed, 15 Jun 2005 05:05:12 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DiTnC-0006Ir-4O for w3c-dist-auth-dist@listhub.w3.org; Wed, 15 Jun 2005 09:02:38 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DiTn6-0006HH-SF for w3c-dist-auth@listhub.w3.org; Wed, 15 Jun 2005 09:02:32 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1DiTn3-0002e2-CY for w3c-dist-auth@w3.org; Wed, 15 Jun 2005 09:02:32 +0000 Received: (qmail invoked by alias); 15 Jun 2005 09:02:26 -0000 Received: from p508F955B.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.149.91] by mail.gmx.net (mp022) with SMTP; 15 Jun 2005 11:02:26 +0200 X-Authenticated: #1915285 Message-ID: <42AFEEA0.2060403@gmx.de> Date: Wed, 15 Jun 2005 11:02:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.0 X-W3C-Scan-Sig: bart.w3.org 1DiTn3-0002e2-CY ba900e7ce5d625975c16efb01c6bb7b6 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Redirect Implementations X-Archived-At: http://www.w3.org/mid/42AFEEA0.2060403@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9673 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 15 Jun 2005 09:02:38 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I'm keen to identify any changes required to the document, but to help us > figure out what to do with this document once we call it done, I will ask > the following? > > Does anyone have a redirect server implementation? do they have a client > implementation? Do they plan to build one some time in the next 12 months? > Do the know of others building client or server? SAP's Netweaver KM comes with both a server and a client implementation of redirects. It has been shipping this way for several years now, with same recent updates for the changes in the latest drafs (UPDATEREDIRECTREF method, fragment identifiers). > I anyone does not feel comfortable replying to the list, I will attempt to > keep any private replies I receive private other than posting to the list > the aggregate number of replies that indicating they would have a client or > server. > > Cullen > > PS. This may be a lame question to ask when we have a small number of > participants, but what the heck, I'm trying to figure out what provides > useful information for making decision in this WG and what does not. That's fine. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Jun 16 08:20: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 IAA13017 for ; Thu, 16 Jun 2005 08:20:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DitJp-00087R-Cz for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 12:18:01 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DitJk-000855-6o for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 12:17:56 +0000 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by lisa.w3.org with esmtp (Exim 4.50) id 1DitJd-0007Ia-Vi for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 12:17:55 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5GCHLHr004044 for ; Thu, 16 Jun 2005 08:17:21 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5GCHLCk216706 for ; Thu, 16 Jun 2005 08:17:21 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5GCHL25004426 for ; Thu, 16 Jun 2005 08:17:21 -0400 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 j5GCHLPO004421 for ; Thu, 16 Jun 2005 08:17:21 -0400 In-Reply-To: <42AE9773.6050908@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: Thu, 16 Jun 2005 08:17:27 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/16/2005 08:17:21, Serialize complete at 06/16/2005 08:17:21 Content-Type: multipart/alternative; boundary="=_alternative 0043830F85257022_=" X-W3C-Hub-Spam-Status: No, score=-1.0 X-W3C-Scan-Sig: lisa.w3.org 1DitJd-0007Ia-Vi ee542683c36aa01937323d223041b933 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/OFCD2C0E36.ACD7FE97-ON85257022.0042452C-85257022.00438313@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9674 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 12:18:01 +0000 This is a multipart message in MIME format. --=_alternative 0043830F85257022_= Content-Type: text/plain; charset="US-ASCII" This is a very simple subject area, but there are some choices to be made, and without a standard to define a common way, we'll get folks just rolling their own with incompatible semantic details (as is being done now). So unless there are some actual technical problems with the REDIRECT draft, I believe the current REDIRECT draft should go to "Proposed", to address the interoperability in this area that already has arisen due to the lack of a standard for how to author redirect references. In this case, since there aren't any subtle technical issues/obstacles to be addressed, and we just need a common convention, I think it is appropriate for the draft standard to drive the implementations, rather than the other way round. In particular, the issue of authoring redirect references isn't critical enough for folks to modify their current mechanisms to make them interoperable, until there is a draft standard that defines how to do so. Cheers, Geoff Julian wrote on 06/14/2005 04:38:11 AM: > > Lisa Dusseault wrote: > > > > > > The main flaw in the REDIRECT proposal is that there is not enough in > > the way of plans to implement it. Without a set of independent > > implementors around to review it, I fear it's too complex or has missed > > key interoperability issues. > > I do agree that there seems to be more interest in BIND than REDIRECT. > On the other hand, I disagree that because of this it can't start at > "Proposed" (as Jim W. pointed out some time ago in a similar dicussion > for BIND). > > If the working group feels that it's too early to go to "Proposed", I > think "Experimental" would make sense. It would preserve the work that > has been done; and if at a later point of time more implementations > appear, it can be rev'd up. > > > To be clear, I do understand that the Web needs and uses redirects, and > > I see that administrators do create them and that browsers follow > > redirect status codes. I'm arguing that there isn't a clear need for > > interoperable authoring of redirect resources, or if there is, it's not > > met by this specification. Implementors might tell us, for example, > > that they don't need the ability to modify a redirect (why not just > > recreate) or that they'd prefer something which could handle redirecting > > URLs via pattern matching to another set of calculated URLs. > > The ability to modify was added based on a Last-Call comment in 2000, > and the WG decided to accept it. See > protocol-issues.html#lc-58-update>. > > > There seems to be one organization that implements REDIRECT authoring in > > a potentially-interoperable way -- I believe that's Julian's > > organization. I think that's great, and even better that they're > > It's SAP (first time I've heard it called "Julian's org", but that > sounds nice :-). As a matter of fact, the Xythos client implements some > aspects of the protocol as well (discovery but not authorability). > > > ... > > Best regards, Julian > --=_alternative 0043830F85257022_= Content-Type: text/html; charset="US-ASCII"
This is a very simple subject area, but there are some
choices to be made, and without a standard to define a common way,
we'll get folks just rolling their own with incompatible semantic
details (as is being done now).

So unless there are some actual technical problems with the REDIRECT
draft, I believe the current REDIRECT draft should go to "Proposed",
to address the interoperability in this area that already has arisen
due to the lack of a standard for how to author redirect references.

In this case, since there aren't any subtle technical issues/obstacles
to be addressed, and we just need a common convention, I think it is
appropriate for the draft standard to drive the implementations, rather
than the other way round.  In particular, the issue of authoring redirect
references isn't critical enough for folks to modify their current
mechanisms to make them interoperable, until there is a draft standard
that defines how to do so.

Cheers,
Geoff


Julian wrote on 06/14/2005 04:38:11 AM:

>
> Lisa Dusseault wrote:
> >
> >
> > The main flaw in the REDIRECT proposal is that there is not enough in
> > the way of plans to implement it.  Without a set of independent
> > implementors around to review it, I fear it's too complex or has missed
> > key interoperability issues.
>
> I do agree that there seems to be more interest in BIND than REDIRECT.
> On the other hand, I disagree that because of this it can't start at
> "Proposed" (as Jim W. pointed out some time ago in a similar dicussion
> for BIND).
>
> If the working group feels that it's too early to go to "Proposed", I
> think "Experimental" would make sense. It would preserve the work that
> has been done; and if at a later point of time more implementations
> appear, it can be rev'd up.
>
> > To be clear, I do understand that the Web needs and uses redirects, and
> > I see that administrators do create them and that browsers follow
> > redirect status codes.  I'm arguing that there isn't a clear need for
> > interoperable authoring of redirect resources, or if there is, it's not
> > met by this specification.  Implementors might tell us, for example,
> > that they don't need the ability to modify a redirect (why not just
> > recreate) or that they'd prefer something which could handle redirecting
> > URLs via pattern matching to another set of calculated URLs.
>
> The ability to modify was added based on a Last-Call comment in 2000,
> and the WG decided to accept it. See
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-
> protocol-issues.html#lc-58-update>.
>
> > There seems to be one organization that implements REDIRECT authoring in
> > a potentially-interoperable way -- I believe that's Julian's
> > organization. I think that's great, and even better that they're
>
> It's SAP (first time I've heard it called "Julian's org", but that
> sounds nice :-). As a matter of fact, the Xythos client implements some
> aspects of the protocol as well (discovery but not authorability).
>
>  > ...
>
> Best regards, Julian
>
--=_alternative 0043830F85257022_=-- From w3c-dist-auth-request@frink.w3.org Thu Jun 16 11:09: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 LAA29732 for ; Thu, 16 Jun 2005 11:09:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DivyT-0004Z7-Ti for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 15:08:09 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DivyL-0004Y4-45 for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 15:08:01 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by maggie.w3.org with esmtp (Exim 4.50) id 1DivyF-0000nE-48 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 15:08:03 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 7745E14226B; Thu, 16 Jun 2005 08:04:53 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13998-04; Thu, 16 Jun 2005 08:04:53 -0700 (PDT) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 3859D142266; Thu, 16 Jun 2005 08:04:51 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/alternative; boundary=Apple-Mail-14-1040829311 Message-Id: <87c5235f9ea00705fa41612b47577368@osafoundation.org> Cc: " webdav" From: Lisa Dusseault Date: Thu, 16 Jun 2005 08:07:46 -0700 To: Geoffrey M Clemm X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1DivyF-0000nE-48 cf6236fb6b3db4fe4d039ba6cc0d7bc8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/87c5235f9ea00705fa41612b47577368@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9675 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 15:08:09 +0000 --Apple-Mail-14-1040829311 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Are there any other Web or WebDAV servers that allow redirects to be=20 authored over any kind of protocol or service? The only things I'm=20 aware of already: - Joe's hack which is a client-to-client communication that is ignored=20= by the server, so unlikely to be replaced by server logic - Web server configuration done by administrators, which isn't really=20= itself a protocol or service although there might be something like SSH=20= or FTP involved, also unlikely to be replaced because it's what=20 administrators do for many other chores as well (and because REDIRECT=20 may not solve the entire need) If there are other approaches, I'm unaware of them, and it would help=20 to know. But if these are the only cases than I have a different=20 evaluation of whether implementors will change current mechanisms. Lisa On Jun 16, 2005, at 5:17 AM, Geoffrey M Clemm wrote: > > This is a very simple subject area, but there are some > choices to be made, and without a standard to define a common way, > we'll get folks just rolling their own with incompatible semantic > details (as is being done now). > > So unless there are some actual technical problems with the REDIRECT > draft, I believe the current REDIRECT draft should go to "Proposed", > to address the interoperability in this area that already has arisen > due to the lack of a standard for how to author redirect references. > > In this case, since there aren't any subtle technical issues/obstacles > to be addressed, and we just need a common convention, I think it is > appropriate for the draft standard to drive the implementations, = rather > than the other way round. =A0In particular, the issue of authoring=20 > redirect > references isn't critical enough for folks to modify their current > mechanisms to make them interoperable, until there is a draft standard > that defines how to do so. > > Cheers, > Geoff > > > Julian wrote on 06/14/2005 04:38:11 AM: > > > > > Lisa Dusseault wrote: > > > > > > > > > The main flaw in the REDIRECT proposal is that there is not=20 > enough in > > > the way of plans to implement it. =A0Without a set of independent > > > implementors around to review it, I fear it's too complex or has=20= > missed > > > key interoperability issues. > > > > I do agree that there seems to be more interest in BIND than=20 > REDIRECT. > > On the other hand, I disagree that because of this it can't start = at > > "Proposed" (as Jim W. pointed out some time ago in a similar=20 > dicussion > > for BIND). > > > > If the working group feels that it's too early to go to "Proposed",=20= > I > > think "Experimental" would make sense. It would preserve the work=20= > that > > has been done; and if at a later point of time more implementations > > appear, it can be rev'd up. > > > > > To be clear, I do understand that the Web needs and uses=20 > redirects, and > > > I see that administrators do create them and that browsers follow > > > redirect status codes. =A0I'm arguing that there isn't a clear = need=20 > for > > > interoperable authoring of redirect resources, or if there is,=20 > it's not > > > met by this specification. =A0Implementors might tell us, for=20 > example, > > > that they don't need the ability to modify a redirect (why not=20 > just > > > recreate) or that they'd prefer something which could handle=20 > redirecting > > > URLs via pattern matching to another set of calculated URLs. > > > > The ability to modify was added based on a Last-Call comment in=20 > 2000, > > and the WG decided to accept it. See > > > protocol-issues.html#lc-58-update>. > > > > > There seems to be one organization that implements REDIRECT=20 > authoring in > > > a potentially-interoperable way -- I believe that's Julian's > > > organization. I think that's great, and even better that they're > > > > It's SAP (first time I've heard it called "Julian's org", but that > > sounds nice :-). As a matter of fact, the Xythos client implements=20= > some > > aspects of the protocol as well (discovery but not authorability). > > > > =A0> ... > > > > Best regards, Julian > > --Apple-Mail-14-1040829311 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are there any other Web or WebDAV servers that allow redirects to be authored over any kind of protocol or service? The only things I'm aware of already: - Joe's hack which is a client-to-client communication that is ignored by the server, so unlikely to be replaced by server logic - Web server configuration done by administrators, which isn't really itself a protocol or service although there might be something like SSH or FTP involved, also unlikely to be replaced because it's what administrators do for many other chores as well (and because REDIRECT may not solve the entire need) If there are other approaches, I'm unaware of them, and it would help to know. But if these are the only cases than I have a different evaluation of whether implementors will change current mechanisms. Lisa On Jun 16, 2005, at 5:17 AM, Geoffrey M Clemm wrote: This is a very simple subject area, but there are some=20 choices to be made, and without a standard to define a common way,=20 we'll get folks just rolling their own with incompatible semantic=20 details (as is being done now).=20 So unless there are some actual technical problems with the REDIRECT=20 draft, I believe the current REDIRECT draft should go to "Proposed",=20 to address the interoperability in this area that already has arisen=20 due to the lack of a standard for how to author redirect references.=20 In this case, since there aren't any subtle technical issues/obstacles=20 to be addressed, and we just need a common convention, I think it is=20 appropriate for the draft standard to drive the implementations, rather=20 than the other way round. =A0In particular, the issue of authoring redirect=20 references isn't critical enough for folks to modify their current mechanisms to make them interoperable, until there is a draft standard=20 that defines how to do so.=20 Cheers,=20 Geoff=20 Julian wrote on 06/14/2005 04:38:11 = AM: > > Lisa Dusseault wrote: > > > > > > The main flaw in the REDIRECT proposal is that there is not enough in > > the way of plans to implement it. =A0Without a set of independent > > implementors around to review it, I fear it's too complex or has missed > > key interoperability = issues. > > I do agree that there seems to be more interest in BIND than REDIRECT. > On the other hand, I disagree that because of this it can't start at > "Proposed" (as Jim W. pointed out some time ago in a similar dicussion > for BIND). > > If the working group feels that it's too early to go to "Proposed", I > think "Experimental" would make sense. It would preserve the work that > has been done; and if at a later point of time more implementations > appear, it can be rev'd = up. > > > To be clear, I do understand that the Web needs and uses redirects, and > > I see that administrators do create them and that browsers follow > > redirect status codes. =A0I'm arguing that there isn't a clear need for > > interoperable authoring of redirect resources, or if there is, it's not > > met by this specification. =A0Implementors might tell us, for example, > > that they don't need the ability to modify a redirect (why not just > > recreate) or that they'd prefer something which could handle redirecting > > URLs via pattern matching to another set of calculated URLs. > > The ability to modify was added based on a Last-Call comment in 2000, > and the WG decided to accept it. See = > = < > = protocol-issues.html#lc-58-update>. > > > There seems to be one organization that implements REDIRECT authoring in > > a potentially-interoperable way -- I believe that's Julian's > > organization. I think that's great, and even better that they're > > It's SAP (first time I've heard it called "Julian's org", but that > sounds nice :-). As a matter of fact, the Xythos client implements some > aspects of the protocol as well (discovery but not authorability). > > =A0> ... > > Best regards, Julian > = --Apple-Mail-14-1040829311-- From w3c-dist-auth-request@frink.w3.org Thu Jun 16 12:39: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 MAA08935 for ; Thu, 16 Jun 2005 12:39:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DixNb-00048e-Mi for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 16:38:11 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DixNT-00046H-MZ for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 16:38:03 +0000 Received: from numenor.qualcomm.com ([129.46.51.58]) by maggie.w3.org with esmtp (Exim 4.50) id 1DixNR-0006pZ-I0 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 16:38:05 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GGbrCK026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Jun 2005 09:37:54 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-6.qualcomm.com [10.50.16.6]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GGbouR010917; Thu, 16 Jun 2005 09:37:51 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 16 Jun 2005 09:37:49 -0700 To: Geoffrey M Clemm , " webdav" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-W3C-Hub-Spam-Status: No, score=-0.6 X-W3C-Scan-Sig: maggie.w3.org 1DixNR-0006pZ-I0 7e4d4aadc59de289d1733f3a54306441 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/p06210207bed75a8e2980@%5B192.168.1.4%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9676 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 16:38:11 +0000 At 8:17 AM -0400 6/16/05, Geoffrey M Clemm wrote: > >So unless there are some actual technical problems with the REDIRECT >draft, I believe the current REDIRECT draft should go to "Proposed", >to address the interoperability in this area that already has arisen >due to the lack of a standard for how to author redirect references. > >In this case, since there aren't any subtle technical issues/obstacles >to be addressed, and we just need a common convention, I think it is >appropriate for the draft standard to drive the implementations, rather >than the other way round. Just as a quick clarification, am I right that you mean you want the current draft, as a Proposed Standard, to guide implementations? Because of the usual draft-vs.-Draft Standard, I could read your message to mean "wait until the Draft Standard conditions are met", and it seems safer to confirm your intent. regards, Ted Hardie From w3c-dist-auth-request@frink.w3.org Thu Jun 16 12:42: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 MAA09308 for ; Thu, 16 Jun 2005 12:42:27 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DixRG-0004xz-JC for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 16:41:58 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DixRE-0004xP-0h for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 16:41:56 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1DixRB-0007UZ-62 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 16:41:58 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5GGflLw030020 for ; Thu, 16 Jun 2005 12:41:47 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5GGflCk200402 for ; Thu, 16 Jun 2005 12:41:47 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5GGfk7G009936 for ; Thu, 16 Jun 2005 12:41:47 -0400 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 j5GGfkPf009933; Thu, 16 Jun 2005 12:41:46 -0400 In-Reply-To: To: Ted Hardie 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, 16 Jun 2005 12:41:54 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/16/2005 12:41:46, Serialize complete at 06/16/2005 12:41:46 Content-Type: multipart/alternative; boundary="=_alternative 005BB93785257022_=" X-W3C-Hub-Spam-Status: No, score=-1.0 X-W3C-Scan-Sig: maggie.w3.org 1DixRB-0007UZ-62 17ada582a22291fc443fe27168e049b1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/OFA46C9F7D.2F236C21-ON85257022.005B8AE2-85257022.005BB93A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9677 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 16:41:58 +0000 This is a multipart message in MIME format. --=_alternative 005BB93785257022_= Content-Type: text/plain; charset="US-ASCII" You are correct that I intended to suggest that the current draft be adopted as a Draft Standard, to guide implementations. Sorry about the ambiguous wording, and thanks for the clarification! Cheers, Geoff Ted Hardie wrote on 06/16/2005 12:37:49 PM: > At 8:17 AM -0400 6/16/05, Geoffrey M Clemm wrote: > > > >So unless there are some actual technical problems with the REDIRECT > >draft, I believe the current REDIRECT draft should go to "Proposed", > >to address the interoperability in this area that already has arisen > >due to the lack of a standard for how to author redirect references. > > > >In this case, since there aren't any subtle technical issues/obstacles > >to be addressed, and we just need a common convention, I think it is > >appropriate for the draft standard to drive the implementations, rather > >than the other way round. > > Just as a quick clarification, am I right that you mean you want > the current draft, as a Proposed Standard, to guide implementations? > Because of the usual draft-vs.-Draft Standard, I could read your > message to mean "wait until the Draft Standard conditions are met", > and it seems safer to confirm your intent. > regards, > Ted Hardie --=_alternative 005BB93785257022_= Content-Type: text/html; charset="US-ASCII"
You are correct that I intended to suggest that the current draft be
adopted as a Draft Standard, to guide implementations.

Sorry about the ambiguous wording, and thanks for the clarification!

Cheers,
Geoff

Ted Hardie <hardie@qualcomm.com> wrote on 06/16/2005 12:37:49 PM:

> At 8:17 AM -0400 6/16/05, Geoffrey M Clemm wrote:
> >
> >So unless there are some actual technical problems with the REDIRECT
> >draft, I believe the current REDIRECT draft should go to "Proposed",
> >to address the interoperability in this area that already has arisen
> >due to the lack of a standard for how to author redirect references.
> >
> >In this case, since there aren't any subtle technical issues/obstacles
> >to be addressed, and we just need a common convention, I think it is
> >appropriate for the draft standard to drive the implementations, rather
> >than the other way round.
>
> Just as a quick clarification, am I right that you mean you want
> the current draft, as a Proposed Standard, to guide implementations?
> Because of the usual draft-vs.-Draft Standard, I could read your
> message to mean "wait until the Draft Standard conditions are met",
> and it seems safer to confirm your intent.
>          regards,
>             Ted Hardie
 --=_alternative 005BB93785257022_=-- From w3c-dist-auth-request@frink.w3.org Thu Jun 16 14:25:47 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 OAA22447 for ; Thu, 16 Jun 2005 14:25:46 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Diz2T-0006vx-Uk for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 18:24:29 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Diz2Q-0006v4-Hn for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 18:24:26 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.50) id 1Diz2M-0000nn-P7 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 18:24:26 +0000 Received: (qmail invoked by alias); 16 Jun 2005 18:24:21 -0000 Received: from p508F9F05.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.159.5] by mail.gmx.net (mp034) with SMTP; 16 Jun 2005 20:24:21 +0200 X-Authenticated: #1915285 Message-ID: <42B1C3D2.90207@gmx.de> Date: Thu, 16 Jun 2005 20:24:18 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav , Brian Korver , Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1Diz2M-0000nn-P7 9b27afe4d6e928317cf70ead44eed137 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-quota-07 X-Archived-At: http://www.w3.org/mid/42B1C3D2.90207@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9678 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 18:24:29 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I would like to start working group last call > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt > > This WGCL will end on June 27th so please have your comments emailed to this > list before then. > > Thank you, Cullen Hi, we (greenbytes, currently contracting for SAP), do not intend to implement the QUOTA spec any time soon, but we do feel that the spec is stable and mature, and it is suited as an interoperable base for a set of differing quota implementations. Some more thoughts: - The spec started as a description of a very specific quota implementation, which wasn't directly implementable for other quota systems such as the Unix one; as far as I can tell, this problem has been resolved. - The spec still contains a somewehat arbitrary optimization for a specific type of implementation (requiring live properties on collections but not on it's members). I'd prefer that one to be removed, simplifying the spec a bit more, but unless others feel the same way, we should probably leave things as they are (WG dicussion back in ) - The spec currently suggests that disk limits to be marshalled as quotas. I'm not sure this is a good idea (for instance, Unix handles those very differently), but again I'm not planning to lie down in the road because of it. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Jun 16 14:51: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 OAA24989 for ; Thu, 16 Jun 2005 14:51:58 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DizC1-0001rh-SO for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 18:34:21 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Diz9u-0000zC-TG; Thu, 16 Jun 2005 18:32:11 +0000 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by maggie.w3.org with esmtp (Exim 4.50) id 1Diz9q-0007Ld-MJ; Thu, 16 Jun 2005 18:32:12 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5GIW3mH019839; Thu, 16 Jun 2005 14:32:03 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5GIW3an231742; Thu, 16 Jun 2005 14:32:03 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5GIW2dU019488; Thu, 16 Jun 2005 14:32:03 -0400 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 j5GIW1qP019424; Thu, 16 Jun 2005 14:32:01 -0400 In-Reply-To: <42B1C3D2.90207@gmx.de> To: Julian Reschke Cc: Brian Korver , Cullen Jennings , Lisa Dusseault , 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: Thu, 16 Jun 2005 14:32:03 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/16/2005 14:32:01, Serialize complete at 06/16/2005 14:32:01 Content-Type: multipart/alternative; boundary="=_alternative 0065CEDD85257022_=" X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Diz9q-0007Ld-MJ 449f431e9ec363a917c402f4f3c1f5a0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-quota-07 X-Archived-At: http://www.w3.org/mid/OF434A6356.48E08769-ON85257022.006594C8-85257022.0065CEE1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9679 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 18:34:21 +0000 This is a multipart message in MIME format. --=_alternative 0065CEDD85257022_= Content-Type: text/plain; charset="US-ASCII" I agree with Julian's comments. In particular, I would also prefer that the two changes Julian suggest below be made, but like Julian, would not lie in the road to make sure they get made (:-). Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 06/16/2005 02:24:18 PM: > > Cullen Jennings wrote: > > > > I would like to start working group last call > > > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt > > > > This WGCL will end on June 27th so please have your comments emailed to this > > list before then. > > > > Thank you, Cullen > > Hi, > > we (greenbytes, currently contracting for SAP), do not intend to > implement the QUOTA spec any time soon, but we do feel that the spec is > stable and mature, and it is suited as an interoperable base for a set > of differing quota implementations. > > Some more thoughts: > > - The spec started as a description of a very specific quota > implementation, which wasn't directly implementable for other quota > systems such as the Unix one; as far as I can tell, this problem has > been resolved. > > - The spec still contains a somewehat arbitrary optimization for a > specific type of implementation (requiring live properties on > collections but not on it's members). I'd prefer that one to be removed, > simplifying the spec a bit more, but unless others feel the same way, we > should probably leave things as they are (WG dicussion back in > ) > > - The spec currently suggests that disk limits to be marshalled as > quotas. I'm not sure this is a good idea (for instance, Unix handles > those very differently), but again I'm not planning to lie down in the > road because of it. > > Best regards, > > Julian > --=_alternative 0065CEDD85257022_= Content-Type: text/html; charset="US-ASCII"
I agree with Julian's comments.  In particular, I would also prefer
that the two changes Julian suggest below be made, but like Julian, would
not lie in the road to make sure they get made (:-).

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/16/2005 02:24:18 PM:

>
> Cullen Jennings wrote:
> >
> > I would like to start working group last call
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt
> >
> > This WGCL will end on June 27th so please have your comments emailed to this
> > list before then.
> >
> > Thank you, Cullen
>
> Hi,
>
> we (greenbytes, currently contracting for SAP), do not intend to
> implement the QUOTA spec any time soon, but we do feel that the spec is
> stable and mature, and it is suited as an interoperable base for a set
> of differing quota implementations.
>
> Some more thoughts:
>
> - The spec started as a description of a very specific quota
> implementation, which wasn't directly implementable for other quota
> systems such as the Unix one; as far as I can tell, this problem has
> been resolved.
>
> - The spec still contains a somewehat arbitrary optimization for a
> specific type of implementation (requiring live properties on
> collections but not on it's members). I'd prefer that one to be removed,
> simplifying the spec a bit more, but unless others feel the same way, we
> should probably leave things as they are (WG dicussion back in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0322.html>)
>
> - The spec currently suggests that disk limits to be marshalled as
> quotas. I'm not sure this is a good idea (for instance, Unix handles
> those very differently), but again I'm not planning to lie down in the
> road because of it.
>
> Best regards,
>
> Julian
>
--=_alternative 0065CEDD85257022_=-- From w3c-dist-auth-request@frink.w3.org Thu Jun 16 16:07: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 QAA04022 for ; Thu, 16 Jun 2005 16:07:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dj0cP-0007GY-HD for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 20:05:41 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dj0QJ-0003gp-LY for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 19:53:11 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1Dj0QG-0000xk-J2 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 19:53:11 +0000 Received: (qmail invoked by alias); 16 Jun 2005 19:53:05 -0000 Received: from p508F9F05.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.159.5] by mail.gmx.net (mp031) with SMTP; 16 Jun 2005 21:53:05 +0200 X-Authenticated: #1915285 Message-ID: <42B1D898.9080105@gmx.de> Date: Thu, 16 Jun 2005 21:52:56 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <87c5235f9ea00705fa41612b47577368@osafoundation.org> In-Reply-To: <87c5235f9ea00705fa41612b47577368@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: bart.w3.org 1Dj0QG-0000xk-J2 8fec9d920226dcb986525f37009b8a44 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42B1D898.9080105@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9680 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 20:05:41 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Are there any other Web or WebDAV servers that allow redirects to be > authored over any kind of protocol or service? The only things I'm aware > of already: > - Joe's hack which is a client-to-client communication that is ignored > by the server, so unlikely to be replaced by server logic > - Web server configuration done by administrators, which isn't really > itself a protocol or service although there might be something like SSH > or FTP involved, also unlikely to be replaced because it's what > administrators do for many other chores as well (and because REDIRECT > may not solve the entire need) > > If there are other approaches, I'm unaware of them, and it would help to > know. But if these are the only cases than I have a different evaluation > of whether implementors will change current mechanisms. Lisa, I don't think it's relevant whether implementors will *change* current mechanisms. Why would they? The question is whether there's a use case for a HTTP-client driven mechanism, which could be implemented *in addition* to what the server already does. Looking at Apache/moddav, it seems that MKREDIRECT and UPDATEREDIRECT could be implemented in mod_alias (adding and updating entries in .htaccess, for example). It's a bit unclear to me what exactly your point is. Yes, server admins can already author redirects, so there are other ways to create these redirects than HTTP. The same could be said about WebDAV, so why did we bother defining that? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Jun 16 16:27: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 QAA10744 for ; Thu, 16 Jun 2005 16:27:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dj0wR-0003A1-8B for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 20:26:23 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Dj0kO-0008Fs-Sd for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 20:13:56 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by lisa.w3.org with esmtp (Exim 4.50) id 1Dj0kM-0001LS-B7 for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 20:13:56 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id B7B2E142270; Thu, 16 Jun 2005 13:10:53 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16907-10; Thu, 16 Jun 2005 13:10:53 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id A286E14226E; Thu, 16 Jun 2005 13:10:51 -0700 (PDT) In-Reply-To: <42B1D898.9080105@gmx.de> References: <87c5235f9ea00705fa41612b47577368@osafoundation.org> <42B1D898.9080105@gmx.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Thu, 16 Jun 2005 13:13:50 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: lisa.w3.org 1Dj0kM-0001LS-B7 b23b7ef4d061f6dc5ab24979635015b7 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/e94ca939f2a19fb973960eee0f36de2b@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9681 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 20:26:23 +0000 Content-Transfer-Encoding: 7bit > It's a bit unclear to me what exactly your point is. Yes, server > admins can already author redirects, so there are other ways to create > these redirects than HTTP. The same could be said about WebDAV, so why > did we bother defining that? > Because there was a clear need for client interoperability in the general case of authoring Web content: several volunteer editors each from different possible implementors, several other participants who were also implementors. It wasn't a large community of implementors (not compared to other WGs I've participated in, like SIP) but it was large enough to make the work not only clearly useful but also validated by more than one implementation model and by a set of use cases that mattered to more than one implementation. Lisa From w3c-dist-auth-request@frink.w3.org Thu Jun 16 17:05: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 RAA15768 for ; Thu, 16 Jun 2005 17:05:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dj1Xk-0004pH-G6 for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 21:04:56 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dj1Li-0001UX-FV for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 20:52:30 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1Dj1Le-0002oW-QS for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 20:52:30 +0000 Received: (qmail invoked by alias); 16 Jun 2005 20:52:24 -0000 Received: from p508F9F05.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.159.5] by mail.gmx.net (mp018) with SMTP; 16 Jun 2005 22:52:24 +0200 X-Authenticated: #1915285 Message-ID: <42B1E680.9070508@gmx.de> Date: Thu, 16 Jun 2005 22:52:16 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Geoffrey M Clemm , webdav References: <87c5235f9ea00705fa41612b47577368@osafoundation.org> <42B1D898.9080105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: bart.w3.org 1Dj1Le-0002oW-QS 9bbc4f45f60f1368dbd66038454c0ada X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/42B1E680.9070508@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9682 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 21:04:56 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > >> It's a bit unclear to me what exactly your point is. Yes, server >> admins can already author redirects, so there are other ways to create >> these redirects than HTTP. The same could be said about WebDAV, so why >> did we bother defining that? >> > > Because there was a clear need for client interoperability in the > general case of authoring Web content: several volunteer editors each > from different possible implementors, several other participants who > were also implementors. It wasn't a large community of implementors > (not compared to other WGs I've participated in, like SIP) but it was > large enough to make the work not only clearly useful but also validated > by more than one implementation model and by a set of use cases that > mattered to more than one implementation. I think there is clearly a need for discovery of redirects, that is clarifications about the relation between redirects and WebDAV's extensions. Today, the behaviour of servers that have redirects inside WebDAV collections is unspecified, and clients *do* expose strange behaviour because of that. Of course we can argue about whether we need a standard protocol to *author* redirects. At the end of the day, the question should be "is this harmful?" or "is it useful?". IMHO it's not harmful at all, because nobody is forced to implement it. But it is certainly useful, because it gives implementors a well-defined protocol that they *can* implement instead of coming up with proprietary extensions. So is the lack of server support for HTTP-authorable redirects caused by the fact nobody needs it, or is it simply because implementors actually wait for this WG to actually finish and publish the spec? Best regards, Julian From w3c-dist-auth-request@frink.w3.org Thu Jun 16 17:18: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 RAA16672 for ; Thu, 16 Jun 2005 17:18:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dj1jq-00083x-Dk for w3c-dist-auth-dist@listhub.w3.org; Thu, 16 Jun 2005 21:17:26 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Dj1TD-0003cx-Lt for w3c-dist-auth@listhub.w3.org; Thu, 16 Jun 2005 21:00:15 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by maggie.w3.org with esmtp (Exim 4.50) id 1Dj1TA-0002mP-On for w3c-dist-auth@w3.org; Thu, 16 Jun 2005 21:00:17 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id F0AD6142270; Thu, 16 Jun 2005 13:57:08 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18908-05; Thu, 16 Jun 2005 13:57:08 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 5292714226E; Thu, 16 Jun 2005 13:57:07 -0700 (PDT) In-Reply-To: <42B1E680.9070508@gmx.de> References: <87c5235f9ea00705fa41612b47577368@osafoundation.org> <42B1D898.9080105@gmx.de> <42B1E680.9070508@gmx.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Geoffrey M Clemm , webdav From: Lisa Dusseault Date: Thu, 16 Jun 2005 14:00:02 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.3 X-W3C-Scan-Sig: maggie.w3.org 1Dj1TA-0002mP-On 20f6401093ce8e642c64566edf1686b9 X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/ae4d3dd83079e766ff498f498c5f04d8@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9683 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 16 Jun 2005 21:17:26 +0000 Content-Transfer-Encoding: 7bit I don't really know what's causing the lack of implementor participation in redirects -- it could be total lack of interest or simply "wait and see". But as far as I can tell there is a difference between the level of interest in redirect and the level of interest in bind and quota, which both do seem to have the minimum amount of implementor interest. Lisa On Jun 16, 2005, at 1:52 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >>> It's a bit unclear to me what exactly your point is. Yes, server >>> admins can already author redirects, so there are other ways to >>> create these redirects than HTTP. The same could be said about >>> WebDAV, so why did we bother defining that? >>> >> Because there was a clear need for client interoperability in the >> general case of authoring Web content: several volunteer editors each >> from different possible implementors, several other participants who >> were also implementors. It wasn't a large community of implementors >> (not compared to other WGs I've participated in, like SIP) but it was >> large enough to make the work not only clearly useful but also >> validated by more than one implementation model and by a set of use >> cases that mattered to more than one implementation. > > I think there is clearly a need for discovery of redirects, that is > clarifications about the relation between redirects and WebDAV's > extensions. Today, the behaviour of servers that have redirects inside > WebDAV collections is unspecified, and clients *do* expose strange > behaviour because of that. > > Of course we can argue about whether we need a standard protocol to > *author* redirects. At the end of the day, the question should be "is > this harmful?" or "is it useful?". IMHO it's not harmful at all, > because nobody is forced to implement it. But it is certainly useful, > because it gives implementors a well-defined protocol that they *can* > implement instead of coming up with proprietary extensions. > > So is the lack of server support for HTTP-authorable redirects caused > by the fact nobody needs it, or is it simply because implementors > actually wait for this WG to actually finish and publish the spec? > > > Best regards, Julian > From w3c-dist-auth-request@frink.w3.org Fri Jun 17 01:22:05 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 BAA22217 for ; Fri, 17 Jun 2005 01:22:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dj9Fs-0000vO-Te for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Jun 2005 05:19:00 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Dj9Fk-0000ta-Vs for w3c-dist-auth@listhub.w3.org; Fri, 17 Jun 2005 05:18:52 +0000 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by lisa.w3.org with esmtp (Exim 4.50) id 1Dj9Fh-0005KU-EM for w3c-dist-auth@w3.org; Fri, 17 Jun 2005 05:18:52 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2005 22:18:48 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5H5IkTc006817 for ; Thu, 16 Jun 2005 22:18:47 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 22:21:06 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 16 Jun 2005 18:06:10 -0700 From: Cullen Jennings To: WebDav Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jun 2005 05:21:06.0382 (UTC) FILETIME=[5CC756E0:01C572FC] X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: lisa.w3.org 1Dj9Fh-0005KU-EM b2a96ca8b0f13ec6e874d5f557397b4b X-Original-To: w3c-dist-auth@w3.org Subject: Meeting time at Paris IETF X-Archived-At: http://www.w3.org/mid/BED77012.3E7A6%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9684 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Jun 2005 05:19:00 +0000 Content-Transfer-Encoding: 7bit I am assuming that it does not make sense to get together in the official agenda time at the next IETF. I will not be requesting a time slot. If folks violently disagree with this, let me know. Cullen From w3c-dist-auth-request@frink.w3.org Fri Jun 17 12:37:05 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 MAA02696 for ; Fri, 17 Jun 2005 12:37:05 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DjJob-0007Rm-GS for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Jun 2005 16:35:33 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DjJoX-0007R5-5a for w3c-dist-auth@listhub.w3.org; Fri, 17 Jun 2005 16:35:29 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by bart.w3.org with esmtp (Exim 4.50) id 1DjJoU-0006bH-LD for w3c-dist-auth@w3.org; Fri, 17 Jun 2005 16:35:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 09:35:26 -0700 X-IronPort-AV: i="3.93,208,1115017200"; d="scan'208"; a="280039859:sNHT25251356" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5HGZOQ3011991 for ; Fri, 17 Jun 2005 09:35:24 -0700 (PDT) Received: from 10.32.130.34 ([10.32.130.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jun 2005 16:37:44 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 17 Jun 2005 09:35:23 -0700 From: Cullen Jennings To: WebDav Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: bart.w3.org 1DjJoU-0006bH-LD 2aa526feb95e2d998d117b0254bc57e6 X-Original-To: w3c-dist-auth@w3.org Subject: Additional web page X-Archived-At: http://www.w3.org/mid/BED849DB.3E9F7%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9685 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Jun 2005 16:35:33 +0000 Content-Transfer-Encoding: 7bit In addition to the main WG web page at http://www.ietf.org/html.charters/webdav-charter.html many groups have another web site. Silly questions but, does this group have a site like this? It does not seem to be listed on charter page. Is it webdav.org? Should we have one? I like having a place I can put links to all the drafts, rfcs, and notes from meetings. Cullen PS - I won't even bother to point out that it is more or less mandatory that there is one particular protocol that WG members must be able to use to update this site :-) From w3c-dist-auth-request@frink.w3.org Fri Jun 17 12:43: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 MAA03332 for ; Fri, 17 Jun 2005 12:43:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DjJvS-0008S4-6t for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Jun 2005 16:42:38 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DjJvM-0008Qv-1R for w3c-dist-auth@listhub.w3.org; Fri, 17 Jun 2005 16:42:32 +0000 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by maggie.w3.org with esmtp (Exim 4.50) id 1DjJvK-0000JB-9M for w3c-dist-auth@w3.org; Fri, 17 Jun 2005 16:42:34 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2005 09:42:26 -0700 X-IronPort-AV: i="3.93,208,1115017200"; d="scan'208"; a="644294190:sNHT38140708" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5HGgKQ5016360 for ; Fri, 17 Jun 2005 09:42:24 -0700 (PDT) Received: from 10.32.130.34 ([10.32.130.34]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jun 2005 16:44:44 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 17 Jun 2005 09:42:23 -0700 From: Cullen Jennings To: WebDav Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: maggie.w3.org 1DjJvK-0000JB-9M d09c5c41c55d0019e9a9f43aad399747 X-Original-To: w3c-dist-auth@w3.org Subject: FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France X-Archived-At: http://www.w3.org/mid/BED84B7F.3EA04%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9686 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Jun 2005 16:42:38 +0000 Content-Transfer-Encoding: 7bit I am assuming that there will be no new 00 WG documents submitted over the next several months. Redirect, quota, bind, and bis are already all WG documents. If I am off base on this, let me know. Cullen ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 17 Jun 2005 00:00:02 -0400 To: Working Group Chairs Subject: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org. We would appreciate receiving your list of approved drafts four (4) business days prior to the cutoff date for -00 submissions, or by Tuesday, July 5th at 9:00 AM ET for the 63rd IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. ------ End of Forwarded Message From w3c-dist-auth-request@frink.w3.org Fri Jun 17 12:46: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 MAA03436 for ; Fri, 17 Jun 2005 12:46:00 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DjJyA-0000oN-E6 for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Jun 2005 16:45:26 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DjJxm-0000R1-O7 for w3c-dist-auth@listhub.w3.org; Fri, 17 Jun 2005 16:45:02 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1DjJxj-0000lz-Mz for w3c-dist-auth@w3.org; Fri, 17 Jun 2005 16:45:02 +0000 Received: (qmail invoked by alias); 17 Jun 2005 16:44:57 -0000 Received: from p508F8006.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.128.6] by mail.gmx.net (mp017) with SMTP; 17 Jun 2005 18:44:57 +0200 X-Authenticated: #1915285 Message-ID: <42B2FE02.9010705@gmx.de> Date: Fri, 17 Jun 2005 18:44:50 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1DjJxj-0000lz-Mz c59b565663670f109292cff2768945c1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Additional web page X-Archived-At: http://www.w3.org/mid/42B2FE02.9010705@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9687 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Jun 2005 16:45:26 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > In addition to the main WG web page at > http://www.ietf.org/html.charters/webdav-charter.html many groups have > another web site. Silly questions but, does this group have a site like > this? It does not seem to be listed on charter page. Is it webdav.org? > Should we have one? > > I like having a place I can put links to all the drafts, rfcs, and notes > from meetings. > > Cullen > > PS - I won't even bother to point out that it is more or less mandatory that > there is one particular protocol that WG members must be able to use to > update this site :-) Cullen, yes, that's www.webdav.org. And yes, it's running with Apache/moddav, so we are eaiting our own dog food. Not all of the specs are maintained there, though. For instance, BIND is, while REDIRECT is not (should I fix that?). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Jun 17 12:50: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 MAA03720 for ; Fri, 17 Jun 2005 12:50:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DjK2e-00045I-Ms for w3c-dist-auth-dist@listhub.w3.org; Fri, 17 Jun 2005 16:50:04 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DjK2Z-0003gf-V4 for w3c-dist-auth@listhub.w3.org; Fri, 17 Jun 2005 16:49:59 +0000 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1DjK25-0000eN-CI for w3c-dist-auth@w3.org; Fri, 17 Jun 2005 16:49:59 +0000 Received: (qmail invoked by alias); 17 Jun 2005 16:49:27 -0000 Received: from p508F8006.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.128.6] by mail.gmx.net (mp015) with SMTP; 17 Jun 2005 18:49:27 +0200 X-Authenticated: #1915285 Message-ID: <42B2FF14.1000404@gmx.de> Date: Fri, 17 Jun 2005 18:49:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-1.1 X-W3C-Scan-Sig: bart.w3.org 1DjK25-0000eN-CI 1583ac3d39ccf37d23d3a0eb1b5e359b X-Original-To: w3c-dist-auth@w3.org Subject: Re: FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France X-Archived-At: http://www.w3.org/mid/42B2FF14.1000404@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9688 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 17 Jun 2005 16:50:04 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I am assuming that there will be no new 00 WG documents submitted over the > next several months. Redirect, quota, bind, and bis are already all WG > documents. If I am off base on this, let me know. > > Cullen No, that's right. We even should be able to squeeze in updated versions of BIND/REDRECT/QUOTA when needed in time. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Sun Jun 19 07:38: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 HAA28001 for ; Sun, 19 Jun 2005 07:38:36 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Djy5K-0007wH-W3 for w3c-dist-auth-dist@listhub.w3.org; Sun, 19 Jun 2005 11:35:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1Djy5H-0007vh-CK for w3c-dist-auth@listhub.w3.org; Sun, 19 Jun 2005 11:35:27 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1Djy5D-0002rM-Oq for w3c-dist-auth@w3.org; Sun, 19 Jun 2005 11:35:27 +0000 Received: (qmail invoked by alias); 19 Jun 2005 11:35:19 -0000 Received: from p508FA3E4.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.163.228] by mail.gmx.net (mp012) with SMTP; 19 Jun 2005 13:35:19 +0200 X-Authenticated: #1915285 Message-ID: <42B5586F.6060309@gmx.de> Date: Sun, 19 Jun 2005 13:35:11 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav , Geoffrey M Clemm , Jim Whitehead , ccjason@us.ibm.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1Djy5D-0002rM-Oq 869afff627aba3fdd404653776206c4a X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-bind-11 X-Archived-At: http://www.w3.org/mid/42B5586F.6060309@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9689 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 19 Jun 2005 11:35:30 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I would like to start working group last call on > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-11.txt > > This WGCL will end on July 4th so please have your comments emailed to this > list before then. > > Thank you, Cullen Being one of the authors, it won't surprise anybody that I do not have any issues with the current draft. For the sake of completeness, I'l like to point to one issue where there seems to be an unresolved controversy. The question is: can the BIND spec make any requirements on the behaviour of live properties it doesn't define itself? After long discussion (and important contributions from Roy Fielding who stepped in when we went the wrong way), the answer is "no". Furthermore it turns out that the problem of describing live property behaviour for multiple URIs mapped to the same resource is related to the issue how these properties behave under namespace operations (such as MOVE). Thus, one could argue, makes it a RFC2518bis issue instead. I wrote a summary in (which in turn links to ). If people feel that the spec indeed should say anything at all about this topic, they should re-read the discussion now. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Mon Jun 20 13:06: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 NAA18802 for ; Mon, 20 Jun 2005 13:06:08 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DkPgX-0004Kp-Tg for w3c-dist-auth-dist@listhub.w3.org; Mon, 20 Jun 2005 17:03:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1DkPgS-0004KG-JD for w3c-dist-auth@listhub.w3.org; Mon, 20 Jun 2005 17:03:40 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by maggie.w3.org with esmtp (Exim 4.50) id 1DkPgP-0000DW-Bv for w3c-dist-auth@w3.org; Mon, 20 Jun 2005 17:03:42 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 8409B142267 for ; Mon, 20 Jun 2005 09:59:57 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25890-04 for ; Mon, 20 Jun 2005 09:59:57 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 20289142266 for ; Mon, 20 Jun 2005 09:59:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: webdav WG From: Lisa Dusseault Date: Sun, 19 Jun 2005 13:04:26 -0700 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-1.9 X-W3C-Scan-Sig: maggie.w3.org 1DkPgP-0000DW-Bv e7fa013c141d11b110f6b1be31c8abfc X-Original-To: w3c-dist-auth@w3.org Subject: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/bef0c930ba496386b1f0a453d8a9bcb9@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9690 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 20 Jun 2005 17:03:45 +0000 Content-Transfer-Encoding: 7bit As Julian recently noted, the behavior of live properties on bindings (or on resources with multiple bindings) has been raised. I still don't consider the issue closed and since we're reraising these issues, I wanted to methodically consider some of the implications of requiring consistency, of explicitly allowing variation, or of the spec remaining silent. Important note: Some of the confusion around these properties is increased by lack of explicitness in RFC2518 (source, displayname in particular). If BIND depends on RFC2518 instead of 2518bis, that may have different implications for our decisions about the consistency of property values across bindings. As we've discussed before, there's a certain amount of clarification that should be added to 2518bis about whether properties apply to underlying resources, but if BIND is issued as an RFC depending on 2518, before 2518bis is issued, then BIND implementors won't be able to benefit from clarifications in 2518bis. DAV:getcontentlanguage DAV:getcontentlength DAV:getcontenttype RFC2518 defines these as the values returned in a GET response in the Content-Language, Content-Length and Content-Type headers, so the value of this property can vary on bindings only if the GET response also varies on bindings. Yet, the BIND spec doesn't require that the GET response be the same regardless of binding URL used. A server could conceivably see bindings as a creative way of handling variant access or access to source/output versions of a dynamic resource, because bindings would allow a bindings-aware client to discover the other URLs and possibly to modify variants or source. I wouldn't say I recommend this approach but it's not forbidden. - We don't have evidence so far that any implementations do anything other than keep these values consistent across bindings. - If the spec says that the values MUST be the same on all bindings, then servers can't implement odd features like using one binding to get to the German version of a resource, and the other binding to get the French version. That seems fine to me, there are other, probably better ways of handling access to variants and source/output than using bindings. - If the spec explicitly allows variation, then clients must download the property separately for each binding if they care about it, and we might want to say something about why they could vary. - If the spec remains silent, we're unlikely to see odd implementations of this but it's conceivable. A cautious and perceptive client implementor would behave as if it could differ and download the property an extra time for every binding. DAV:getetag Although RFC2518 says that this is tied to the ETag header value in a GET response, this is a little different than the last three, because it's perfectly conceivable for two URLs to have the same GET response (byte for byte) and yet have different ETag values. - We have evidence that server implementations use the URL to calculate the ETag, so presumably it would be easiest for those to continue that behavior. OTOH some server implementations only base the ETag on resource characteristics, not on bindings. - If the spec says that the value MUST be the same on all bindings, then this makes for the easiest and most efficient client synchronization operations. OTOH a few server implementations must change a little bit to correctly implement BIND. I think this is fine -- a minor server burden for increased efficiency and simplicity. - If the spec explicitly allows variation, then clients must behave as if it does vary in order to interoperate against different servers. In some situations the client will have to query the ETag on several bindings to the same resource to verify whether it needs to resynchronize the resource, resulting in more roundtrips. Of course the client is likely to behave the same way with all servers supporting bindings even if the ETag doesn't vary according to URL. - If the spec is silent, then a cautious and perceptive client implementor would behave as if the property could differ and do the extra work -- again, possibly unnecessary. DAV:supportedlock DAV:lockdiscovery Since the BIND spec clearly states that locks are on resources, not on URLs, it's a pretty obvious assumption that the values of the lock-related properties must also be related to resources and not vary depending on URL. - If the spec states that the value MUST be the same on all bindings, I see no harm. - If the spec explicitly allows variation, that would be pretty weird. I'm not sure what we would say to justify that. - If the spec remained silent, well, probably no harm, that would only be weird if the spec were explicit about other property behaviors. DAV:creationdate RFC2518 defined this property and didn't tie it to any locking or GET request behavior, and it isn't used for synchronization or cache refreshes. Thus we have little to guide us on behavior but OTOH probably not a lot of problems caused if we go either way. - If the spec states that the value MUST be the same on all bindings and that it MUST be the date the resource was first created (e.g. with PUT), then this is the best case for people viewing creationdate (as some clients already display it). It makes most sense to the person that creation date be the date of first uploading the content. - If the spec states that the value MUST be the same on all bindings and that it MUST be the date the last binding was created that could be a little weird. - If the spec explicitly allows different bindings to have different creationdate values then this implies that the creationdate is the date of creation of the binding. That's not unreasonable. Presumably a client could find the oldest binding and use its creationdate as the resource creationdate. - If the spec is silent then we really don't know if creation date refers to creation of the resource or of the binding. A person using a client that simply displays the value might notice the different behaviours on different servers. A document retention or document archival program might produce quite different results depending on how this was implemented. A cautious and perceptive client or agent implementor would have to assume that they might vary and would have to check all bindings. OTOH there are already clients and archival programs which aren't aware of bindings and these would have to be upgraded to check the creationdate on different bindings in order to regain predictable behavior. DAV:getlastmodified Again, RFC2518 defines this as the value of the Last-Modified header on the GET request, but the server has a lot of leeway to set this to the last time the underlying resource was changed, or to update this when a new binding is created -- perhaps only the newest binding would have a different value because it was created after the underlying resource was last changed. - The implementations I know of would probably treat this as the time the underlying resource body was last modified. - If the spec states that this value MUST be the same on all bindings, and that it MUST reflect only changes to the body of the underlying resource, that would be the most clear and useful statement for clients -- clients could simply display this and users would easily be able to confirm that if this value changed then somebody had changed the body of the resource. Servers would have to implement this in the same way when they add BIND support and I'm not aware of any problems that would cause. Clients might sometimes see a new URL appear in a collection on date D2, when the last-modified time is a timestamp D1 from much earlier (before the client last synchronized, for example), but that seems unlikely to cause bugs. - If the spec explicitly allows this to vary then the spec probably has to say something about what that means. - If the spec remains silent, then a cautious and perceptive client implementor would have to assume that it could mean anything. I'm not sure if it would be best to download all the different bindings' getlastmodified times to see if they're different. If they are different, what would the client do? Display the earliest one? The latest one? Which value would be most helpful to the user? Again, existing document archive and retention programs would probably show different behavior if servers end up calculating this property in different ways. DAV:displayname RFC2518 underspecifies this property and we know the problems that has caused. Nevertheless BIND could say something here. - We do have implementation evidence that some implementations calculate display name from the URL, thus it could conceivably vary according to binding. We also know some implementations store display name as if it were a dead property, thus it would not vary according to binding. - If the spec says that displayname MUST be consistent across bindings, then some implementations would have to change the way they calculate displayname in order to implement BIND. I would argue that would be a good thing and would help alleviate the uncertainty in RFC2518. - If the spec explicitly allows this to vary, that implicitly supports the calculated displayname model. Probably, however, servers which keep the value consistent would continue to do so. - If the spec is silent, then a cautious and perceptive client implementor would have to assume that displayname could vary and download it again for every binding if the client needs this property. DAV:source This property isn't widely implemented so it's hard to make any statements about implementations or about implications of consistency across bindings. General case It would be best if BIND could say something about the general case of live properties even if it leaves some leeway for future live properties to be defined as exceptions to the general case. Based on looking at the live properties defined in RFC2518, we could define those as being the same values across all bindings. The consequences of this would be more consistent and clear server behavior and easier client implementations, at the cost of some server implementations having to change a few things in order to become compliant with BIND. It's conceivable that such a clear requirement would rule out some imaginative and odd ways of implementing new or custom functionality based on bindings and existing live properties, which might not be a bad thing. A clear requirement for existing live properties to have the same values on all bindings could still allow for exceptions for new live properties defined differently, and thus not close off future innovation. Lisa From w3c-dist-auth-request@frink.w3.org Tue Jun 21 05:30: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 FAA27670 for ; Tue, 21 Jun 2005 05:30:14 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dkf32-000307-2Z for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Jun 2005 09:28:00 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dkf2u-0002yY-GL for w3c-dist-auth@listhub.w3.org; Tue, 21 Jun 2005 09:27:52 +0000 Received: from [217.5.201.10] (helo=greenbytes.de) by bart.w3.org with esmtp (Exim 4.50) id 1Dkf2o-0006Ek-Pp for w3c-dist-auth@w3.org; Tue, 21 Jun 2005 09:27:52 +0000 Received: from [192.168.1.90] by greenbytes.de (MDaemon.PRO.v8.0.2.T) with ESMTP id md50000115204.msg for ; Tue, 21 Jun 2005 11:24:00 +0200 Message-ID: <42B7DCAE.1060101@greenbytes.de> Date: Tue, 21 Jun 2005 11:23:58 +0200 From: Manfred Baedke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: webdav WG References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030600020707070901000402" X-Authenticated-Sender: MBaedke@greenbytes.de X-Spam-Processed: greenbytes.de, Tue, 21 Jun 2005 11:24:00 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.90 X-Return-Path: manfred.baedke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1Dkf2o-0006Ek-Pp ffa250c0dd3073b2c85c532493abdb5c X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/42B7DCAE.1060101@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9691 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jun 2005 09:28:00 +0000 This is a multi-part message in MIME format. --------------030600020707070901000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, As a mere implementor, I have never posted on this list before, but now I am getting a little worried. I have been working on a specific backend for the SAP Netweaver WebDav server that does not (and never will) implement BIND. But it does implement large parts of RFC 3253. In particular it supports the Version-Controlled-Collection feature, which forces the existence of multiple bindings of the same resource in some cases. Our implementation neither implements BIND nor a spec depending on BIND. So I really do not want BIND to put any constraints on our implementation. The existence of multiple bindings has nothing to do with the existence of the BIND method. The BIND spec is the wrong place to describe the behavior of properties that are defined by other specifications under methods that are defined by other specifications. Regards, Manfred Lisa Dusseault wrote: > > As Julian recently noted, the behavior of live properties on bindings > (or on resources with multiple bindings) has been raised. I still don't > consider the issue closed and since we're reraising these issues, I > wanted to methodically consider some of the implications of requiring > consistency, of explicitly allowing variation, or of the spec remaining > silent. > > Important note: Some of the confusion around these properties is > increased by lack of explicitness in RFC2518 (source, displayname in > particular). If BIND depends on RFC2518 instead of 2518bis, that may > have different implications for our decisions about the consistency of > property values across bindings. As we've discussed before, there's a > certain amount of clarification that should be added to 2518bis about > whether properties apply to underlying resources, but if BIND is issued > as an RFC depending on 2518, before 2518bis is issued, then BIND > implementors won't be able to benefit from clarifications in 2518bis. > > DAV:getcontentlanguage > DAV:getcontentlength > DAV:getcontenttype > > RFC2518 defines these as the values returned in a GET response in the > Content-Language, Content-Length and Content-Type headers, so the value > of this property can vary on bindings only if the GET response also > varies on bindings. Yet, the BIND spec doesn't require that the GET > response be the same regardless of binding URL used. A server could > conceivably see bindings as a creative way of handling variant access or > access to source/output versions of a dynamic resource, because bindings > would allow a bindings-aware client to discover the other URLs and > possibly to modify variants or source. I wouldn't say I recommend this > approach but it's not forbidden. > - We don't have evidence so far that any implementations do anything > other than keep these values consistent across bindings. > - If the spec says that the values MUST be the same on all bindings, > then servers can't implement odd features like using one binding to get > to the German version of a resource, and the other binding to get the > French version. That seems fine to me, there are other, probably > better ways of handling access to variants and source/output than using > bindings. > - If the spec explicitly allows variation, then clients must download > the property separately for each binding if they care about it, and we > might want to say something about why they could vary. > - If the spec remains silent, we're unlikely to see odd implementations > of this but it's conceivable. A cautious and perceptive client > implementor would behave as if it could differ and download the property > an extra time for every binding. > > DAV:getetag > > Although RFC2518 says that this is tied to the ETag header value in a > GET response, this is a little different than the last three, because > it's perfectly conceivable for two URLs to have the same GET response > (byte for byte) and yet have different ETag values. > - We have evidence that server implementations use the URL to calculate > the ETag, so presumably it would be easiest for those to continue that > behavior. OTOH some server implementations only base the ETag on > resource characteristics, not on bindings. > - If the spec says that the value MUST be the same on all bindings, > then this makes for the easiest and most efficient client > synchronization operations. OTOH a few server implementations must > change a little bit to correctly implement BIND. I think this is fine > -- a minor server burden for increased efficiency and simplicity. > - If the spec explicitly allows variation, then clients must behave as > if it does vary in order to interoperate against different servers. In > some situations the client will have to query the ETag on several > bindings to the same resource to verify whether it needs to > resynchronize the resource, resulting in more roundtrips. Of course the > client is likely to behave the same way with all servers supporting > bindings even if the ETag doesn't vary according to URL. > - If the spec is silent, then a cautious and perceptive client > implementor would behave as if the property could differ and do the > extra work -- again, possibly unnecessary. > > DAV:supportedlock > DAV:lockdiscovery > > Since the BIND spec clearly states that locks are on resources, not on > URLs, it's a pretty obvious assumption that the values of the > lock-related properties must also be related to resources and not vary > depending on URL. > - If the spec states that the value MUST be the same on all bindings, I > see no harm. > - If the spec explicitly allows variation, that would be pretty weird. > I'm not sure what we would say to justify that. > - If the spec remained silent, well, probably no harm, that would only > be weird if the spec were explicit about other property behaviors. > > DAV:creationdate > > RFC2518 defined this property and didn't tie it to any locking or GET > request behavior, and it isn't used for synchronization or cache > refreshes. Thus we have little to guide us on behavior but OTOH > probably not a lot of problems caused if we go either way. > - If the spec states that the value MUST be the same on all bindings > and that it MUST be the date the resource was first created (e.g. with > PUT), then this is the best case for people viewing creationdate (as > some clients already display it). It makes most sense to the person > that creation date be the date of first uploading the content. > - If the spec states that the value MUST be the same on all bindings > and that it MUST be the date the last binding was created that could be > a little weird. > - If the spec explicitly allows different bindings to have different > creationdate values then this implies that the creationdate is the date > of creation of the binding. That's not unreasonable. Presumably a > client could find the oldest binding and use its creationdate as the > resource creationdate. > - If the spec is silent then we really don't know if creation date > refers to creation of the resource or of the binding. A person using a > client that simply displays the value might notice the different > behaviours on different servers. A document retention or document > archival program might produce quite different results depending on how > this was implemented. A cautious and perceptive client or agent > implementor would have to assume that they might vary and would have to > check all bindings. OTOH there are already clients and archival > programs which aren't aware of bindings and these would have to be > upgraded to check the creationdate on different bindings in order to > regain predictable behavior. > > DAV:getlastmodified > > Again, RFC2518 defines this as the value of the Last-Modified header on > the GET request, but the server has a lot of leeway to set this to the > last time the underlying resource was changed, or to update this when a > new binding is created -- perhaps only the newest binding would have a > different value because it was created after the underlying resource was > last changed. > - The implementations I know of would probably treat this as the time > the underlying resource body was last modified. > - If the spec states that this value MUST be the same on all bindings, > and that it MUST reflect only changes to the body of the underlying > resource, that would be the most clear and useful statement for clients > -- clients could simply display this and users would easily be able to > confirm that if this value changed then somebody had changed the body of > the resource. Servers would have to implement this in the same way when > they add BIND support and I'm not aware of any problems that would > cause. Clients might sometimes see a new URL appear in a collection on > date D2, when the last-modified time is a timestamp D1 from much earlier > (before the client last synchronized, for example), but that seems > unlikely to cause bugs. > - If the spec explicitly allows this to vary then the spec probably has > to say something about what that means. > - If the spec remains silent, then a cautious and perceptive client > implementor would have to assume that it could mean anything. I'm not > sure if it would be best to download all the different bindings' > getlastmodified times to see if they're different. If they are > different, what would the client do? Display the earliest one? The > latest one? Which value would be most helpful to the user? Again, > existing document archive and retention programs would probably show > different behavior if servers end up calculating this property in > different ways. > > DAV:displayname > > RFC2518 underspecifies this property and we know the problems that has > caused. Nevertheless BIND could say something here. > - We do have implementation evidence that some implementations > calculate display name from the URL, thus it could conceivably vary > according to binding. We also know some implementations store display > name as if it were a dead property, thus it would not vary according to > binding. > - If the spec says that displayname MUST be consistent across bindings, > then some implementations would have to change the way they calculate > displayname in order to implement BIND. I would argue that would be a > good thing and would help alleviate the uncertainty in RFC2518. > - If the spec explicitly allows this to vary, that implicitly supports > the calculated displayname model. Probably, however, servers which keep > the value consistent would continue to do so. > - If the spec is silent, then a cautious and perceptive client > implementor would have to assume that displayname could vary and > download it again for every binding if the client needs this property. > > DAV:source > > This property isn't widely implemented so it's hard to make any > statements about implementations or about implications of consistency > across bindings. > > General case > > It would be best if BIND could say something about the general case of > live properties even if it leaves some leeway for future live properties > to be defined as exceptions to the general case. Based on looking at the > live properties defined in RFC2518, we could define those as being the > same values across all bindings. The consequences of this would be more > consistent and clear server behavior and easier client implementations, > at the cost of some server implementations having to change a few things > in order to become compliant with BIND. It's conceivable that such a > clear requirement would rule out some imaginative and odd ways of > implementing new or custom functionality based on bindings and existing > live properties, which might not be a bad thing. A clear requirement > for existing live properties to have the same values on all bindings > could still allow for exceptions for new live properties defined > differently, and thus not close off future innovation. > > Lisa > > --------------030600020707070901000402 Content-Type: text/x-vcard; charset=utf-8; name="manfred.baedke.vcf" Content-Disposition: attachment; filename="manfred.baedke.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Manfred Baedke n:Baedke;Manfred org:greenbytes GmbH adr;quoted-printable;quoted-printable:;;Salzmannstra=C3=9Fe 152;M=C3=BCnster;;48159;germany email;internet:manfred.baedke@greenbytes.de tel;work:+492512807762 tel;fax:+492512807761 tel;home:+49251795369 tel;cell:+491722974356 x-mozilla-html:FALSE url:http://www.greenbytes.de version:2.1 end:vcard --------------030600020707070901000402-- From w3c-dist-auth-request@frink.w3.org Tue Jun 21 11:38: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 LAA01668 for ; Tue, 21 Jun 2005 11:38:40 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DkkoM-0004r7-Nn for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Jun 2005 15:37:14 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DkkoJ-0004qO-IN for w3c-dist-auth@listhub.w3.org; Tue, 21 Jun 2005 15:37:11 +0000 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by bart.w3.org with esmtp (Exim 4.50) id 1DkkoG-0002YZ-HF for w3c-dist-auth@w3.org; Tue, 21 Jun 2005 15:37:11 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2005 08:37:07 -0700 X-IronPort-AV: i="3.93,218,1115017200"; d="scan'208"; a="281349362:sNHT28677516" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5LFauqs009291 for ; Tue, 21 Jun 2005 08:37:05 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 08:39:30 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 21 Jun 2005 08:34:39 -0700 From: Cullen Jennings To: WebDav Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 15:39:30.0348 (UTC) FILETIME=[6A1E3EC0:01C57677] X-W3C-Hub-Spam-Status: No, score=1.5 X-W3C-Scan-Sig: bart.w3.org 1DkkoG-0002YZ-HF 68a063dfde25539be058c78af93d168a X-Original-To: w3c-dist-auth@w3.org Subject: Comments on webdav-quota-07 X-Archived-At: http://www.w3.org/mid/BEDD819F.3EE69%25fluffy@cisco.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9692 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jun 2005 15:37:14 +0000 Content-Transfer-Encoding: 7bit I did a nits review on this draft. Ran idnits and there were no problems. I did not validate the XML - has anyone validated it? From w3c-dist-auth-request@frink.w3.org Tue Jun 21 12:14: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 MAA04610 for ; Tue, 21 Jun 2005 12:14:55 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DklO1-0005eI-QA for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Jun 2005 16:14:05 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DklNy-0005dk-6B for w3c-dist-auth@listhub.w3.org; Tue, 21 Jun 2005 16:14:02 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1DklNu-0000YV-A1 for w3c-dist-auth@w3.org; Tue, 21 Jun 2005 16:14:02 +0000 Received: (qmail invoked by alias); 21 Jun 2005 16:13:56 -0000 Received: from p508FACEB.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.172.235] by mail.gmx.net (mp012) with SMTP; 21 Jun 2005 18:13:56 +0200 X-Authenticated: #1915285 Message-ID: <42B83CC3.9030407@gmx.de> Date: Tue, 21 Jun 2005 18:13:55 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: WebDav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1DklNu-0000YV-A1 6bd58f9172f75898979627bb81efd4c1 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Comments on webdav-quota-07 X-Archived-At: http://www.w3.org/mid/42B83CC3.9030407@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9693 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jun 2005 16:14:05 +0000 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I did a nits review on this draft. Ran idnits and there were no problems. I > did not validate the XML - has anyone validated it? Yes, it's fine (). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Tue Jun 21 13:15: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 NAA08946 for ; Tue, 21 Jun 2005 13:15:15 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DkmK2-0003JI-Nd for w3c-dist-auth-dist@listhub.w3.org; Tue, 21 Jun 2005 17:14:02 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DkmJy-0003If-Il for w3c-dist-auth@listhub.w3.org; Tue, 21 Jun 2005 17:13:58 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.50) id 1DkmJt-0004vq-Jl for w3c-dist-auth@w3.org; Tue, 21 Jun 2005 17:13:58 +0000 Received: (qmail invoked by alias); 21 Jun 2005 17:13:51 -0000 Received: from p508FACEB.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.172.235] by mail.gmx.net (mp004) with SMTP; 21 Jun 2005 19:13:51 +0200 X-Authenticated: #1915285 Message-ID: <42B84ACD.2080608@gmx.de> Date: Tue, 21 Jun 2005 19:13:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: lisa.w3.org 1DkmJt-0004vq-Jl 45ad607996980cf6f4affb1cc6d0185d X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/42B84ACD.2080608@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9694 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 21 Jun 2005 17:14:02 +0000 Content-Transfer-Encoding: 7bit Lisa, thanks for the feedback. Let me make some base statements before I dig into the details: 1) If the spec can't be implemented within Apache/moddav on a Unix filesystem (using hard links), there's something wrong with the spec. In general, introducing new requirements not present in either RFC2616 or RFC2518 is a bad idea. 2) The behaviour of live properties for multiple URIs follows the same patterns as for plain HTTP/WebDAV when namespace operations such as MOVE are involved (see discussion in http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0001.html>). 3) I disagree that it is a problem when RFC2518bis (containing clarifications on live property behaviour) comes out after BIND; once it's officially updating RFC2518, this is what readers of the BIND spec should read (just like RFC3986 is now the current URI spec, and both RFC2518 and RFC2616 still point to older revisions). > As Julian recently noted, the behavior of live properties on bindings > (or on resources with multiple bindings) has been raised. I still don't > consider the issue closed and since we're reraising these issues, I > wanted to methodically consider some of the implications of requiring > consistency, of explicitly allowing variation, or of the spec remaining > silent. > > Important note: Some of the confusion around these properties is > increased by lack of explicitness in RFC2518 (source, displayname in > particular). If BIND depends on RFC2518 instead of 2518bis, that may > have different implications for our decisions about the consistency of > property values across bindings. As we've discussed before, there's a > certain amount of clarification that should be added to 2518bis about > whether properties apply to underlying resources, but if BIND is issued > as an RFC depending on 2518, before 2518bis is issued, then BIND > implementors won't be able to benefit from clarifications in 2518bis. ---> 3). > DAV:getcontentlanguage > DAV:getcontentlength > DAV:getcontenttype > > RFC2518 defines these as the values returned in a GET response in the > Content-Language, Content-Length and Content-Type headers, so the value > of this property can vary on bindings only if the GET response also > varies on bindings. Yet, the BIND spec doesn't require that the GET > response be the same regardless of binding URL used. A server could > conceivably see bindings as a creative way of handling variant access or > access to source/output versions of a dynamic resource, because bindings > would allow a bindings-aware client to discover the other URLs and > possibly to modify variants or source. I wouldn't say I recommend this > approach but it's not forbidden. > - We don't have evidence so far that any implementations do anything > other than keep these values consistent across bindings. > - If the spec says that the values MUST be the same on all bindings, > then servers can't implement odd features like using one binding to get > to the German version of a resource, and the other binding to get the > French version. That seems fine to me, there are other, probably > better ways of handling access to variants and source/output than using > bindings. > - If the spec explicitly allows variation, then clients must download > the property separately for each binding if they care about it, and we > might want to say something about why they could vary. > - If the spec remains silent, we're unlikely to see odd implementations > of this but it's conceivable. A cautious and perceptive client > implementor would behave as if it could differ and download the property > an extra time for every binding Agreed, except I'm not sure what you call "odd". If RFC2616 allows this behaviour, and RFC2616 ultimately defines the semantics of these properties, it's not up to us to decide what's "odd"... > DAV:getetag > > Although RFC2518 says that this is tied to the ETag header value in a > GET response, this is a little different than the last three, because > it's perfectly conceivable for two URLs to have the same GET response > (byte for byte) and yet have different ETag values. I don't agree here that it's different. DAV:etag is whatever the server returns upon GET as "ETag" response header. Same behaviour as for the above three. > - We have evidence that server implementations use the URL to calculate > the ETag, so presumably it would be easiest for those to continue that > behavior. OTOH some server implementations only base the ETag on > resource characteristics, not on bindings. Yes. Some really have unique ideas for each content body that's there, others compute it dynamically based on timestamps and such. > - If the spec says that the value MUST be the same on all bindings, > then this makes for the easiest and most efficient client > synchronization operations. OTOH a few server implementations must > change a little bit to correctly implement BIND. I think this is fine > -- a minor server burden for increased efficiency and simplicity. As I have pointed out multiple times (see link above), this does not work. Servers must have the freedom to adjust ETags because of namespace operations, so they also need to be able to do that for BIND. Could you *please* follow up on the analysis in ? Thanks. > - If the spec explicitly allows variation, then clients must behave as > if it does vary in order to interoperate against different servers. In > some situations the client will have to query the ETag on several > bindings to the same resource to verify whether it needs to > resynchronize the resource, resulting in more roundtrips. Of course the > client is likely to behave the same way with all servers supporting > bindings even if the ETag doesn't vary according to URL. Yes. > - If the spec is silent, then a cautious and perceptive client > implementor would behave as if the property could differ and do the > extra work -- again, possibly unnecessary. Yes. > DAV:supportedlock > DAV:lockdiscovery > > Since the BIND spec clearly states that locks are on resources, not on > URLs, it's a pretty obvious assumption that the values of the > lock-related properties must also be related to resources and not vary > depending on URL. > - If the spec states that the value MUST be the same on all bindings, I > see no harm. Agreed. > - If the spec explicitly allows variation, that would be pretty weird. > I'm not sure what we would say to justify that. I think that would be a bug. > - If the spec remained silent, well, probably no harm, that would only > be weird if the spec were explicit about other property behaviors. Yes. > DAV:creationdate > > RFC2518 defined this property and didn't tie it to any locking or GET > request behavior, and it isn't used for synchronization or cache > refreshes. Thus we have little to guide us on behavior but OTOH > probably not a lot of problems caused if we go either way. > - If the spec states that the value MUST be the same on all bindings > and that it MUST be the date the resource was first created (e.g. with > PUT), then this is the best case for people viewing creationdate (as > some clients already display it). It makes most sense to the person > that creation date be the date of first uploading the content. > - If the spec states that the value MUST be the same on all bindings > and that it MUST be the date the last binding was created that could be > a little weird. > - If the spec explicitly allows different bindings to have different > creationdate values then this implies that the creationdate is the date > of creation of the binding. That's not unreasonable. Presumably a > client could find the oldest binding and use its creationdate as the > resource creationdate. > - If the spec is silent then we really don't know if creation date > refers to creation of the resource or of the binding. A person using a > client that simply displays the value might notice the different > behaviours on different servers. A document retention or document > archival program might produce quite different results depending on how > this was implemented. A cautious and perceptive client or agent > implementor would have to assume that they might vary and would have to > check all bindings. OTOH there are already clients and archival > programs which aren't aware of bindings and these would have to be > upgraded to check the creationdate on different bindings in order to > regain predictable behavior. I disagree. DAV:resourcetype is defined by RFC2518 to be a property of the resource; and the whole point of the BIND spec is to define behaviours for multiple URIs mapped to the same resource. So it seems to be straighforward that the DAV:creationdate will be the same for all URLs (just like DAV:lockdiscovery). > DAV:getlastmodified > > Again, RFC2518 defines this as the value of the Last-Modified header on > the GET request, but the server has a lot of leeway to set this to the > last time the underlying resource was changed, or to update this when a > new binding is created -- perhaps only the newest binding would have a > different value because it was created after the underlying resource was > last changed. > - The implementations I know of would probably treat this as the time > the underlying resource body was last modified. > - If the spec states that this value MUST be the same on all bindings, > and that it MUST reflect only changes to the body of the underlying > resource, that would be the most clear and useful statement for clients > -- clients could simply display this and users would easily be able to > confirm that if this value changed then somebody had changed the body of > the resource. Servers would have to implement this in the same way when > they add BIND support and I'm not aware of any problems that would > cause. Clients might sometimes see a new URL appear in a collection on > date D2, when the last-modified time is a timestamp D1 from much earlier > (before the client last synchronized, for example), but that seems > unlikely to cause bugs. > - If the spec explicitly allows this to vary then the spec probably has > to say something about what that means. > - If the spec remains silent, then a cautious and perceptive client > implementor would have to assume that it could mean anything. I'm not > sure if it would be best to download all the different bindings' > getlastmodified times to see if they're different. If they are > different, what would the client do? Display the earliest one? The > latest one? Which value would be most helpful to the user? Again, > existing document archive and retention programs would probably show > different behavior if servers end up calculating this property in > different ways. But the DAV:getlastmodified falls into the same category as all the other DAV:get* properties. They are defined as per RFC2616, and as I have shown multiple times, you cannot rely on them to be stable across namespace operations (be it MOVE or BIND). So we really cannot say anything above what RFC2616 already says. > DAV:displayname > > RFC2518 underspecifies this property and we know the problems that has > caused. Nevertheless BIND could say something here. How? If it's underspecified in RFC2518 (with which I agree), it needs to be clarified in RFC2518bis... > - We do have implementation evidence that some implementations > calculate display name from the URL, thus it could conceivably vary > according to binding. We also know some implementations store display > name as if it were a dead property, thus it would not vary according to > binding. Yes. > - If the spec says that displayname MUST be consistent across bindings, > then some implementations would have to change the way they calculate > displayname in order to implement BIND. I would argue that would be a > good thing and would help alleviate the uncertainty in RFC2518. I agree that it would be good if servers would behave that way, and thus we should clarify that in RFC2518bis. > - If the spec explicitly allows this to vary, that implicitly supports > the calculated displayname model. Probably, however, servers which keep > the value consistent would continue to do so. > - If the spec is silent, then a cautious and perceptive client > implementor would have to assume that displayname could vary and > download it again for every binding if the client needs this property. Depends on what RFC2518 and our bis issues list say; and whether there'll be servers that actually do implement multiple bindings while having the per-URL displayname functionality. I'm not aware of any. > DAV:source > > This property isn't widely implemented so it's hard to make any > statements about implementations or about implications of consistency > across bindings. > > General case > > It would be best if BIND could say something about the general case of > live properties even if it leaves some leeway for future live properties > to be defined as exceptions to the general case. Based on looking at the > live properties defined in RFC2518, we could define those as being the > same values across all bindings. The consequences of this would be more I guess you mean those except the DAV:get* properties defined by RFC2616? > consistent and clear server behavior and easier client implementations, > at the cost of some server implementations having to change a few things > in order to become compliant with BIND. It's conceivable that such a > clear requirement would rule out some imaginative and odd ways of > implementing new or custom functionality based on bindings and existing > live properties, which might not be a bad thing. A clear requirement > for existing live properties to have the same values on all bindings > could still allow for exceptions for new live properties defined > differently, and thus not close off future innovation. How about suggesting a concrete wording? First thing we should do then is to test it against what RFC3253, RFC3648 and RFC3744 already define. Best regards, Julian From w3c-dist-auth-request@frink.w3.org Fri Jun 24 13:34: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 NAA27331 for ; Fri, 24 Jun 2005 13:34:42 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dls1z-0006Ml-B4 for w3c-dist-auth-dist@listhub.w3.org; Fri, 24 Jun 2005 17:31:55 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dls1w-0006MD-FS for w3c-dist-auth@listhub.w3.org; Fri, 24 Jun 2005 17:31:52 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by bart.w3.org with esmtp (Exim 4.50) id 1Dls1t-0001LE-Nx for w3c-dist-auth@w3.org; Fri, 24 Jun 2005 17:31:52 +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 j5OHVmAx008227 for ; Fri, 24 Jun 2005 10:31:48 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 24 Jun 2005 10:31:48 -0700 Received: from [17.226.20.190] (baumjo.apple.com [17.226.20.190]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id j5OHVkAo027812; Fri, 24 Jun 2005 10:31:46 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BEF5A74-FECC-492E-97C2-601F35AEA5EB@apple.com> Cc: Christopher Sharp , Jim Luther Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Fri, 24 Jun 2005 10:31:46 -0700 To: w3c-dist-auth@w3.org X-Mailer: Apple Mail (2.730) X-W3C-Hub-Spam-Status: No, score=0.0 X-W3C-Scan-Sig: bart.w3.org 1Dls1t-0001LE-Nx 159c38d7da3413246b4ab567042990ef X-Original-To: w3c-dist-auth@w3.org Subject: Re: Coments, please (was Re: Working group process and the future of the WG.) X-Archived-At: http://www.w3.org/mid/4BEF5A74-FECC-492E-97C2-601F35AEA5EB@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9695 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 24 Jun 2005 17:31:55 +0000 Content-Transfer-Encoding: 7bit The server-side perspective from Apple is as follows: 1. We often have weeks to implement a feature, so waiting months for an RFC is not practical. That said, we're strong supporters of standards and endeavor to implement them as accurately as possible. When we have implemented a feature in a custom way, and a subsequent standard is released, we again endeavor to expose the feature also via the standard mechanism. 2. We currently support a fairly complete and compliant ACL implementation that includes the 3744 framework. 3. We find BIND overly complex for our needs and have implemented a much simpler linking mechanism that maps well onto the concept of iDisk ("rooted subtrees") ownership by paying customers that wish to share resources. (Note our recent "family pack" offerings.) 4. Investigation of Redirect is on our to-do list. 5. We support a "ranged PUTs" custom extension, which seems to be adequate for out needs. But would probably implement the PATCH mechanism if completed. 6. We have abandoned DeltaV for now. 7. Jim stated out position on Quota. WebDAV and related protocols are and will continue to be essential to the .Mac service offerings. JS "Jake" Baumgarten .Mac Backend Server Engineering Apple Computer On Jun 3, 2005, at 2:16 PM, Jim Luther wrote: > > We already have a variant of Quota implemented in .Mac iDisk server > and the Mac OS X WebDAV file system and plan to conform to the real > Quota spec. > > BIND would allow us to implement hard links in our WebDAV file > system, but that's not really that useful. > > More useful would be support for Redirect resources which would > look like symlinks to file system clients. We've been asked to > support symlinks in the WebDAV file system many times. > > The only other HTTP extension method we are interested in is PATCH > (which was discussed on the HTTP mailing list for a while) because > the lack of a way to modify part of a resource is a big performance > problem for a WebDAV file system. > > Jim Luther > Apple > > On Jun 3, 2005, at 11:24 AM, Ted Hardie wrote: From w3c-dist-auth-request@frink.w3.org Mon Jun 27 12:11: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 MAA07398 for ; Mon, 27 Jun 2005 12:11:38 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DmwAi-0000R3-CX for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Jun 2005 16:09:20 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.50) id 1DmwAd-0000ME-Gt for w3c-dist-auth@listhub.w3.org; Mon, 27 Jun 2005 16:09:15 +0000 Received: from mail-out4.apple.com ([17.254.13.23]) by lisa.w3.org with esmtp (Exim 4.50) id 1DmwAa-0006kR-J5 for w3c-dist-auth@w3.org; Mon, 27 Jun 2005 16:09:15 +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 j5RG9B1U011712 for ; Mon, 27 Jun 2005 09:09:11 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 27 Jun 2005 09:09:11 -0700 Received: from [17.226.20.190] (baumjo.apple.com [17.226.20.190]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j5RG9BZF022442 for ; Mon, 27 Jun 2005 09:09:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baumgarten Date: Mon, 27 Jun 2005 09:09:10 -0700 To: WebDav X-Mailer: Apple Mail (2.730) X-W3C-Hub-Spam-Status: No, score=0.2 X-W3C-Scan-Sig: lisa.w3.org 1DmwAa-0006kR-J5 8ee0a794a6d29fba3c9439bb981fe93a X-Original-To: w3c-dist-auth@w3.org Subject: Re: WGLC draft-ietf-webdav-redirectref-protocol-12 X-Archived-At: http://www.w3.org/mid/AE9933E8-D189-4FA4-BB4C-266F59475C00@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9696 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Jun 2005 16:09:20 +0000 Content-Transfer-Encoding: 7bit All- After reviewing this draft, I have decided that the protocol is too complex for our needs with .Mac. In particular, the failure of locking methods that contain redirected resources would confuse our clients. Instead, we have decided to implement a simpler redirect capability via a custom property (not a WebDAV resource type) that is only activated when indicated by the client request. Given this decision, I will not be able to provide specific feedback on the draft. -Jake JS "Jake" Baumgarten .Mac Backend Server Engineering 408-974-0043 De Anza 6 #202 jbaumgarten@apple.com On Jun 13, 2005, at 6:01 PM, Cullen Jennings wrote: > > > I would like to start working group last call > > http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref- > protocol-1 > 2.txt > > This WGCL will end on July 4th so please have your comments emailed > to this > list before then. > > Thank you, Cullen > > > From w3c-dist-auth-request@frink.w3.org Mon Jun 27 18:04: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 SAA00691 for ; Mon, 27 Jun 2005 18:04:23 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dn1gj-0002eE-9g for w3c-dist-auth-dist@listhub.w3.org; Mon, 27 Jun 2005 22:02:45 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Dn1ge-0002de-S3 for w3c-dist-auth@listhub.w3.org; Mon, 27 Jun 2005 22:02:41 +0000 Received: from laweleka.osafoundation.org ([204.152.186.98] helo=smtp.osafoundation.org) by maggie.w3.org with esmtp (Exim 4.50) id 1Dn1ga-0001hE-SB for w3c-dist-auth@w3.org; Mon, 27 Jun 2005 22:02:42 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id C16A8142267; Mon, 27 Jun 2005 15:02:34 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15816-06; Mon, 27 Jun 2005 15:02:34 -0700 (PDT) Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id C8412142264; Mon, 27 Jun 2005 15:02:33 -0700 (PDT) In-Reply-To: <42B84ACD.2080608@gmx.de> References: <42B84ACD.2080608@gmx.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1405067cc71ebf15f90f42142ebbfd6f@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: webdav WG From: Lisa Dusseault Date: Mon, 27 Jun 2005 15:02:28 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: maggie.w3.org 1Dn1ga-0001hE-SB e41c774cc43a8ff557895d0271e65c18 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/1405067cc71ebf15f90f42142ebbfd6f@osafoundation.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9697 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 27 Jun 2005 22:02:45 +0000 Content-Transfer-Encoding: 7bit We disagree on some pretty fundamental issues here, it seems... On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote: > > Lisa, > > thanks for the feedback. > > Let me make some base statements before I dig into the details: > > 1) If the spec can't be implemented within Apache/moddav on a Unix > filesystem (using hard links), there's something wrong with the spec. I am not sure about this. ACL couldn't be implemented on a Unix filesystem using Unix permissions and in the end we had to live with that. For that matter, you can't implement WebDAV properties on a Unix fs without creating extra data store constructs of some kind. So I wouldn't agree with a statement this broad although I would agree with a statement to the effect that it's a "nice to have" if bindings can be implemented using Unix fs hard links. > In general, introducing new requirements not present in either RFC2616 > or RFC2518 is a bad idea. I don't agree with this -- a new spec is all about adding new requirements. Are you talking instead about new requirements that would affect an implementor who wasn't implementing bindings? That I do agree with, but I'm not suggesting that kind of thing, naturally that is ineffectual. The argument (seen elsewhere, e.g. in the property behavior proposal) that any feature that is defined in HTTP can't be defined more carefully in a draft that extends HTTP is one I have to reject for all the interoperability problems that must cause if taken as a general argument. We can't expect authors of specs to be omniscient -- they can only deal with issues they are made aware of -- and we must be able to help implementors out by making things clear when we have the chance. > > 2) The behaviour of live properties for multiple URIs follows the same > patterns as for plain HTTP/WebDAV when namespace operations such as > MOVE are involved (see discussion in > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ > 0001.html>). That may be, but I don't see that sufficiently spelled out for implementors to end up with something consistent. Nor do I think we've examined all the ramifications of that kind of broad statement. > > 3) I disagree that it is a problem when RFC2518bis (containing > clarifications on live property behaviour) comes out after BIND; once > it's officially updating RFC2518, this is what readers of the BIND > spec should read (just like RFC3986 is now the current URI spec, and > both RFC2518 and RFC2616 still point to older revisions). So Bind will reference RFC2518? If so, then implementors *can't* automatically update the reference to what replaces RFC2518 unless that makes no interoperability differences. To do so would be to be non-compliant with Bind and what it references. That also means that implementors of RFC2518 and RFC2616 can't cause backward-compatibility problems with clients by implementing RFC3986 and still claim compliance with RFC2518/2616. > >> - If the spec says that the value MUST be the same on all bindings, >> then this makes for the easiest and most efficient client >> synchronization operations. OTOH a few server implementations must >> change a little bit to correctly implement BIND. I think this is >> fine -- a minor server burden for increased efficiency and >> simplicity. > > As I have pointed out multiple times (see link above), this does not > work. Servers must have the freedom to adjust ETags because of > namespace operations, so they also need to be able to do that for > BIND. Could you *please* follow up on the analysis in > properties-latest.html>? Thanks. Where this document explains how MOVE and COPY should work with getLastModified and ETags, I agree with the explanations. Where the document explains that ETag behavior on multiple bindings must remain unspecified, I disagree, as already noted. Where the document says that header behavior is impossible to predict because the headers are defined by HTTP, I agree that is the situation in fact today, however I propose that we do better to help clients here. The bind spec can, and should, put more restrictions on servers that support that spec in how they handle ETags and last-modified timestamps. > >> DAV:creationdate >> RFC2518 defined this property and didn't tie it to any locking or GET >> request behavior, and it isn't used for synchronization or cache >> refreshes. Thus we have little to guide us on behavior but OTOH >> probably not a lot of problems caused if we go either way. >> - If the spec states that the value MUST be the same on all bindings >> and that it MUST be the date the resource was first created (e.g. >> with PUT), then this is the best case for people viewing creationdate >> (as some clients already display it). It makes most sense to the >> person that creation date be the date of first uploading the content. >> - If the spec states that the value MUST be the same on all bindings >> and that it MUST be the date the last binding was created that could >> be a little weird. >> - If the spec explicitly allows different bindings to have different >> creationdate values then this implies that the creationdate is the >> date of creation of the binding. That's not unreasonable. >> Presumably a client could find the oldest binding and use its >> creationdate as the resource creationdate. >> - If the spec is silent then we really don't know if creation date >> refers to creation of the resource or of the binding. A person using >> a client that simply displays the value might notice the different >> behaviours on different servers. A document retention or document >> archival program might produce quite different results depending on >> how this was implemented. A cautious and perceptive client or agent >> implementor would have to assume that they might vary and would have >> to check all bindings. OTOH there are already clients and archival >> programs which aren't aware of bindings and these would have to be >> upgraded to check the creationdate on different bindings in order to >> regain predictable behavior. > > I disagree. DAV:resourcetype is defined by RFC2518 to be a property of > the resource; and the whole point of the BIND spec is to define > behaviours for multiple URIs mapped to the same resource. So it seems > to be straighforward that the DAV:creationdate will be the same for > all URLs (just like DAV:lockdiscovery). I agree that DAV:creationdate should be the same for all URLs to the same resource. I think that's the best option and I'd like that added to the spec. >> - If the spec says that displayname MUST be consistent across >> bindings, then some implementations would have to change the way they >> calculate displayname in order to implement BIND. I would argue that >> would be a good thing and would help alleviate the uncertainty in >> RFC2518. > > I agree that it would be good if servers would behave that way, and > thus we should clarify that in RFC2518bis. The Bindings spec also can, and should, say something about this, particularly if it references RFC2518. >> DAV:source >> This property isn't widely implemented so it's hard to make any >> statements about implementations or about implications of consistency >> across bindings. >> General case >> It would be best if BIND could say something about the general case >> of live properties even if it leaves some leeway for future live >> properties to be defined as exceptions to the general case. Based on >> looking at the live properties defined in RFC2518, we could define >> those as being the same values across all bindings. The consequences >> of this would be more > > I guess you mean those except the DAV:get* properties defined by > RFC2616? No, I think we could include those as well and it would improve interoperability and make implementations more consistent. I bet that if servers implementing Binding were required to do these properties a certain way, then even other servers that don't implement Binding would find the guidance and example helpful and can decide whether to update their implementations accordingly even if they're not required to. > >> consistent and clear server behavior and easier client >> implementations, at the cost of some server implementations having to >> change a few things in order to become compliant with BIND. It's >> conceivable that such a clear requirement would rule out some >> imaginative and odd ways of implementing new or custom functionality >> based on bindings and existing live properties, which might not be a >> bad thing. A clear requirement for existing live properties to have >> the same values on all bindings could still allow for exceptions for >> new live properties defined differently, and thus not close off >> future innovation. > > How about suggesting a concrete wording? First thing we should do then > is to test it against what RFC3253, RFC3648 and RFC3744 already > define. I am not sure about RFC3253. It's got a bunch of very complex stuff and I am not sure how all its properties should behave. However, for the others , I suggest wording along these lines: "The live properties defined in RFC2518, RFC3648 and RFC3744 are all resource properties, and therefore those values MUST NOT vary due to the binding used to access the resource." Lisa From w3c-dist-auth-request@frink.w3.org Mon Jun 27 23:25: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 XAA29112 for ; Mon, 27 Jun 2005 23:25:07 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dn6hC-000847-QT for w3c-dist-auth-dist@listhub.w3.org; Tue, 28 Jun 2005 03:23:34 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.50) id 1Dn6h1-00083S-1H for w3c-dist-auth@listhub.w3.org; Tue, 28 Jun 2005 03:23:23 +0000 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by maggie.w3.org with esmtp (Exim 4.50) id 1Dn6gb-0007zj-S6 for w3c-dist-auth@w3.org; Tue, 28 Jun 2005 03:23:25 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5S3Mscu031936 for ; Mon, 27 Jun 2005 23:22:54 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5S3Msnj207200 for ; Mon, 27 Jun 2005 23:22:54 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5S3Msml018603 for ; Mon, 27 Jun 2005 23:22:54 -0400 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 j5S3MrrZ018600 for ; Mon, 27 Jun 2005 23:22:53 -0400 In-Reply-To: <1405067cc71ebf15f90f42142ebbfd6f@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: Mon, 27 Jun 2005 23:22:56 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/27/2005 23:22:53, Serialize complete at 06/27/2005 23:22:53 Content-Type: multipart/alternative; boundary="=_alternative 001293ED8525702E_=" X-W3C-Hub-Spam-Status: No, score=-2.4 X-W3C-Scan-Sig: maggie.w3.org 1Dn6gb-0007zj-S6 b7abf60c2ac0cd1c13367d815e0bd666 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/OFF6C09C1F.1C5A243F-ON8525702E.000F52A1-8525702E.001293F1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9698 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 28 Jun 2005 03:23:34 +0000 This is a multipart message in MIME format. --=_alternative 001293ED8525702E_= Content-Type: text/plain; charset="US-ASCII" We have gone over these exact arguments many times. It is true that we disagree, but that disagreement is over a single simple point. In particular, the authors of the BIND specification believe that the semantics of a live property should be defined by the specification that introduces that live property, and if those semantics of a given live property are to be redefined/refined/clarified, that should be done in a specification that obsoletes the one with the original definition. A key question is whether disagreement on such a point from a single workgroup participant can veto a specification. Cheers, Geoff p.s. A few additional comments interspersed below. Lisa wrote on 06/27/2005 06:02:28 PM: > We disagree on some pretty fundamental issues here, it seems... > > On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote: > > Let me make some base statements before I dig into the details: > > > > 1) If the spec can't be implemented within Apache/moddav on a Unix > > filesystem (using hard links), there's something wrong with the spec. > > I am not sure about this. ACL couldn't be implemented on a Unix > filesystem using Unix permissions and in the end we had to live with > that. For that matter, you can't implement WebDAV properties on a Unix > fs without creating extra data store constructs of some kind. So I > wouldn't agree with a statement this broad although I would agree with > a statement to the effect that it's a "nice to have" if bindings can be > implemented using Unix fs hard links. A more important point here is that the Unix file system is a common example of an existing WebDAV implementation that exposes multiple bindings, just as is defined and allowed by RFC 2616 (and therefore inherited by RFC 2518). So any constraints you try to place on the semantics of multiple bindings are new constraints being placed on existing properties and methods. > > In general, introducing new requirements not present in either RFC2616 > > or RFC2518 is a bad idea. > > I don't agree with this -- a new spec is all about adding new > requirements. Are you talking instead about new requirements that > would affect an implementor who wasn't implementing bindings? That I > do agree with, but I'm not suggesting that kind of thing, naturally > that is ineffectual. You appear to be suggesting exactly that kind of thing. As indicated above, multiple bindings are defined in RFC-2616, and exist in common implementations (such as Unix file-system based implementations). > The argument (seen elsewhere, e.g. in the property behavior proposal) > that any feature that is defined in HTTP can't be defined more > carefully in a draft that extends HTTP is one I have to reject for all > the interoperability problems that must cause if taken as a general > argument. We can't expect authors of specs to be omniscient -- they > can only deal with issues they are made aware of -- and we must be able > to help implementors out by making things clear when we have the > chance. And we do so by doing defining a particular property more carefully in a "bis" specification that replaces the one that previously defined that property, so that the implementor of that property does not have to be omniscient and guess all the specifications that they need to read in order to understand the behavior of that property. > > 2) The behaviour of live properties for multiple URIs follows the same > > patterns as for plain HTTP/WebDAV when namespace operations such as > > MOVE are involved (see discussion in > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ > > 0001.html>). > > That may be, but I don't see that sufficiently spelled out for > implementors to end up with something consistent. Nor do I think we've > examined all the ramifications of that kind of broad statement. The specification is not an implementation guide, exactly to allow for a variety of implementations. So it is not always the case that "more guidance is better", if that guidance invalidates reasonable alternative implementations. So this will always be a value-judgement that is unlikely to ever get unanimous agreement. > > 3) I disagree that it is a problem when RFC2518bis (containing > > clarifications on live property behaviour) comes out after BIND; once > > it's officially updating RFC2518, this is what readers of the BIND > > spec should read (just like RFC3986 is now the current URI spec, and > > both RFC2518 and RFC2616 still point to older revisions). > > So Bind will reference RFC2518? If so, then implementors *can't* > automatically update the reference to what replaces RFC2518 unless that > makes no interoperability differences. To do so would be to be > non-compliant with Bind and what it references. What? There is a clearly defined IETF process for defining a replacement specification (that's what the "obsoletes" keyword is for). So "automatically updating the reference to what replaces RFC2518" is exactly what is expected from all implementors, just as they were expected to implement RFC2616 instead of RFC2068. > That also means that implementors of RFC2518 and RFC2616 can't cause > backward-compatibility problems with clients by implementing RFC3986 > and still claim compliance with RFC2518/2616. That is exactly what they can (and are expected) to do. Of course, the authors of RFC3986 worked hard to minimize those backward compatibility issues with RFC2396 (just as the authors of RFC2518bis are expected to minimize the backward compatibility issues with RFC2518). The rest of the message below should appear in an RFC2518bis thread, so I'll wait to respond to it until it appears there. > >> - If the spec says that the value MUST be the same on all bindings, > >> then this makes for the easiest and most efficient client > >> synchronization operations. OTOH a few server implementations must > >> change a little bit to correctly implement BIND. I think this is > >> fine -- a minor server burden for increased efficiency and > >> simplicity. > > > > As I have pointed out multiple times (see link above), this does not > > work. Servers must have the freedom to adjust ETags because of > > namespace operations, so they also need to be able to do that for > > BIND. Could you *please* follow up on the analysis in > > > properties-latest.html>? Thanks. > > Where this document explains how MOVE and COPY should work with > getLastModified and ETags, I agree with the explanations. > > Where the document explains that ETag behavior on multiple bindings > must remain unspecified, I disagree, as already noted. > > Where the document says that header behavior is impossible to predict > because the headers are defined by HTTP, I agree that is the situation > in fact today, however I propose that we do better to help clients > here. The bind spec can, and should, put more restrictions on servers > that support that spec in how they handle ETags and last-modified > timestamps. > > > > >> DAV:creationdate > >> RFC2518 defined this property and didn't tie it to any locking or GET > >> request behavior, and it isn't used for synchronization or cache > >> refreshes. Thus we have little to guide us on behavior but OTOH > >> probably not a lot of problems caused if we go either way. > >> - If the spec states that the value MUST be the same on all bindings > >> and that it MUST be the date the resource was first created (e.g. > >> with PUT), then this is the best case for people viewing creationdate > >> (as some clients already display it). It makes most sense to the > >> person that creation date be the date of first uploading the content. > >> - If the spec states that the value MUST be the same on all bindings > >> and that it MUST be the date the last binding was created that could > >> be a little weird. > >> - If the spec explicitly allows different bindings to have different > >> creationdate values then this implies that the creationdate is the > >> date of creation of the binding. That's not unreasonable. > >> Presumably a client could find the oldest binding and use its > >> creationdate as the resource creationdate. > >> - If the spec is silent then we really don't know if creation date > >> refers to creation of the resource or of the binding. A person using > >> a client that simply displays the value might notice the different > >> behaviours on different servers. A document retention or document > >> archival program might produce quite different results depending on > >> how this was implemented. A cautious and perceptive client or agent > >> implementor would have to assume that they might vary and would have > >> to check all bindings. OTOH there are already clients and archival > >> programs which aren't aware of bindings and these would have to be > >> upgraded to check the creationdate on different bindings in order to > >> regain predictable behavior. > > > > I disagree. DAV:resourcetype is defined by RFC2518 to be a property of > > the resource; and the whole point of the BIND spec is to define > > behaviours for multiple URIs mapped to the same resource. So it seems > > to be straighforward that the DAV:creationdate will be the same for > > all URLs (just like DAV:lockdiscovery). > > I agree that DAV:creationdate should be the same for all URLs to the > same resource. I think that's the best option and I'd like that added > to the spec. > > >> - If the spec says that displayname MUST be consistent across > >> bindings, then some implementations would have to change the way they > >> calculate displayname in order to implement BIND. I would argue that > >> would be a good thing and would help alleviate the uncertainty in > >> RFC2518. > > > > I agree that it would be good if servers would behave that way, and > > thus we should clarify that in RFC2518bis. > > The Bindings spec also can, and should, say something about this, > particularly if it references RFC2518. > > >> DAV:source > >> This property isn't widely implemented so it's hard to make any > >> statements about implementations or about implications of consistency > >> across bindings. > >> General case > >> It would be best if BIND could say something about the general case > >> of live properties even if it leaves some leeway for future live > >> properties to be defined as exceptions to the general case. Based on > >> looking at the live properties defined in RFC2518, we could define > >> those as being the same values across all bindings. The consequences > >> of this would be more > > > > I guess you mean those except the DAV:get* properties defined by > > RFC2616? > > No, I think we could include those as well and it would improve > interoperability and make implementations more consistent. I bet that > if servers implementing Binding were required to do these properties a > certain way, then even other servers that don't implement Binding would > find the guidance and example helpful and can decide whether to update > their implementations accordingly even if they're not required to. > > > > >> consistent and clear server behavior and easier client > >> implementations, at the cost of some server implementations having to > >> change a few things in order to become compliant with BIND. It's > >> conceivable that such a clear requirement would rule out some > >> imaginative and odd ways of implementing new or custom functionality > >> based on bindings and existing live properties, which might not be a > >> bad thing. A clear requirement for existing live properties to have > >> the same values on all bindings could still allow for exceptions for > >> new live properties defined differently, and thus not close off > >> future innovation. > > > > How about suggesting a concrete wording? First thing we should do then > > is to test it against what RFC3253, RFC3648 and RFC3744 already > > define. > > I am not sure about RFC3253. It's got a bunch of very complex stuff > and I am not sure how all its properties should behave. However, for > the others , I suggest wording along these lines: > > "The live properties defined in RFC2518, RFC3648 and RFC3744 are all > resource properties, and therefore those values MUST NOT vary due to > the binding used to access the resource." > > Lisa > > --=_alternative 001293ED8525702E_= Content-Type: text/html; charset="US-ASCII"
We have gone over these exact arguments many times.
It is true that we disagree, but that disagreement is over
a single simple point.

In particular, the authors of the BIND specification believe
that the semantics of a live property should be defined by
the specification that introduces that live property,
and if those semantics of a given live property are to be
redefined/refined/clarified, that should be done in a
specification that obsoletes the one with the original definition.

A key question is whether disagreement on such a point
from a single workgroup participant can veto a specification.

Cheers,
Geoff

p.s. A few additional comments interspersed below.

Lisa wrote on 06/27/2005 06:02:28 PM:
> We disagree on some pretty fundamental issues here, it seems...
>
> On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote:
> > Let me make some base statements before I dig into the details:
> >
> > 1) If the spec can't be implemented within Apache/moddav on a Unix  
> > filesystem (using hard links), there's something wrong with the spec.
>
> I am not sure about this.  ACL couldn't be implemented on a Unix  
> filesystem using Unix permissions and in the end we had to live with  
> that.  For that matter, you can't implement WebDAV properties on a Unix  
> fs without creating extra data store constructs of some kind.  So I  
> wouldn't agree with a statement this broad although I would agree with  
> a statement to the effect that it's a "nice to have" if bindings can be  
> implemented using Unix fs hard links.

A more important point here is that the Unix file system is a common
example of an existing WebDAV implementation that exposes multiple bindings,
just as is defined and allowed by RFC 2616 (and therefore inherited by
RFC 2518). So any constraints you try to place on the semantics of multiple bindings
are new constraints being placed on existing properties and methods.

> > In general, introducing new requirements not present in either RFC2616  
> > or RFC2518 is a bad idea.
>
> I don't agree with this -- a new spec is all about adding new  
> requirements.   Are you talking instead about new requirements that  
> would affect an implementor who wasn't implementing bindings?  That I  
> do agree with, but I'm not suggesting that kind of thing, naturally  
> that is ineffectual.

You appear to be suggesting exactly that kind of thing.  As indicated above,
multiple bindings are defined in RFC-2616, and exist in common implementations
(such as Unix file-system based implementations).

> The argument (seen elsewhere, e.g. in the property behavior proposal)  
> that any feature that is defined in HTTP can't be defined more  
> carefully in a draft that extends HTTP is one I have to reject for all  
> the interoperability problems that must cause if taken as a general  
> argument.  We can't expect authors of specs to be omniscient -- they  
> can only deal with issues they are made aware of -- and we must be able  
> to help implementors out by making things clear when we have the  
> chance.

And we do so by doing defining a particular property more carefully in
a "bis" specification that replaces the one that previously defined
that property, so that the implementor of that property does not have
to be omniscient and guess all the specifications that they need
to read in order to understand the behavior of that property.
> > 2) The behaviour of live properties for multiple URIs follows the same  
> > patterns as for plain HTTP/WebDAV when namespace operations such as  
> > MOVE are involved (see discussion in  
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/
> > 0001.html>).
>
> That may be, but I don't see that sufficiently spelled out for  
> implementors to end up with something consistent.  Nor do I think we've  
> examined all the ramifications of that kind of broad statement.

The specification is not an implementation guide, exactly to allow for
a variety of implementations.  So it is not always the case that "more
guidance is better", if that guidance invalidates reasonable alternative
implementations.  So this will always be a value-judgement that is unlikely
to ever get unanimous agreement.
 
> > 3) I disagree that it is a problem when RFC2518bis (containing  
> > clarifications on live property behaviour) comes out after BIND; once  
> > it's officially updating RFC2518, this is what readers of the BIND  
> > spec should read (just like RFC3986 is now the current URI spec, and  
> > both RFC2518 and RFC2616 still point to older revisions).
>
> So Bind will reference RFC2518?  If so, then implementors *can't*  
> automatically update the reference to what replaces RFC2518 unless that  
> makes no interoperability differences.  To do so would be to be  
> non-compliant with Bind and what it references.

What?  There is a clearly defined IETF process for defining a replacement
specification (that's what the "obsoletes" keyword is for).
So "automatically updating the reference to what replaces
RFC2518" is exactly what is expected from all implementors, just as they
were expected to implement RFC2616 instead of RFC2068.

> That also means that implementors of RFC2518 and RFC2616 can't cause  
> backward-compatibility problems with clients by implementing RFC3986  
> and still claim compliance with RFC2518/2616.

That is exactly what they can (and are expected) to do.  Of course, the
authors of RFC3986 worked hard to minimize those backward compatibility
issues with RFC2396 (just as the authors of RFC2518bis
are expected to minimize the backward compatibility issues with RFC2518).

The rest of the message below should appear in an RFC2518bis thread,
so I'll wait to respond to it until it appears there.

> >>  - If the spec says that the value MUST be the same on all bindings,  
> >> then this makes for the easiest and most efficient client  
> >> synchronization operations.  OTOH a few server implementations must  
> >> change a little bit to correctly implement BIND.  I think this is  
> >> fine -- a minor server burden for increased efficiency and  
> >> simplicity.
> >
> > As I have pointed out multiple times (see link above), this does not  
> > work. Servers must have the freedom to adjust ETags because of  
> > namespace operations, so they also need to be able to do that for  
> > BIND. Could you *please* follow up on the analysis in  
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-
> > properties-latest.html>? Thanks.
>
> Where this document explains how MOVE and COPY should work with  
> getLastModified and ETags, I agree with the explanations.
>
> Where the document explains that ETag behavior on multiple bindings  
> must remain unspecified, I disagree, as already noted.
>
> Where the document says that header behavior is impossible to predict  
> because the headers are defined by HTTP, I agree that is the situation  
> in fact today, however I propose that we do better to help clients  
> here.  The bind spec can, and should, put more restrictions on servers  
> that support that spec in how they handle ETags and last-modified  
> timestamps.
>
> >
> >> DAV:creationdate
> >> RFC2518 defined this property and didn't tie it to any locking or GET  
> >> request behavior, and it isn't used for synchronization or cache  
> >> refreshes.  Thus we have little to guide us on behavior but OTOH  
> >> probably not a lot of problems caused if we go either way.
> >>  - If the spec states that the value MUST be the same on all bindings  
> >> and that it MUST be the date the resource was first created (e.g.  
> >> with PUT), then this is the best case for people viewing creationdate  
> >> (as some clients already display it).  It makes most sense to the  
> >> person that creation date be the date of first uploading the content.
> >>  - If the spec states that the value MUST be the same on all bindings  
> >> and that it MUST be the date the last binding was created that could  
> >> be a little weird.
> >>  - If the spec explicitly allows different bindings to have different  
> >> creationdate values then this implies that the creationdate is the  
> >> date of creation of the binding.  That's not unreasonable.  
> >> Presumably a client could find the oldest binding and use its  
> >> creationdate as the resource creationdate.
> >>  - If the spec is silent then we really don't know if creation date  
> >> refers to creation of the resource or of the binding.  A person using  
> >> a client that simply displays the value might notice the different  
> >> behaviours on different servers.  A document retention or document  
> >> archival program might produce quite different results depending on  
> >> how this was implemented.  A cautious and perceptive client or agent  
> >> implementor would have to assume that they might vary and would have  
> >> to check all bindings.  OTOH there are already clients and archival  
> >> programs which aren't aware of bindings and these would have to be  
> >> upgraded to check the creationdate on different bindings in order to  
> >> regain predictable behavior.
> >
> > I disagree. DAV:resourcetype is defined by RFC2518 to be a property of  
> > the resource; and the whole point of the BIND spec is to define  
> > behaviours for multiple URIs mapped to the same resource. So it seems  
> > to be straighforward that the DAV:creationdate will be the same for  
> > all URLs (just like DAV:lockdiscovery).
>
> I agree that DAV:creationdate should be the same for all URLs to the  
> same resource.  I think that's the best option and I'd like that added  
> to the spec.
>
> >>  - If the spec says that displayname MUST be consistent across  
> >> bindings, then some implementations would have to change the way they  
> >> calculate displayname in order to implement BIND.  I would argue that  
> >> would be a good thing and would help alleviate the uncertainty in  
> >> RFC2518.
> >
> > I agree that it would be good if servers would behave that way, and  
> > thus we should clarify that in RFC2518bis.
>
> The Bindings spec also can, and should, say something about this,  
> particularly if it references RFC2518.
>
> >> DAV:source
> >> This property isn't widely implemented so it's hard to make any  
> >> statements about implementations or about implications of consistency  
> >> across bindings.
> >> General case
> >> It would be best if BIND could say something about the general case  
> >> of live properties even if it leaves some leeway for future live  
> >> properties to be defined as exceptions to the general case. Based on  
> >> looking at the live properties defined in RFC2518, we could define  
> >> those as being the same values across all bindings.  The consequences  
> >> of this would be more
> >
> > I guess you mean those except the DAV:get* properties defined by  
> > RFC2616?
>
> No, I think we could include those as well and it would improve  
> interoperability and make implementations more consistent.   I bet that  
> if servers implementing Binding were required to do these properties a  
> certain way, then even other servers that don't implement Binding would  
> find the guidance and example helpful and can decide whether to update  
> their implementations accordingly even if they're not required to.
>
> >
> >> consistent and clear server behavior and easier client  
> >> implementations, at the cost of some server implementations having to  
> >> change a few things in order to become compliant with BIND.  It's  
> >> conceivable that such a clear requirement would rule out some  
> >> imaginative and odd ways of implementing new  or custom functionality  
> >> based on bindings and existing live properties, which might not be a  
> >> bad thing.  A clear requirement for existing live properties to have  
> >> the same values on all bindings could still allow for exceptions for  
> >> new live properties defined differently, and thus not close off  
> >> future innovation.
> >
> > How about suggesting a concrete wording? First thing we should do then  
> > is to test it against what RFC3253, RFC3648 and RFC3744 already  
> > define.
>
> I am not sure about RFC3253.  It's got a bunch of very complex stuff  
> and I am not sure how all its properties should behave.  However, for  
> the others , I suggest wording along these lines:
>
> "The live properties defined in RFC2518, RFC3648 and RFC3744 are all  
> resource properties, and therefore those values MUST NOT vary due to  
> the binding used to access the resource."
>
> Lisa
>
>
--=_alternative 001293ED8525702E_=-- From w3c-dist-auth-request@frink.w3.org Wed Jun 29 11:18:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DneKD-0004Ng-4p for webdav-archive@megatron.ietf.org; Wed, 29 Jun 2005 11:18:07 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01091 for ; Wed, 29 Jun 2005 11:18:02 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1DneHO-00030Q-3c for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Jun 2005 15:15:10 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1DneHK-0002pP-Bl for w3c-dist-auth@listhub.w3.org; Wed, 29 Jun 2005 15:15:06 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.50) id 1DneHD-0001Uw-Lk for w3c-dist-auth@w3.org; Wed, 29 Jun 2005 15:15:06 +0000 Received: (qmail invoked by alias); 29 Jun 2005 15:14:56 -0000 Received: from p508FB260.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.178.96] by mail.gmx.net (mp027) with SMTP; 29 Jun 2005 17:14:56 +0200 X-Authenticated: #1915285 Message-ID: <42C2BAED.8080808@gmx.de> Date: Wed, 29 Jun 2005 17:14:53 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1DneHD-0001Uw-Lk 8c58147bc018cf9f43da84e7fe257254 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/42C2BAED.8080808@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9699 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jun 2005 15:15:10 +0000 Content-Transfer-Encoding: 7bit Geoffrey M Clemm wrote: > > We have gone over these exact arguments many times. > It is true that we disagree, but that disagreement is over > a single simple point. > > In particular, the authors of the BIND specification believe > that the semantics of a live property should be defined by > the specification that introduces that live property, > and if those semantics of a given live property are to be > redefined/refined/clarified, that should be done in a > specification that obsoletes the one with the original definition. Yes. > A key question is whether disagreement on such a point > from a single workgroup participant can veto a specification. Agreed. The other point we seem to disagree upon is that BIND should only be applicable to a certain class of servers that indeed can maintain the live properties the way many wish. I absolutely agree in that it's a good thing if a server behaves that way, but I also think that BIND shouldn't mandate that. We conceivably could do two things: - in RFC2518bis, clarify the issues that arise because of the interaction between DAV:get* properties inherited from HTTP and the WebDAV namespace operations (for instance, state that a server must do post-namespace-op-cleanup of for instance DAV:getlastmodified; and also suggest that having strong entity tags that are unique across the server's whole namespace will make that unnecessary for DAV:getetag) - define a specific profile (putting additional constraints on the behaviour of some of these live properties), and make that client-detectable (for instance through a specific DAV: header option). Best regards, Julian From w3c-dist-auth-request@frink.w3.org Wed Jun 29 11:40:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnefw-0003Wg-U4 for webdav-archive@megatron.ietf.org; Wed, 29 Jun 2005 11:40:33 -0400 Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03532 for ; Wed, 29 Jun 2005 11:40:30 -0400 (EDT) Received: from lists by frink.w3.org with local (Exim 4.50) id 1Dnef5-0004Zb-R4 for w3c-dist-auth-dist@listhub.w3.org; Wed, 29 Jun 2005 15:39:39 +0000 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.50) id 1Dnef2-0004YO-7i for w3c-dist-auth@listhub.w3.org; Wed, 29 Jun 2005 15:39:36 +0000 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.50) id 1Dneey-0007Pq-EQ for w3c-dist-auth@w3.org; Wed, 29 Jun 2005 15:39:36 +0000 Received: (qmail invoked by alias); 29 Jun 2005 15:39:31 -0000 Received: from p508FB260.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.178.96] by mail.gmx.net (mp026) with SMTP; 29 Jun 2005 17:39:31 +0200 X-Authenticated: #1915285 Message-ID: <42C2C0B1.4080100@gmx.de> Date: Wed, 29 Jun 2005 17:39:29 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: webdav WG References: <42B84ACD.2080608@gmx.de> <1405067cc71ebf15f90f42142ebbfd6f@osafoundation.org> In-Reply-To: <1405067cc71ebf15f90f42142ebbfd6f@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Scan-Sig: bart.w3.org 1Dneey-0007Pq-EQ 36860d045a83880c0854a9315ea6e241 X-Original-To: w3c-dist-auth@w3.org Subject: Re: BIND and live property value consistency X-Archived-At: http://www.w3.org/mid/42C2C0B1.4080100@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/9700 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-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, 29 Jun 2005 15:39:39 +0000 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > We disagree on some pretty fundamental issues here, it seems... > > On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote: > >> >> Lisa, >> >> thanks for the feedback. >> >> Let me make some base statements before I dig into the details: >> >> 1) If the spec can't be implemented within Apache/moddav on a Unix >> filesystem (using hard links), there's something wrong with the spec. > > > I am not sure about this. ACL couldn't be implemented on a Unix > filesystem using Unix permissions and in the end we had to live with > that. For that matter, you can't implement WebDAV properties on a Unix > fs without creating extra data store constructs of some kind. So I > wouldn't agree with a statement this broad although I would agree with > a statement to the effect that it's a "nice to have" if bindings can be > implemented using Unix fs hard links. The issue with Apache/mod_dav is this: mod_dav does *not* compute entity tags (or lastmodified on it's own), it simply uses the ones already implemented in httpd (or whatever the name of the base component is). This core component is designed to function completely independantly of WebDAV, so it's simply impossible to change the ETag requirements here. Of course things look different if a server implements all of HTTP/WebDAV/BIND in the same place, but that approach simply isn't going to work in all use cases. >> In general, introducing new requirements not present in either >> RFC2616 or RFC2518 is a bad idea. > > > I don't agree with this -- a new spec is all about adding new > requirements. Are you talking instead about new requirements that > would affect an implementor who wasn't implementing bindings? That I > do agree with, but I'm not suggesting that kind of thing, naturally > that is ineffectual. Actually, this is what you seem to suggest. You're asking for new requirements on the behaviour of DAV:get* properties, and these requirements affect all servers, not only those aware of bindings. > The argument (seen elsewhere, e.g. in the property behavior proposal) > that any feature that is defined in HTTP can't be defined more > carefully in a draft that extends HTTP is one I have to reject for all > the interoperability problems that must cause if taken as a general > argument. We can't expect authors of specs to be omniscient -- they > can only deal with issues they are made aware of -- and we must be able > to help implementors out by making things clear when we have the chance. It depends on what the target audience of that spec is. Of course you can profile HTTP/WebDAV for some specific scenarios, but that also means that what you spec may not be implementable for many servers. This is something the BIND spec editors want to avoid. >> 2) The behaviour of live properties for multiple URIs follows the >> same patterns as for plain HTTP/WebDAV when namespace operations such >> as MOVE are involved (see discussion in >> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ >> 0001.html>). > > > That may be, but I don't see that sufficiently spelled out for > implementors to end up with something consistent. Nor do I think we've > examined all the ramifications of that kind of broad statement. OK, so that's a To-Do item for RFC2518bis. >> 3) I disagree that it is a problem when RFC2518bis (containing >> clarifications on live property behaviour) comes out after BIND; once >> it's officially updating RFC2518, this is what readers of the BIND >> spec should read (just like RFC3986 is now the current URI spec, and >> both RFC2518 and RFC2616 still point to older revisions). > > > So Bind will reference RFC2518? If so, then implementors *can't* Of course. > automatically update the reference to what replaces RFC2518 unless that > makes no interoperability differences. To do so would be to be > non-compliant with Bind and what it references. I'm not sure I follow. In the IETF, this (updates of a base document) happens all the time and nobody seems to suggest that RFCs absolutely need to be updated just because a base document has progressed to a new standards level. > That also means that implementors of RFC2518 and RFC2616 can't cause > backward-compatibility problems with clients by implementing RFC3986 > and still claim compliance with RFC2518/2616. Interesting. So why are we talking of RFC2616 all the time, when the spec that RFC2518 refers to is actually RFC2068??? > Where this document explains how MOVE and COPY should work with > getLastModified and ETags, I agree with the explanations. > > Where the document explains that ETag behavior on multiple bindings > must remain unspecified, I disagree, as already noted. > > Where the document says that header behavior is impossible to predict > because the headers are defined by HTTP, I agree that is the situation > in fact today, however I propose that we do better to help clients > here. The bind spec can, and should, put more restrictions on servers > that support that spec in how they handle ETags and last-modified > timestamps. (see separate email ). >> I disagree. DAV:resourcetype is defined by RFC2518 to be a property >> of the resource; and the whole point of the BIND spec is to define >> behaviours for multiple URIs mapped to the same resource. So it seems >> to be straighforward that the DAV:creationdate will be the same for >> all URLs (just like DAV:lockdiscovery). > > > I agree that DAV:creationdate should be the same for all URLs to the > same resource. I think that's the best option and I'd like that added > to the spec. > >>> - If the spec says that displayname MUST be consistent across >>> bindings, then some implementations would have to change the way >>> they calculate displayname in order to implement BIND. I would >>> argue that would be a good thing and would help alleviate the >>> uncertainty in RFC2518. >> >> >> I agree that it would be good if servers would behave that way, and >> thus we should clarify that in RFC2518bis. > > > The Bindings spec also can, and should, say something about this, > particularly if it references RFC2518. So how is it supposed to do that without risking to disagree with RFC2518bis? >>> DAV:source >>> This property isn't widely implemented so it's hard to make any >>> statements about implementations or about implications of >>> consistency across bindings. >>> General case >>> It would be best if BIND could say something about the general case >>> of live properties even if it leaves some leeway for future live >>> properties to be defined as exceptions to the general case. Based on >>> looking at the live properties defined in RFC2518, we could define >>> those as being the same values across all bindings. The >>> consequences of this would be more >> >> >> I guess you mean those except the DAV:get* properties defined by >> RFC2616? > > > No, I think we could include those as well and it would improve > interoperability and make implementations more consistent. I bet that > if servers implementing Binding were required to do these properties a > certain way, then even other servers that don't implement Binding would > find the guidance and example helpful and can decide whether to update > their implementations accordingly even if they're not required to. That sounds like you're trying to use BIND to enforce a specific server behaviour to everybody else. I disagree with that approach, although I may agree that it's good if a server behaves that way. To get there, it's IMHO better to (1) explain the issue and (2) potentially make it easier for clients to find out whether a server follows that model. Both would be action items for RFC2518bis. >>> consistent and clear server behavior and easier client >>> implementations, at the cost of some server implementations having >>> to change a few things in order to become compliant with BIND. >>> It's conceivable that such a clear requirement would rule out some >>> imaginative and odd ways of implementing new or custom >>> functionality based on bindings and existing live properties, which >>> might not be a bad thing. A clear requirement for existing live >>> properties to have the same values on all bindings could still allow >>> for exceptions for new live properties defined differently, and thus >>> not close off future innovation. >> >> >> How about suggesting a concrete wording? First thing we should do >> then is to test it against what RFC3253, RFC3648 and RFC3744 already >> define. > > > I am not sure about RFC3253. It's got a bunch of very complex stuff > and I am not sure how all its properties should behave. However, for > the others , I suggest wording along these lines: > > "The live properties defined in RFC2518, RFC3648 and RFC3744 are all > resource properties, and therefore those values MUST NOT vary due to > the binding used to access the resource." I think it's inacceptable because it describes what may be desirable in some scenarios, but not reality. Best regards, Julian