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 * Mike Spreitzer Transport Area Directors * Scott Bradner * Vern Paxson Responsible Area Director * Vern Paxson Mailing List The 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.