W3C home > Mailing lists > Public > ietf-discuss@w3.org > December 1999

Re: HTTP Extensions Framework status?

From: Keith Moore <moore@cs.utk.edu>
Date: Tue, 07 Dec 1999 17:28:52 -0500
Message-Id: <199912072228.RAA25211@astro.cs.utk.edu>
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.

Received on Tuesday, 7 December 1999 17:39:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:00 UTC