Re: HTTP-NG Working Group?

Thanks for your comments, Scott.

I think they indicate that we weren't quite clear enough in the BOF
about why HTTP-NG is a direct follow-on to HTTP, though.  Perhaps I can
do better here...

HTTP 1.1 contains elements of several distinct layers.  The specific
methods defined in it (GET, HEAD, etc.) go back to the object-oriented
origins of HTTP, as does the terminology.  They are really about a
specific application, the Web application, which is a basic
document-managment application.  The elements dealing with chunking,
message-boundary marking (Content-length), persistent connections, etc.,
are a low-level transport kind of layer.  Most of the rest define a
specific wire-protocol, or messaging layer, that attempts to be
independent of these other two levels.  But often fails.  To my mind,
that failure is because the crucial differentiation between
method-independent elements of the wire protocol, and method-specific
parameters, was never clearly spelled out.  To make things worse, no
clear system for sending method-specific parameters was ever adopted for
HTTP.  Some folk use optional headers, some embed them in the URL, some
pass an entity-body containing them.

Many of the problems with `extending' HTTP for other applications (other
than the `Web' application) seem to be caused by this poor
differentiation of elements.  What we've tried to do in HTTP-NG is to
factor out these layers so that each can be evolved independently, and
provide answers to the problems we've seen (poor extensibility,
excessive open connections, wasted bytes with inefficient headers,
wasted time in overloaded servers by using textual marshalling where
it's not natural, multiple conflicting uses of HTTP POST as an
inefficient reliable datagram transport, etc.).  This permits simple,
clear, quick use of the basic HTTP substrate for the many other
applications that wish to use it.  It should improve things all around,
particularly with firewalls, which no longer have to keep track of the
multiple ways applications are tunnelled through HTTP.

The Transport area seems an appropriate home for a large part of the
HTTP-NG effort, namely the identification of a standard type system, the
marshalling protocols for messages, the development of the flexible
transport stack, the continuation of the webmux work.  All of that is
application-independent work, which can profit from the experience of
the Transport area experts.  In addition, the work is similar to that
undertaken by the ONC RPC working group, which is also in the Transport
area.  However, I think you've got a point about the development of the
TCWA (the Classic Web Application) interfaces, which is really an
Application area kind of project.  We've discussed these concerns with
the appropriate area directors, and they feel that sufficient
Applications area expertise can be brought into the working group even
if chartered in the Transport area.

Hope this helps...

Bill

Received on Monday, 31 August 1998 21:48:21 UTC