****************************************************************
HTTP-NG BOF at IETF-43
13:00--15:300 on Monday, Dec 7, 1998
Edited by Mike Spreitzer, based on a transcript
(http://lists.w3.org/Archives/Public/ietf-http-ng/1998Dec/0016.html) recorded
by Rohit Khare.
A BOF was held to consider forming a Transport Area Working Group to work on
HTTP-NG. Presenting the case for such a Working Group were Jim Gettys, Henrik
Frystyk Nielsen, and Mike Spreitzer. There was significant interest, with much
approval and also some significant dissent. Ultimately there was consensus to
move forward with some of the work and to consider the rest more carefully.
The details follow.
Henrik Frystyk Nielsen opened the session by setting the context. There was an
HTTP-NG BOF at IETF-42 in Chicago in August, at which there was a detailed
introduction to the proposed work for the IETF. Reaction was mild and
generally favorable (minutes, which did not make it into the official IETF-42
proceedings, can be found at
http://www.w3.org/Protocols/HTTP-NG/1998/08/HTTP-NG-BOF-Minutes.html).
However, there was no proposed charter or chair at that time, and so no WG
could be formed. Now we have proposed chair, Jim Gettys and Mike Spreitzer,
and charter, which will be presented here.
Henrik also presented some results obtained in the W3C testbed since August.
He showed a slide reporting time and bytes used to transfer the Microscape page
(including inlined images) and a simple test page over a path that included a
wireless link. The graphs showed HTTP/1.1 making a large improvement over
HTTP/1.0, and HTTP-NG making a modest improvement over HTTP/1.1. The 1.1 test
used libwww, a highly optimized 1.1 implementation; the NG test was in the
ILU-based testbed, which has received essentially no performance tuning.
Mike Spreitzer then lead a presentation of
draft-frystyk-httpng-overview-00.txt, a draft overview of the problem
statement, requirements, and solution outline for the proposed HTTP-NG Working
Group. The presentation was a brief introduction to the I-D's contents; a few
comments augmented those contents, as follows. There are two dimensions of
modularity: a "vertical" modularity of layering and a "horizontal" modularity
of independent multiple protocol modules at the same layer. The https URI
scheme is an example of layering failure: just adding security required going
to a new namespace, and without an upgrading facility. It may be desirable to
further split the middle layer into two sublayers: one for the control aspects
and one for data formatting. The transition from HTTP/1.1 to HTTP-NG should be
easier than, e.g., the transition to IPv6, because it can be done on a
link-by-link basis instead of having to be available end-to-end. So adopters
can be incented incrementally, initially focusing on client/server (one-hop,
not browser/origin-server) pairs that can most clearly see a high payoff;
possible examples include: high-level cache and origin server; browser and
low-level cache (e.g., over wireless link); low-level and high-level cache.
The possible payoffs include: performance, functionality (resulting from better
evolvability), and manageability (a multifaceted concept, including firewall
considerations). An analogy was made between the way HTTP-NG increases HTTP's
modularity and the way XML, by simplifying SGML and generalizing HTML, makes it
easier to churn out new tag sets. The current situation, with HTTP being
cloned and tunnelled through in a number of ways, was characterized by some as
a "train wreck". Among other things, it makes it difficult for a firewall to
discern what's really going through it. Some suggested this "train wreck" is
really a good thing, just a healthy diversity of protocol re-use. Others
considered it a success disaster, motivating change.
Jim Gettys then gave a brief introduction to the proposed charter.
Here is the proposed charter:
----------------------------------------------------------------
IETF HTTP-NG Charter
Working Group Name
* HTTP Next Generation (httpng)
IETF Area
* Transport Area
Chairs
* Jim Gettys <jg@w3.org>
* Mike Spreitzer <spreitze@parc.xerox.com>
Transport Area Directors
* Scott Bradner <sob@harvard.edu>
* Vern Paxson <vern@ee.lbl.gov>
Responsible Area Director
* Vern Paxson
Mailing List
The <ietf-http-ng@w3.org> mailing list and archives
(http://lists.w3.org/Archives/Public/ietf-http-ng/) are available
for discussions of HTTP-NG. Postings to this mailing list from
non-subscribers are moderated in order to avoid spam, everything
else will be passed as is. See the W3C Mailing list administrativia
(http://www.w3.org/Mail/Request.html) for details.
Description of Working Group
The goal of this working group is to produce a next generation of the HTTP
protocol that builds on the experience from HTTP/1.x --- notably including
proxies, caching, and firewalls --- by adding explicit layering and
modularity to better support the World Wide Web and the other applications
that are being layered on top of, and just plain tunnelled through, HTTP.
The WG goals will emphasize transitioning existing application
functionality to a better technology base, rather than improving the
application functionality.
The WG will first develop a requirements document detailing the needed
changes to the HTTP/1.x protocol. An already-existing draft of this
document calls for the factoring of HTTP into three layers: the lowest will
provide opaque message transport services needed by the next layer,
building upon current and/or future Internet transport protocols such as
TCP and UDP; the middle will be a general remote invocation layer; and the
highest will be an expression of the web application in terms of the lower
two.
The WG will then proceed to standardize the pieces into which HTTP is to be
factored. The WG will also develop techniques for the transition of the Web
from HTTP/1.x to HTTP-NG.
The following work is specifically excluded from the scope of this working
group: definitions of language mappings and/or ancillary APIs for the
remote invocation layer; significantly advancing the functionality of web
applications; development of base transport protocols (e.g. any replacement
for TCP).
Because HTTP's functionality spans a range that includes both the Transport
and Application areas of the IETF, this working group should draw
participants from both areas.
The working group will ensure that there is an adequate flow of information
between the working group and the W3C allowing W3C to better coordinate W3C
Activities related to HTTP-NG and to provide input to the working group.
Goals and Milestones
* 1998/12 - I-D of problem statement and solution outline
* 1999/01 - I-D of W3C project's proposal for message transport layer
* 1999/01 - I-D of W3C project's proposal for invocation layer
* 1999/04 - Problem statement and solution outline submitted to IESG for
publication as Informational RFC
* 1999/06 - WG consensus I-D on message transport layer
* 1999/08 - WG consensus I-D on invocation layer
* 1999/11 - WG consensus I-D on web application interfaces
* 1999/11 - message transport layer specification submitted to IESG for
publication as Proposed Standard
* 2000/02 - invocation layer specification submitted to IESG for
publication as Proposed Standard
* 2000/05 - web application interfaces submitted to IESG for publication
as Proposed Standard
Working Drafts and Notes
Here is the list of drafts that were presented and discussed at the HTTP-NG
BOF at IETF-42:
* HTTP-ng Architectural Model (draft-frystyk-httpng-arch-00.txt),
Internet Draft, August 1, 1998
* HTTP-ng Web Interfaces (draft-larner-nginterfaces-00.txt), Internet
Draft, August 1, 1998
* HTTP-ng Binary Wire Protocol (draft-janssen-httpng-wire-00.txt),
Internet Draft, August 1, 1998
* WebMUX Protocol Specification (draft-gettys-webmux-00.txt), Internet
Draft, August 1, 1998
* Design of HTTP-ng Testbed, W3C Note, 10 July 1998
* Short- and Long-Term Goals for the HTTP-NG Project, W3C Note, 27 March
1998
Background Information
* HTTP-NG BOF at the IETF Chicago Meeting, August 23-28 (minutes at
http://www.w3.org/Protocols/HTTP-NG/1998/08/HTTP-NG-BOF-Minutes.html)
* Check the W3C HTTP-NG overview (http://www.w3.org/Protocols/HTTP-NG) for
more information.
----------------------------------------------------------------
It was noted that the dates on the milestones are particularly tentative.
Discussion then ensued.
Security was discussed. The design in the drafts was reiterated: the design
starts with the lowest layer providing some subset of authentication, message
integrity, and message secrecy; the middle layer may add to that; and in the
highest layer the application starts to build on the services provided by the
lower layers. There was concern that collaborators inside and outside a
firewall could still collude to tunnel information through the more
understandable channel being created. Due to time pressures, the conversation
was cut short before anyone could observe that that's always true and that
nonetheless there are benefits to making traffic more comprehensible to
firewalls.
Many participants, although not all, felt that the lower layers were more
"baked" than the higher ones. The audience generally found the available
documents about the lower layers to be more clearly understandable than the
documents about the higher ones. It should be noted that the attendance was
dominated by the Transport Area, although there definitely were some
Applications Area people in attendance (although the Apps ADs were not among
them).
There was concern that the charter wasn't specific enough ("lack of
concreteness and testable assertions") --- that everybody could agree to the
text in the charter without actually agreeing with each other about what it
means --- and that this was a weakness. The proponents actually have a much
more detailed opinion, but many of those details were deliberately kept out of
the charter on the grounds that they are things the WG should debate and reach
consensus on. Some felt that too much, such as design principles articulated
by Bill Janssen at the previous BOF, was left out of the proposed charter.
There was concern about leaving the WG with too much problem definition work to
start out with. In the interest of getting through all the audience's input in
time, the discussion moved on before satisfactorily finishing with this topic.
There was some discussion of the length of time that would be required. In the
interest of getting through all the audience's input in time, the discussion
moved on before satisfactorily finishing with this topic
There was concern about the current competition in the distributed object
standards marketplace (CORBA vs. DCOM vs. Java RMI vs. web-based thingies vs.
...); perhaps the IETF cannot and should not try to settle this; instead get
more deployment and experience with HTTP/1.1, IPP, DAV, etc and wait for the
marketplace to settle the wars. Not everyone agreed that this is the right
reaction. It was also noted that the competition is mainly over API turf, and
that the combatants have shown considerable flexibility on protocol. The
HTTP-NG proponents have had favorable discussions with the OMG and with
Microsoft's DCOM group (representatives of neither of which were in evidence at
the BOF) about the possibility of running CORBA and DCOM over HTTP-NG's lower
two layers. In the interest of getting through all the audience's input in
time, the discussion moved on before satisfactorily finishing with this topic.
There was debate over the appropriateness of using "HTTP" in the name. Some
felt that the genericity of the lower two layers, and the lack of byte-wise
protocol continuity with HTTP/1.1, makes it inappropriate to use "HTTP" in the
name. Others felt that as the goals include replacing HTTP, the proposed name
is fair. In the interest of getting through all the audience's input in time,
the discussion moved on before satisfactorily finishing with this topic.
There was concern that the proposal was too ambitious, in that it opens too big
a can of design worms. Some argued for making a set of incremental changes to
HTTP/1.1; others (including authors of the HTTP/1.1 spec) argued that progress
on 1.1 is very difficult due to its lack of modularity, that's why HTTP-NG
should be done. Others asked: why take up design of a new remote invocation
protocol when the IETF already has ONC RPC? The proponents answered that what
they have done can be viewed as an extension of ONC RPC to deal with ways in
which it is deficient for supporting Internet applications such as the WWW.
Lack of support for objects was cited as one such deficiency, although some in
the audience thought that was a Good Thing. No other deficiencies were
mentioned, due to lack of time. Another question was: why create another such
protocol when the world already has too many? The answer is that the intent is
to unify the existing ones: move the web onto a suitably general HTTP-NG, and
the other distributed object systems will adopt NG's invocation protocol.
Another question was: wouldn't designing a new remote invocation protocol
invite "experts" from all over, making the design process drag on forever?
Some felt that the work on the middle layer should be remanded to the IRTF.
Others felt that enough work had been done to show that there is an acceptable
solution, so it's not research and wouldn't take forever to reach consensus on.
On the other hand, concern was also expressed that an existing prototype would
unduely constrain the requirements-setting phase; not everyone was worried
about this, and having a measurable prototype is a good thing. The proponents
pointed out that they had deliberately put in a scope limitation to actual
applications, rather than all the existing middleware systems (e.g., Java RMI,
DCOM, and some CORBA implementations) that can currently tunnel through HTTP,
as a way to limit desiderata brought to bear on the middle layer. There was
concern that having to track application development would be a never-ending
task. Naturally an HTTP-NG WG would at some point have to say "enough!", and
hopefully by then it would have a sufficiently general protocol to be useful in
other applications without needing to explicitly prepare for them. In the
interest of getting through all the audience's input in time, the discussion
moved on before satisfactorily finishing with this topic.
Some argued that the proposed work should be split into two WGs, one on the
lower two layers and one on the highest layer (the "web application"). This
has several virtues. One is that this would allow better alignment with IETF
Areas: the higher WG could go into the Apps Area, with the lower WG in
Transport. Another is general manageability: divide and conquer. Another is
that work should be done on improving the web application's functionality
(something expressly excluded in the proposed charter above) --- that is,
particular extensions, not just extensibility --- and that it would naturally
find a home in the upper of two HTTP-NG WGs. On the other hand, forming just
one WG has some virtues too. The Apps Area is currently overloaded, and simply
cannot take on a new major chunk of work. Another is that keeping all the
HTTP-NG work together helps make sure it really works together. And it is
appropriate to view HTTP-NG as a single integrated effort, because it needs to
replace a single integrated protocol (HTTP/1.1). In the interest of getting
through all the audience's input in time, the discussion moved on before
satisfactorily finishing with this topic.
There was a misplaced concern about replacing the web application's use of the
open extensible Internet Media Type (AKA MIME type) space with something else
(not sure what); the proposal is actually to keep that as it is. It was noted
that some applications deliberately try to "pun" a user interface and a
programmatic interface together into one thing (typically an HTML form). These
applications will continue to layer over HTML and all of HTTP/whatever,
regardless of what "whatever" is, because they want all of the web
application's functionality; they don't care directly about factoring HTTP, but
will appreciate any incidental benefits such as improvements in performance,
functionality, etc.
There was concern that the performance gains will be too small to justify the
effort. The slide that Henrik showed at the start showed only a modest
performance gain. However, that compared a well tuned 1.1 implementation
against a poorly tuned (some might say de-tuned) NG implementation. And it
doesn't prove that more gains can't be had. And it addresses only one
scenario. In the interest of getting through all the audience's input in time,
the discussion moved on before satisfactorily finishing with this topic.
Jim Gettys tested and found consensus to proceed with work on the lowest layer
and to work on more clearly articulating the problem statement and requirements
for the rest of HTTP-NG.