Re: HTTP Extensions Framework status?

> [I feel compelled to point out at the outset that none of the
> below has anything to do with the HTTP Extensions Framework document -
> (a) this was an indivdual submission, not an HTTP working group
> and (b) the document received mixed reviews both within the HTTP WG
> and during Last Call, which is why it was not approved as Proposed.]

Actually I think this has a lot to do with it.

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.

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.

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.

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.

If the openness of the IETF has to be for real then such differences are
supposed to be dealt with on a public mailing list, not by dropping
specs into process holes. IESG can not at the same time be the driving
force of Internet Standards and an architectural guardian using the very
same process.

One solution to this is to appoint a app area directorate which can
object to proposals and provide timely technical/philosophical feedback
rather than having IESG use process to slow work down.


Received on Tuesday, 7 December 1999 14:03:34 UTC