2004/id/draft-frystyk-httpng-overview-00.txt



       INTERNET-DRAFT             HTTP-NG Overview    H. Frystyk Nielsen, W3C
       draft-frystyk-httpng-overview-00.txt        Mike Spreitzer, Xerox PARC
                                                     Bill Janssen, Xerox PARC
                                                       Jim Gettys, Compaq/W3C

       Expires: May 17, 1999                       Tuesday, November 17, 1998


                                  HTTP-NG Overview
                Problem Statement, Requirements, and Solution Outline


       Status of this Document

       This document is an Internet-Draft. Internet-Drafts are working
       documents of the Internet Engineering Task Force (IETF), its areas,
       and its working groups. Note that other groups may also distribute
       working documents as Internet-Drafts. Internet-Drafts are draft
       documents valid for a maximum of six months and may be updated,
       replaced, or obsoleted by other documents at any time. It is
       inappropriate to use Internet-Drafts as reference material or to cite
       them other than as "work in progress".

       To learn the current status of any Internet-Draft, please check the
       "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
       Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
       munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
       ftp.isi.edu (US West Coast).

       Distribution of this document is unlimited. Please send comments to
       the <ietf-http-ng@w3.org> mailing list. This list is archived at
       "http://lists.w3.org/Archives/Public/ietf-http-ng/".


       Abstract

       This document gives the authors' opinion of a rough outline of (1) the
       problems to be addressed by the proposed IETF HTTP-NG Working Group;
       (2) the requirements on the solution; and (3) the architecture of the
       solution. It draws heavily on contributions from the whole Protocol
       Design Group of the W3C HTTP-NG Activity. A suite of problems should
       be addressed, summarized as observing that the World Wide Web's
       tremendous success has created some strains on the Internet, its
       users, and its application developers. The requirements on the
       solution include modularity, extensibility, scalability, and
       efficiency. The proposed solution is to factor HTTP, the Web's central
       protocol, into three layers and look into performance improvements in
       the lower two of those resultant layers.


       Table of Contents

       1.   Problem Statement..............................................2
       2.   Requirements...................................................3
         2.1  Simplicity at the Core.......................................3
         2.2  Distributed Extensibility....................................4
         2.3  Global Scalability...........................................5


       Frystyk et al                                                 [Page 1]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


         2.4  Network Efficiency...........................................5
         2.5  Transport Flexibility........................................6
       3.   Solution Outline: The Three Layers of HTTP-NG..................6
         3.1  Message Transport............................................7
         3.2  Remote Invocation............................................7
         3.3  The Web Application..........................................8
       4.   Security Considerations........................................9
       5.   Deployment and Transition Strategies..........................10
       6.   References....................................................11
       7.   Acknowledgements..............................................12
       8.   Authors.......................................................12

       1. Problem Statement

       The World Wide Web is a tremendous and growing success and HTTP has
       been at the core of this success as the primary substrate for
       exchanging information on the Web. However, HTTP/1.1 [3] is becoming
       strained modularity wise as well as performance wise and those
       problems are to be addressed by HTTP-NG.

       Modularity is an important kind of simplicity, and HTTP/1.x isn't very
       modular. If we look carefully at HTTP/1.x, we can see it addresses
       three layers of concerns, but in a way that does not cleanly separate
       those layers: message transport, general-purpose remote method
       invocation, and a particular set of methods historically focused on
       document processing (broadly construed to include things like forms
       processing and searching).

       The lack of modularity makes the specification and evolution of HTTP
       more difficult than necessary and also causes problems for other
       applications. Applications are being layered on top of HTTP, and these
       applications are thus forced to include a lot of HTTP's design ---
       whether this is technically ideal or not. Other general invocation
       systems (notably including originally Web independent ones like DCOM,
       Java RMI, and some CORBA implementations) are also being layered on
       top of HTTP. Furthermore, to avoid some of the problems associated
       with layering on top of HTTP, other applications start by cloning a
       subset of HTTP and layering on top of that. Some of the particular
       problems that arise from HTTP/1.x's lack of modularity include (but
       are not limited to) the following.

          o The fact that message delimiting in HTTP/1.1 is not done in a
            distinct layer but rather is mixed with other functionality leads
            to a very complex specification involving five different ways to
            delimit a message (see [3], section 4.4).
          o Because general applications are being tunneled through HTTP's
            document fetching and forms processing methods (GET and POST) ---
            and in a wide variety of ways --- it is very difficult for a
            firewall to discern the semantic content of a given interaction,
            which makes it very difficult for a firewall to apply security
            policies.


       Frystyk et al                                                 [Page 2]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


          o Tunneling other applications through document processing methods
            invites confusion (between the document processing application
            and the tunneled application(s)) on a number of fronts (see [5]
            for a discussion of complexities of using HTTP as a substrate
            that arise even when such layering is deemed appropriate within
            HTTP/1.x)
          o Tunneling other applications through HTTP's document processing
            application requires a degree of quoting/encoding that would not
            be necessary with a more modular HTTP.
          o Because HTTP's invocation layer design is intimately tied to its
            document processing application, designers of other applications
            have a non-trivial job in trying to figure out how to use the
            invocation layer for their own applications.

       There are two sides to the performance strains to be addressed. One
       side is the load presented to the Internet (HTTP accounts for the
       largest fraction of traffic on the Internet). Making HTTP use Internet
       resources more efficiently would have a real benefit for everyone. The
       other side is the performance delivered to end users and applications,
       which is often low on the general Internet today. Furthermore, usage
       of wireless is anticipated to grow significantly in the near future,
       and many wireless technologies deliver relatively low bandwidth and
       high latency which makes delivering good performance to users and
       applications even more challenging.


       2. Requirements

       The continuous growth of the Web depends on the availability of a
       simple yet powerful mechanism for exchanging information on the
       Internet. The purpose of the work proposed here is to design the next
       generation of the HTTP protocol that fulfills a set of requirements
       and at the same time preserve a simplistic design: complex features
       should be built on a simple base.

       Even though HTTP/1.1 overcomes many of the deficiencies in HTTP/1.0
       [1], it does not change the overall nature of the protocol. The
       explicit design decision of keeping HTTP/1.1 backward compatible with
       HTTP/1.0 has prevented a real cleanup of its architecture. By
       loosening this constraint, HTTP-NG can address the following
       requirements.

       The requirements listed below are specific points put forward where
       improvements are needed (see also [11]). These are in addition to the
       general design principles laid out in [2]. We hope that the list will
       spur further discussion on the working group mailing list about
       inconsistencies or omissions (see [12]).


       2.1 Simplicity at the Core

       Simplicity is a key element in systems that are easy to understand,
       implement, and maintain. Over time, HTTP has lost a significant part


       Frystyk et al                                                 [Page 3]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       of its initial simplicity by combining a number of different concerns
       at different levels into a single large protocol. The result is a
       protocol that is difficult to understand, implement, and modify in a
       robust and reliable manner; primarily because the line between
       extensions/applications and the core infrastructure has become blurry.

       Modularity provides one form of simplicity with the potential of
       allowing the core infrastructure to remain small and well defined over
       time while applications can grow yet more complex on top. This is
       likely to help minimal implementations with limited capabilities to
       coexist with more capable implementations. Furthermore, applications
       themselves are likely to benefit from modularization as they are less
       prone to inadvertently stepping on each other.

       By factoring the elements of HTTP into appropriate layers and modules,
       HTTP-NG must attempt to produce a simpler but more capable and more
       flexible system than the one currently provided by HTTP.


       2.2 Distributed Extensibility

       A wide range of applications have proposed various extensions to HTTP
       including distributed authoring, collaboration, printing, and remote
       procedure call mechanisms leading to a growing tension between
       dynamically extensible applications and public, static specifications.
       Due to the inherently unstructured extensibility model of HTTP/1.x,
       there is no guarantee that these extensions are dealt with as intended
       nor that they can applied to the same message without conflicting. The
       result is a lack of robustness in the current Web infrastructure which
       is unacceptable for many potential Web applications and which may lead
       to Web fragmentation and lack of interoperability.

       The requirement to extensibility is that extended applications do not
       require agreement across the whole Internet; rather, it suffices:

          o that conforming peers supporting a particular protocol extension
            or feature can employ it with no prior agreement;
          o that it is possible for one party having a capability for a new
            protocol to require that the other party either understand and
            abide by the new protocol or abort the operation; and
          o that negotiation of capabilities is possible.

       Note that the requirements are on the core infrastructure and not on
       the extensions and their semantic interactions using this
       infrastructure. That is, it is not a requirement that interactions
       between extensions be defined, only interactions between extensions
       and the core infrastructure. The former is a much harder problem that
       we don't believe can be solved generically.

       The HTTP Extension Framework proposes a mechanism for defining
       extensions in HTTP/1.x and keeping them separate from each other
       enabling better support for the type of evolution of features and


       Frystyk et al                                                 [Page 4]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       applications seen in the Web. However, this mechanism can not change
       the behavior of existing HTTP features like the existing HTTP/1.1
       caching model, for example, and so the applicability of the extension
       framework is limited.

       By putting this kind of extensibility into the core of HTTP-NG, new
       features can be introduced and existing features can be replaced
       dynamically putting better evolvability into the heart of the
       architecture.


       2.3 Global Scalability

       HTTP needs to be effective and efficient when deployed in the full
       global system that includes all the clients, servers, caches, proxies,
       gateways, tunnels, and other intermediaries and their interactions
       over the global Internet and all the connected intranets. HTTP is the
       single protocol that now consumes most of the Internet bandwidth. Any
       replacement to HTTP/1.1 will have to address the foreseeable growth
       that one can expect in the near future. Measurements show [4] that
       scalability is not isolated to a single part in the Web model but
       affects all layers ranging from low level transport protocols to high-
       level user interfaces. Even though HTTP-NG focuses on the protocol
       related different encodings of the contents may have as big an impact
       as improving the underlying transport. An example is the potential
       savings using style sheets instead of inlined images for representing
       typographical effects in Web pages.


       2.4 Network Efficiency

       One can argue that bandwidth and latency of the Internet will improve
       dramatically over the next couple of years. However, wireless PDA's,
       portable machines and satellite links will continue to impose severe
       practical limits on the available bandwidth, latency and on-line
       connectivity on parts of the Internet. We consider it likely that low
       bandwidths in the 9600-19200 bps range and latency in the >1/2 second
       range will be with us for a long time.

       It is important to note that latency and bandwidth are independent
       variables; for example satellite IP systems exist today which provide
       good bandwidth to remote locations, but poor latency. Most users of
       the Web are today at home using a dial-up connection with a 28.8 kbps.
       On the optimistic side, this provides a minimum of 160 ms from the
       closest part of the Internet. Cellular modems and many wireless
       systems have even higher latency and lower bandwidth.

       HTTP is a simple request/response protocol, not designed for the
       environment where it is now most heavily used. In [4], it is described
       how persistent connections and pipelining in HTTP/1.1 will solve some,
       but not all of these problems. The reason is that HTTP/1.1 is designed
       to limit TCP overhead produced by HTTP/1.0 but not protocol overhead


       Frystyk et al                                                 [Page 5]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       due to HTTP itself. As an example, HTTP/1.1 defines 5 different
       mechanisms for finding the length of a message, of which all but
       closing the TCP connection require significant parsing to determine
       which one is used.

       Automatable, machine-readable messages are different from human
       readable messages even though they may both be encoded using ASCII
       strings. The choice of MIME based header encoding in HTTP has led to
       the general misconception that HTTP is intended as a human readable
       protocol. The result has been verbose messages and extremely
       complicated parsers. As an example, a typical HTTP request is about
       250 bytes long. Due to the nature of typical Web usage, subsequent
       requests are often closely related leading to about 90% in redundancy
       between requests. This means slowing down information exchange over
       low bandwidth connections.

       If HTTP does not improve its performance dramatically on low bandwidth
       connections, it is likely that other more compact and lightweight
       protocols will be deployed with the risk of incompatibility between
       low bandwidth sensitive devices. HTTP-NG will attempt to optimize the
       bandwidth/latency usage of HTTP, at several levels.


       2.5 Transport Flexibility

       Although ensuring the stability of URIs to a high degree is a social
       engineering task, it is as important that the Web infrastructure
       supports evolution of transports. For example, a single resource may
       be available through different access protocols supported by the party
       serving the resource. These access protocols may or may not be
       compatible: HTTP/0.9, HTTP/1.0, and HTTP/1.1 are backwards compatible
       protocols but HTTP running on top of SSL is not although it is in fact
       using HTTP as part of the transport stack.

       HTTP-NG should have an architected way of using any of an open,
       extensible set of transport substacks and should allow for transport
       stacks that do not necessarily include TCP. Furthermore, HTTP/NG's
       architecture should have a generalized notion of transport
       transformers, of which SSL and TLS are examples but not the only
       possibilities.


       3. Solution Outline: The Three Layers of HTTP-NG

       The solution outlined in this section describes the solution that has
       been developed as part of the W3C HTTP-NG Project using a prototype
       implementation [10]. It attempts to address the requirements laid out
       above by factoring HTTP into three layers and by looking into
       performance improvements in the lower two of those resultant layers.
       Here is a brief outline of the three layers into which HTTP is to be
       factored (see also [6]).


       Frystyk et al                                                 [Page 6]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       3.1 Message Transport

       The lowest layer addresses concerns of simply transporting opaque
       messages for use by the middle (remote invocation) layer. This layer
       identifies a "message transport" abstraction, and the concept of
       "transformers" or "filters" that produce new message transports from
       other message transports. "Message transports" are built on top of
       existing -- and potentially future -- Internet "transport" protocols,
       such as TCP and UDP. HTTP-NG allows the use of a variety of message
       transport substacks or services; this provides a welcome flexibility
       for addressing current, future, and evolvability concerns at the
       message transport layer.

       In particular, there is a set of services that have shown to be often
       needed in the Web and other applications:

          o Batching and pipelining of messages in order to save round trip
            times which especially on dialup lines and wireless connections
            are significant.
          o Chunking and multiplexing of messages which can help fast
            rendering of pages as well as faster responses from caches where
            already cached responses can be returned out-of-order without
            waiting for non-cached responses.
          o Efficient record marking for lowering parsing overhead of
            determining the message length.
          o Support for callback functions via endpoint identification for
            notifications etc. needed by an important set of applications.

       Although these services are distinct services, they are related in
       such a way that we propose to combine them in a single filter called
       WebMux [9]. WebMux is not to be considered an independent transport,
       it is likely to provide the services listed above by taking advantage
       of the services provided by lower level transports like TCP, for
       example, much like HTTP/1.x provides a set of transport services in
       combination with TCP.

       While WebMux potentially can work with other transports, a particular
       important combination is WebMux running on top of TCP. We are still in
       the evaluation phase of the interactions between WebMux and TCP with
       respect to handling support for announcing buffer capabilities.
       HTTP/1.x clients are currently expected to provide essentially
       unlimited buffering which especially in certain HTTP/1.0 and HTTP/1.1
       proxy interactions can cause clients to fail in unpredictable ways
       leading to unreliable situations and denial of service attacks. We
       intend to discuss this further as part of the HTTP-NG working group.


       3.2 Remote Invocation

       The middle layer is a generic request/response messaging layer where
       clients make use of services exported from a server by invoking
       operations on resources resident in that server. It provides a
       mechanism for remote invocations suitable for use by the Web


       Frystyk et al                                                 [Page 7]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       application and also by other applications that are currently being
       layered on top of HTTP (whether directly or indirectly via other
       layered remote invocation systems).

       The layer does not contain any application-specific services like
       security or caching, or other application layer functionality. It
       assumes a hop-by-hop operation where proxies are supported at the
       higher-level application layer and uses the set of services provided
       by the message transport layer.

       Suitability for use by the Web application means, among other things
       that

          o it be byte efficient which not only is important on dialup lines
            and wireless connections but also for operations like cache
            validation which are likely to become widespread used.
          o it be easy to parse which especially is important for servers and
            proxies
          o it supports the type of distributed extensibility currently seen
            in the Web

       By designing an invocation protocol that serves this breadth of
       applications, particularly including the ones that use other remote
       method invocation systems, we hope to eventually reduce the number of
       invocation protocols in use.

       It is not a goal to support every single one of the features of CORBA,
       DCOM, or Java RMI in their current forms, but rather -- by being "good
       enough" for those systems' actual applications -- to be a force for
       unification. It is not a viable solution to simply adopt CORBA, DCOM,
       or Java RMI for this layer, because each -- in its current form -- has
       technical and/or political liabilities for Web use. The hope is that
       HTTP-NG's invocation protocol is eventually adopted by those other
       systems.

       The HTTP-NG work should include defining a network interface
       definition language (the highest layer will need to be expressed in
       some language). It is recognized that there could be multiple
       interface languages for use with a given invocation protocol. In
       particular, it is possible that a XML based solution and/or future
       versions of existing interface definition languages will be suitable
       here. For this reason and for general modularity and clarity, the
       subject matter of the invocation protocol --- objects, other data, and
       invocations --- is defined in a language-independent way (see [8]).


       3.3 The Web Application

       With the lower two layers of HTTP-NG in place, it remains to express
       the operations and application layer services of HTTP/1.1 including
       the current set of methods (GET, HEAD, PUT�), content negotiation,


       Frystyk et al                                                 [Page 8]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       caching, access authentication, etc. as particular network interfaces
       using those lower two layers.

       The application layer is application-specific meaning that the
       particular set of network interfaces defining an application varies
       from application to application.  For example, the Web application
       defined by HTTP/1.1 would constitute a different application than the
       WebDAV application (though they might share some common part).

       The HTTP-NG architecture allows multiple applications to co-exist at
       this level, and provides a mechanism for adding new applications
       without stepping on existing applications. Furthermore, applications
       are defined both statically, in terms of the type system at the second
       layer, and dynamically, in terms of the transport elements of the
       first layer allowing for protocol evolution to happen independent of
       interface evolution.

       While it is tempting to try to improve on the existing Web application
       functionality, that is not the main focus of the HTTP-NG work. HTTP-NG
       is essentially about transitioning the existing functionality to a
       better technology base and as every difference from the Web
       application defined by HTTP/1.x places a strain on the transition,
       these are to be minimized. However, "the existing functionality" is
       itself a moving target and so HTTP-NG must track that closely to make
       HTTP-NG a viable replacement.


       4. Security Considerations

       The division of responsibility for security services should be as
       follows. The lower two layers are responsible for providing some
       subset of the authentication, message integrity, and message secrecy
       security services; applications provide whatever other security
       services they need (e.g., authorization, auditing, accounting, further
       authentication) based on the services provided by the lower layers.
       Which services are supplied by the lower two layers, and which
       mechanisms are used to supply them, is a function of the choice of
       message transport and invocation protocol(s) used. To support this
       variety of possibilities, the message transport and invocation
       abstractions must use an open, extensible categorization of security
       principals and credentials.

       HTTP-NG must interact with firewalls at least as well as HTTP. This
       includes

          1.  the ability of a firewall and its operator to manage traffic
              through the firewall; and
          2.  the ability of users and applications to get through firewalls
              that don't want to block them.

       On the first issue, HTTP-NG's very nature leads to an improvement over
       the current Web situation: by replacing a wide variety of ways of


       Frystyk et al                                                 [Page 9]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       tunneling other applications through HTTP/1.x with a defined way of
       basing applications on a standard invocation mechanism, HTTP-NG
       traffic will be more comprehensible (and thus more manageable) to
       firewalls. One the second issue, the existing Web architecture already
       does a decent job in one direction (client behind firewall to server
       outside), and HTTP-NG should do at least as well as the current Web
       for the other direction (client outside firewall to server inside).


       5. Deployment and Transition Strategies

       The purpose of HTTP-NG is not only to allow for new applications to be
       developed and deployed in the Web but also to provide an incentive for
       moving existing applications already seen in the Web onto the HTTP-NG
       substrate. First and foremost, this of course includes the services
       provided by the HTTP/1.1 protocol itself like content negotiation and
       caching which are integral parts of the current Web application.
       However, HTTP/1.x is in fact only the tip of the iceberg. HTTP is
       being extended or augmented locally in intranets as well as globally
       on the Internet at large either directly or indirectly via other
       layered remote invocation systems. The myriad of applications is
       forcing extensions to HTTP/1.x and threatens the interoperability of
       the Web. The lack of an interface signature at the invocation layer
       makes security policy very difficult to enforce, and inhibits the
       deployment of automated services in the Web.

       In order for this situation to change, the incentive has to be strong
       enough for application providers and extension designers to actually
       deploy the HTTP-NG substrate for new as well as existing applications.
       As the investments in the current infrastructure is already extremely
       high, this is likely to be a process that will continue for a very
       long time and potentially have very slow start phase.

       There are at least two different types of transitions that have to
       evaluated and tested:

          o The transition from the current HTTP/1.x infrastructure to one
            based on HTTP-NG
          o The transition of current applications based on the HTTP/1.x
            infrastructure to the HTTP-NG infrastructure

       Support for transition at the application layer can be considered to
       be a special case of the larger question of support for evolvability,
       which is one of the primary design goals for HTTP-NG. Therefore, the
       claim for evolvability can to a certain extent be evaluated by HTTP-
       NG's capability of supporting applications in transition from the
       existing infrastructure to HTTP-NG.

       Support for transition at the infrastructure level is fundamentally
       different as this relies on interfacing features in the existing
       infrastructure and the NG substrate. Some techniques that should be
       considered for handling this task including but not limited to


       Frystyk et al                                                [Page 10]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


          o the HTTP/1.1 Upgrade header field
          o the HTTP Extension Framework
          o protocol-conversion gateways
          o directory services for locating HTTP-NG servers
          o DHCP for locating HTTP-NG servers
          o new DNS record(s) to indicate availability of NG at a given
            server
          o new URI scheme(s)

       No single technique is likely to provide the full answer, but some
       combination of these and other techniques may well be sufficient to an
       overall reliable transition between the two infrastructures.


       6. References

       [1]  T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer
            Protocol -- HTTP/1.0", RFC 1945, W3C/MIT, UC Irvine, W3C/MIT, May
            1996
       [2]  B. Carpenter, "Architectural Principles of the Internet", RFC
            1958, June 1996
       [3]  R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee,
            "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, U.C. Irvine,
            DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
       [4]  H.F.Nielsen, J. Gettys, A. Baird-Smith, E. Prud�hommeaux, H. Lie,
            and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1,
            and PNG", Proceedings of ACM SIGCOMM '97, Cannes France,
            September 1997
       [5]  K. Moore, P. Faltstrom, "On the use of HTTP as a Substrate for
            Other Protocols", Internet Draft, August 1998, draft-iesg-using-
            http-00.txt. This is work in progress.
       [6]  B. Janssen, H.F.Nielsen, M.Spreitzer, "HTTP-ng Architectural
            Model", August 1998, draft-frystyk-httpng-arch-00.txt. This is
            work in progress.
       [7]  D. Larner, "HTTP-ng Web Interfaces" (limited prototype used in
            testbed), Internet Draft, August 1998. draft-larner-
            nginterfaces-00.txt. This is work in progress.
       [8]  B. Janssen, "HTTP-ng Binary Wire Protocol", Internet Draft,
            August 1998, draft-janssen-httpng-wire-00.txt. This is work in
            progress.
       [9]  J. Gettys, H.F.Nielsen, "The WebMux Protocol", Internet Draft,
            August 1998, draft-gettys-webmux-00.txt. This is work in
            progress.
       [10] D.Veillard, "Design of HTTP-ng Testbed", W3C Note, 10 July 1998
       [11] M.Spreitzer, H.F.Nielsen, "Short- and Long-Term Goals for the
            HTTP-NG Project", W3C Note, 27 March 1998
       [12] Minutes from HTTP-NG BOF at the IETF Chicago Meeting, August 24,
            "http://www.w3.org/Protocols/HTTP-NG/1998/08/HTTP-NG-BOF-
            Minutes.html"


       Frystyk et al                                                [Page 11]


       INTERNET-DRAFT             HTTP-NG Overview Tuesday, November 17, 1998


       7. Acknowledgements

       This work draws heavily on the work of the whole Protocol Design Group
       of the W3C HTTP-NG Activity notably including contributions from Paul
       Bennett, Dan Larner, and Paula Newman. Larry Masinter also made
       valuable contributions.


       8. Authors

       Henrik Frystyk Nielsen
       World Wide Web Consortium
       MIT Laboratory for Computer Science
       545 Technology Square
       Cambridge, MA 02139, USA
       Email: frystyk@w3.org

       Mike Spreitzer
       Xerox Corporation
       Palo Alto Research Center
       3333 Coyote Hill Road
       Palo Alto, California 94304, USA
       Email: spreitze@parc.xerox.com

       Bill Janssen
       Xerox Corporation
       Palo Alto Research Center
       3333 Coyote Hill Road
       Palo Alto, California 94304, USA
       Email: janssen@parc.xerox.com

       James Gettys
       World Wide Web Consortium
       MIT Laboratory for Computer Science
       545 Technology Square
       Cambridge, MA 02139, USA
       Email: jg@w3.org


       Frystyk et al                                                [Page 12]