- From: Keith Moore <moore@cs.utk.edu>
- Date: Tue, 07 Dec 1999 17:28:52 -0500
- To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
- cc: "Keith Moore" <moore@cs.utk.edu>, "Yaron Goland \(Exchange\)" <yarong@exchange.microsoft.com>, "'Patrik Fältström'" <paf@swip.net>, "'Harald Tveit Alvestrand'" <Harald@Alvestrand.no>, "Scott Lawrence" <lawrence@agranat.com>, discuss@apps.ietf.org, "Josh Cohen \(Exchange\)" <joshco@exchange.microsoft.com>, "Peter Ford \(Exchange\)" <peterf@exchange.microsoft.com>
> The HTTP Extension Framework was originally a work item of the HTTP WG > but was because of the desire to close HTTP WG put off to another WG - > the HTTP extension working group along with two other items on "Policy > for how to extend HTTP" and the OPTIONS draft. However, this group was > never chartered due to what I consider political problems. Yes. This document, and other work peripheral to the HTTP WG, were distracting the HTTP WG from getting HTTP 1.1 draft standard out the door. Of course, the reason that HTTP 1.1 was taking so long is that it is a tremendously complex specification. Given that, it is worth asking whether making HTTP even more complex, or layering other protocols on top of HTTP, or especially adding explicit support for intermediaries in other protocol (which causes most of HTTP's complexity) are good ideas and things that IETF should spend its time on. IETF has limited resources and cannot form a new working group for every new idea - especially when that group would have a lot of the same people already participating in other HTTP-related groups such as webdav and dasl. There was lots of interest in the latter two groups and a relatively small amount of interest in HTTP extensions, so webdav and dasl got the cycles. And the reviews of HTTP extensions were always fairly mixed - whether in the HTTP WG list, on the discuss@apps list, or in Last Call comments. Basically, there never seemed to be much evidence of support for it, and several of the comments actually suggested Experimental status. I suspect this is not so much due to unresolved technical issues as due to questions about the premise of the work itself. > There didn't seem to be any other way than to make this draft an > individual submission - something that I don't recommend anybody to try > as there is no protection what so ever from arbitrary comments that > normally get filtered out by "rough concensus" in a wg. Individual submissions work better when the work is non-controversial. That doesn't mean that they're not useful, but that they're not intended to replace the working group process. > If you refer to the comments that were sent in during last call then > these were a) after I had made an informal last call on the HTTP WG > mailing list and b) after the draft had been pending for a while without > comments. Regardless, the comments were resolved during the last call > which I believe is the whole purpose of this mechanism, especially in > the case of individual submissions. In the case of a working group submission, the fact that the working group exists is usually sufficient evidence that there is support for the work. In the case of individual submissions it's harder to be sure. So the Last Call comments do serve a differnet role, and individual submissions often receive more scruitiny than working group submissions. > What I am opposed to is for work items to be needlessly delayed by > process because of architectural differences in where we as a comunity > want to go. I am not claiming that the HTTP extension spec is flawless > but I am calling for open and timely discussion. Architectural differences sound like a lack of consensus to me. Open and timely discussion seems entirely appropriate, and I apologize for my poor handling of this document. But I think that the author of an individual subimssion needs to demonstrate both technical quality and widespread community support for the document, and that objections during Last Call need to be taken as potential evidence of a lack of consensus. In the absence of clear community consensus support for the document to be on the standards track, we need to take the conservative view, and this means not approving the document as a standard. Keith
Received on Tuesday, 7 December 1999 17:39:47 UTC