Re: HTTP Extensions Framework status?

Henrik,
	From my viewpoint as a participant, it seems clear that the
HTTP working group ran out of steam; there was no way that group could
have taken on a work item as ambitious as this one.  As the chair of a
working group whose entropy rate risks exceeding its production, I
thoroughly sympathize with the desire to get it out of the group so
that the energy of the group could focus on getting closed.  I also
sympathize, however, with your desire to get timely review for this
work.  
	Keith and Patrik asked for reviewers from discuss@apps last
year to get focus on the draft from a broad group.  I think that was a
good thing, and I hope we can keep it as a review mechanism (Maybe we
should even make it an earlier part of the standard
individual-submission review process; rather than wait until one of
the two ADs has cycles for a review, get some input early on and let
them review a later version with some of the design rational clarified
and arguments worked out).  Some of the reviewers were actually HTTP
participants (Larry, Koen, et al); others were familiar with similar
issues in other groups (Chris Newman, Graham Klyne).  There probably
wasn't enough review (it was December then, too), but some of the
architectural differences you allude to below did get exposed.
	Given that there were architectural differences, the question
becomes, what should have happened next to resolve them?  There were
three options: a working group to consider the problem (note: not the
draft, but the problem it attempts to solve) could have been formed so
that rough concensus could have developed around a solution; the draft
could have been kicked back and forth between the ADs and document
author until the ADs were satisfied that the architectural problems
had been handled (this takes a *lot* of cycles from people who have
few available); and the draft could go to experimental as a stable
specification and basis for work that may eventually get standardized.
	Depending how you understand the problem, the effort to get
applecore going could be seen as theory 1; it did not take for granted
a basic design principle of this document (must interoperate with HTTP
1.x), but it did have as a goal a stable application core so that
extensions could re-use it.  That effort took time, and it did not get
a groundswell of support.  Shifting after that to an experimental
model for this draft makes sense to me as a way of nailing the
standard down so people can work from it.  It gives the community a
way of working out the architectural issues in practice without
totally presuming the answer.
	Your note below that appointing an app directorate which can
"object to proposals and provide timely technical/philosophical
feedback" as a solution seems to me to indicate that you would have
prefered theory 2 to either theory 1 or theory 3.  It also seems to
miss the point.  The ADs aren't the app area; they are the technical
managers of the area.  The app area itself needs to have the cycles
and interest in providing timely technical/philosophical feedback.
Part of the area directors work as managers is to encourage that
feedback and channel the response so that it solves the underlying
problems rather than just editing the drafts.  By putting this forward
as experimental, the ADs have approved a stable specification for
further work--that, hopefully, will give us a way to channel feedback
on whether this draft solves the underlying problem.
			regards,
				Ted Hardie


> 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.
> 
> Henrik
>

Received on Tuesday, 7 December 1999 15:13:01 UTC