- From: Cullen Jennings <fluffy@cisco.com>
- Date: Tue, 28 Nov 2006 17:08:58 -0800
- To: WebDav <w3c-dist-auth@w3.org>, Julian Reschke <julian.reschke@gmx.de>
- Cc: Ted Hardie <hardie@qualcomm.com>, Lisa Dusseault <lisa@osafoundation.org>
On Nov 28, 2006, at 11:17 AM, Julian Reschke wrote: > Ted Hardie schrieb: >> For some reason, I am only seeing Julian's replies to Cullen; this >> reply >> is really to Cullen, but applies to the whole thread. > > Yes, there's a known issue with Cullen's emails; maybe Jim > Whitehead has got an idea why they aren't reaching the mailing list. > Jim and I are working on this but in the mean time, Julian or Lisa, feel free to forward this to the list. >> At 11:29 AM +0100 11/28/06, Julian Reschke wrote: >>> Cullen Jennings schrieb: >>>> Ok - I see your point. At this point, my primary goal is getting >>>> a document that is better than RFC 2518 off to the IESG. >> I'm glad that this issue seems to have been so quickly resolved, >> and I hope others >> can comment about whether the new text is okay. But I think folks >> should really >> be narrowing focus at this point. This effort has been around for >> a long time, and >> we agreed nearly a year ago to get this document through the last >> hump and out >> the door. The chair and document author both getting put on the >> IESG at the > > The problem here is that once we got it out of the door (WGLC- > wise), almost no follow up activities happened. There *were* LC > comments, and most of them haven't been acted upon. > > I spent a considerable amount of time maintaining a version of the > draft with issues and many potential resolutions, but, quite > frankly, this doesn't seem to help in fixing the problems in the > WG's version of the draft. I really have no idea why. > I'm appreciative of the review and raising issues you do - and do quickly. I view the problem as, for many of the issues, we can't get to the point where more than a handful of people agree on the resolution to them. More below ... >> same time pulled critical energy from the group during what should >> have been >> its final clean-up. Since that point, we have had only >> occasional bursts of energy, >> and some of that has focused on areas that were not truly core to >> the work >> (like the WEBDAV capabilities in HTML thread Jim raised--these are >> interesting, >> but not chartered work). > > Yes. > > From my point of view, activities went away when it became clear > that no matter how much work is done in categorizing the issues and > discussing resolutions, none of that work made it into the WG's > draft. Which, in fact, just expired a few weeks ago, so there was > no "official" WG activity on the draft for over 6 months. > > As a matter of fact, I was seriously considering submitting "my" > version of the draft as a private submission just this weekend, > just to get things going again. > >> I believe that we have had strong consensus for a long time to >> replace RFC 2518, >> and I think the focus at this point has to narrow to places where >> the current document >> isn't as clear as 2518. Given the traffic since the WGLC on -14 >> back in February, >> I just don't see the energy to take on more at this point. I >> think putting the document >> in front of the larger community and acknowledging that it isn't >> perfect but >> is a needed improvement is the way to go. > > The problem aren't things that haven't improved, but changes that > actually make it worse (in some parts). For instance, I'm insisting > on exact language about locking *because* the lock of clarity was a > problem in RFC2518. We have spent a huge number of hours discussing locking - I doubt that more time on this is going to significantly change people from their current position. > >> If the group cannot do that in a short period of time, I would >> have to seriously >> consider closing it. The amount of energy here would clearly not >> justify a new >> working group; this one has continued despite that participation >> level partially >> because of continuity and partly because of the issues in 2518. I >> am not sure, >> however, that there is enough energy to survive another AD >> transition, and >> handing off to a new AD is March is a certainty. >> I encourage everyone to focus on the highest priority items *only* >> at this point >> and to keep in mind that not getting this out means 2518 stays as >> the standard >> for this. I do not think that is anyone's interest at this point. > > I would suggest to review the changes proposed in <http:// > greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis- > latest.html>. I went through every change in the version of this from a week or so ago and compared them to the draft. For each one I asked myself, is this critical that we fix this before publication? Is their clear consensus on how this should be? is this a "typo" type change that everyone would agree to and we just need to fix? For the ones that I came up with a "Yes" to one of these questions, I asked Lisa to change and she did. Now, I no doubt made some mistakes along the way but we have to realize this document would be better finished than perfect. I tried to focus on things that would cause implementers to end up creating software that did not interoperate. The one change that did not fall into one of these categories was the change around the basic with secure/TLS. You rightly pointed out that change did not have consensus and was a non trivial normative change. > That document also lists open LC issues (with no proposed > resolution), and any kind of constructive feedback on those would > be very welcome. Alternatively, reviewing the open issue list at > <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi? > product=WebDAV-RFC2518-bis> would be useful as well. I also when thought that whole list (but not the stuff that was added in November) and asked similar questions. I tried to focus on issues that were raised before the end of the WGLC. One of the problems with any document is we can always find yet one more problem with it so I try to focus on things before WGLC. I do realize that if we fine a total show stopper bug at any point, we do have to deal with it. (I just had to deal with a very bad bug that was found promptly after the RFC was published). Once we sort out this secure network text, I want to request publication of this. All complex drafts reach a point where you need to enough has been done, it's not perfect, but it is worth publishing. I feel the time has come for this draft (actually I think it is long past). The rate of incremental improvement is approaching the limit. The time and energy the WG has is small. The draft is a significant improvement over the previous RFC. Publishing this does not mean we can' every publish a bis draft to fix/improve the problems with this draft. Once publication is requested, Ted as the AD would have the opportunity to review and ask us to correct problems and it would go for IETF LC. This would be another opportunity to identify any true show stopper problems that absolutely needed to be fixed. Cullen <with me chair hat on>
Received on Thursday, 30 November 2006 01:27:32 UTC