WD-HTTP-NG-goals-19980327 21.9 KB

Raw Blame History Permalink

<HTML>
<HEAD>
  <TITLE>Short and Long term Goals for the HTTP-NG Project</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000">
<P>
<H3 align='right'>
  <A HREF='http://www.w3.org/'><IMG border='0' align='left' alt='W3C' src='http://www.w3.org/Icons/WWW/w3c_home'></A>WD-http-ng-goals-19980327
</H3>
<P>
<BR>
<H1 align='center'>
  Short- and Long-Term Goals for the HTTP-NG Project
</H1>
<H3 align='center'>
  W3C Working Draft 27-March-1998
</H3>
<P>
<DL>
  <DT>
    This version:
  <DD>
    <A HREF='http://www.w3.org/TR/1998/WD-http-ng-goals-19980327'>http://www.w3.org/TR/1998/WD-http-ng-goals-19980327</A>
  <DT>
    Previous version:
  <DD>
    None
  <DT>
    Latest version:
  <DD>
    <A HREF='http://www.w3.org/TR/1998/WD-http-ng-goals'>http://www.w3.org/TR/1998/WD-http-ng-goals
    </A>
  <DT>
    Editors:
  <DD>
    <A HREF="http://www.parc.xerox.com/csl/members/spreitze/">Michael Spreitzer</A>
  <DD>
    <A HREF="http://www.w3.org/People/Frystyk/">Henrik Frystyk Nielsen</A>
</DL>
<H2>
  Status of This Document
</H2>
<P>
This draft specification is a work in progress representing the current consensus
of the W3C HTTP-NG Protocol Design Group. This is a W3C Working Draft for
review by W3C members and other interested parties. Publication as a working
draft does not imply endorsement by the W3C membership.
<P>
This document describes the short- and long-term goals for the work of the
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/PDG/">HTTP-NG Protocol
Design Working Group</A> (<A HREF="http://cgi.w3.org/MemberAccess/">Members
Only</A>). The document does not describe an architecture, rather it describes
the goals and requirements of a potential new generation of the HTTP protocol
and how we intend to evaluate these goals.
<P>
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite W3C Working Drafts as
other than "work in progress".
<P>
Note: As working drafts are subject to frequent change, you are advised to
reference the above URL for "Latest version" rather than the URLs for specific
working draft versions themselves. The latest version URL will always point
to the most current version of this draft.
<P>
Comments on this specification may be sent to
&lt;<A HREF="mailto:www-http-ng-comments@w3.org">www-http-ng-comments@w3.org</A>&gt;.
<H2>
  Part I Long Term Goals
</H2>
<H3>
  Introduction
</H3>
<P>
The goal of the HTTP-NG project is to test the hypothesis that the current
HTTP/1.X approach to web protocol design can be replaced with one in which
the Web is expressed as a particular set of interfaces on top of a generic
distributed object system designed with Internet constraints in mind. We
expect that a layered approach would bring many benefits to the Web, including
easier evolution of the protocol standard, interface technology that would
facilitate Web automation, easier application building, and so on. We also
intend to do other pressing HTTP work, notably including further performance
improvements, in the context of HTTP-NG. Even if we find that the main hypothesis
is false, we hope, expect, and intend that much of the experience we gain
will be useful to other design approaches.
<P>
HTTP-NG has to support (at least) the same architectural features of the
Web that HTTP/1.X does. As opposed to the matters of degree below, these
are cast herein as yes/no issues: does the protocol do a required thing?
These yes/no issues are listed in the second section of this document.
<P>
To prove the main point, HTTP-NG has to actually go out there and replace
HTTP/1.X. There has to be a way to deploy HTTP-NG into the existing web that
is using HTTP/1.X (in addition to all the non-HTTP protocols), such that
HTTP-NG can co-exist, interoperate, capture a growing fraction of the traffic,
and eventually supplant HTTP/1.X.
<P>
For HTTP-NG to take over from HTTP/1.X, it does not suffice for us to make
it technically possible (although that is certainly an important goal); in
addition, people have to want to switch. For people to want to switch to
it, it has to be better than HTTP/1.X. There are many dimensions in which
protocols can be compared. There are people in many different roles, and
they have different utility functions. In addition to the yes/no issues mentioned
above, web protocols can be compared in several more-is-better dimensions.
In a more-is-better dimension, the question is a matter of degree. The
more-is-better dimensions are further broken down into "critical" and
"non-critical". We expect HTTP-NG will have to be significantly better than
HTTP/1.X in each of the critical dimensions, and at least as good as HTTP/1.X
in most of the non-critical dimensions. We look forward to enriching future
versions of this document with better statements about the absolute and relative
importance of these axes with knowledge delivered by the Web Characterization
Group. We also hope they can give us many cases where there is a definable
"good enough".
<P>
The Web, in the fullness of its actual use, is expanding to include more
general distributed applications, which are being layered on top of HTTP,
often with unnecessary performance costs, functionality warts, and lack of
generality resulting. By moving the Web to a generic distributed object system
basis, we hope to enable these applications to use the generic object system
directly. In particular, we would like the generic distributed object system
to be simple, yet rich enough to meet the semantic and performance requirements
of CORBA, DCOM, and Java RMI. This doesn't mean we intend to unify the object
models of CORBA, DCOM, and Java RMI (which are somewhat diverse and warty).
It means that we'd like to move HTTP onto a generic distributed object system
of analogous strength, so that programmers (and middleware-owning organizations)
willing to switch could get roughly the same jobs done (at least). Thus,
the axes for evaluation below include the issues that would have to be done
well to make a good generic distributed object system. Furthermore, deployment
of HTTP-NG will be much easier if existing middleware products (CORBA, DCOM,
and Java RMI) can be made useful for HTTP-NG with little effort or lossage.
<H3>
  Gotta-Have-It Axes for Evaluating HTTP*
</H3>
<OL>
  <LI>
    HTTP transports request-response interactions between a client and a server.
  <LI>
    The interaction is with an object called, in the context of the Web, a
    "resource". A server animates multiple resources.
  <LI>
    The client and server in any given transaction are not necessarily the "ultimate"
    client or server; each may be acting as a proxy for another agent. By "proxy"
    we mean any program that acts as a server to some client(s), and, on their
    behalf, as one or more clients to other server(s). A proxy services requests
    internally or by passing them on (possibly transformed). When message traffic
    is secured, a proxy is trusted with the plaintext content of the messages.
  <LI>
    We use the term "origin server" for a server that is not a proxy.
  <LI>
    An origin server may be a gateway into another system.
  <LI>
    Proxies may or may not be semantically transparent to other clients and server.
    The level of transparency is controlled through the Web interfaces.
  <LI>
    Tunnels are intermediates that do not in any way take part in the HTTP
    communication but merely act as transport relays.
  <LI>
    The semantic content of certain request-response interactions may be cached
    to improve both the latency and traffic load presented by equivalent requests
    in the future. There is a way to determine when a cache entry is no longer
    valid (in the current web this is not very accurate). Document retrieval
    interactions are cachable, subject to the server's assent. Caching can be
    semantically transparent when required by all parties. It must be possible
    for clients to detect any potential relaxation of semantic transparency.
    In particular, semantic transparency can only be relaxed when explicitly
    requested by client or origin server. Furthermore, when semantic transparency
    is relaxed by a cache or client, an explicit warning is given to the end
    user [what's an "end user"?].
  <LI>
    A reference to a resource is called a Uniform Resource Identifier (URI).
    A URI conveys the information needed to contact a particular resource and
    conduct an interaction with it. Many different schemes for resource access
    are possible in the Web, and URIs are structured in a way that reflects this.
    A URI is a character string (wrt unspecified character set) that consists
    of a short, centrally-administered scheme name (such as "http"), a colon
    (":"), and finally a scheme-specific following the URI syntax rules. A URI
    may be either name-like or address-like. &nbsp;HTTP has the option to support
    any URI scheme - either directly via origin servers or via gateways into
    other access schemes. "http" is one of the access schemes available in the
    Web. The character set and encoding issues are specified for http URIs, in
    a way that is at least as expressive as specifying the use of US-ASCII. An
    http URI is address-like: it contains a DNS name, an optional TCP port number,
    and a server-relative resource identifier. Some URIs --- in particular, http
    ones for the introductory resources for English-speaking individuals,
    organizations, products, projects, and so on --- are user-friendly (short,
    unambiguous, meaningful) enough to be printed on billboards, business cards,
    airplanes, and so on.
  <LI>
    There is no central administration of all the servers nor all the clients
    in the web. Anybody can put up a server (of any kind), and anybody can run
    a client (of any kind). There is no global coordination of administration
    and/or security domains (beyond the minimal structure given us by the Internet).
    There is no expectation that every party will be using the same security
    systems. There is no expectation that every party will be running the same
    version of the relevant software, nor even speaking the same version(s) of
    the relevant protocols. Programs and protocols are developed independently
    by many parties and deployed into the existing web in such a way that they
    can interoperate to the degree that it makes sense.
  <LI>
    Message traffic can be secured via SSL (among, perhaps, other means).
  <LI>
    Before granting access to a resource, a server can require a client to
    authenticate itself. (This is at a higher layer than is secured by SSL, which
    is often used in a way that authenticates the server to the client but not
    vice versa). Two schemes are available for use here, and the server chooses
    which one(s) are acceptable. In one scheme, the client simply supplies a
    name and password for an account maintained by (or at least accessed by)
    the server. The other scheme avoids sending passwords by using a secure hash
    of them (and other data) instead.
  <LI>
    A resource can migrate to a different server without breaking all the URIs
    printed in the world, in a way that requires the resource's former server
    to retain and report only a small amount of information about that resource
    (such as a new URI, as opposed to something like a full copy of the resource).
  <LI>
    Even though an http URI includes a DNS name, a single machine can be the
    origin server for URIs that use many different DNS names.
  <LI>
    An HTTP message can contain a MIME-typed value.
  <LI>
    A common interaction is GET, which fetches a MIME-typed value.
  <LI>
    The MIME type, natural language (if applicable), and other aspects of the
    particular value returned in a response are functions of a feature called
    "content negotiation", which is about returning the "best" representation
    from among several available. The selection may be performed by either client
    or server. To help the server make a good selection, the client can supply,
    in a request, information on its preferences for MIME type, character set,
    natural language, and other aspects. When the server makes a selection, the
    response indicates which information from the request affected the choice,
    so that a cache can apply the cached interaction as broadly as possible.
    To enable the client to make the selection, the server can return a list
    of the available alternatives and their characteristics.
  <LI>
    Content negotiation and especially its interactions with caching must be
    fully understood
  <LI>
    A common interaction is POST, in which the request conveys some name-value
    pairs of character strings, and the response returns a MIME-typed value (subject
    to content negotiation).
</OL>
<H3>
  More-is-Better Axes for Evaluating HTTP*
</H3>
<OL>
  <LI>
    (critical) Networking performance. Specifically, latency and bandwidth. (Common
    sense follows.) When optimizing the common cases at the expense of the less
    common ones, we can't let the less common ones get too bad --- and not even
    very bad at all if they're still fairly common. An example of the first caution
    is that when using cache techniques, things should not be very bad when there
    is a cache miss; an example of the second is that when cache misses are still
    fairly frequent (e.g., when a client caches information about servers recently
    used, a large fraction of requests (1/4?) are to new servers and thus miss
    in that cache), things should work pretty darned well even when there's a
    cache miss.
  <LI>
    Local processing cost. That is, demands on CPU, memory, disk, etc of clients
    and servers. Sadly, this is sometimes antagonistic with minimizing network
    bandwidth requirements.
  <LI>
    (critical) Scalability. That is, the applicability to a web that truly is
    world-wide, and still growing quickly. This involves not only the general
    efficiency issues of the previous two items, but also requirements to handle
    (a) large numbers of servers and clients, and (b) the expected patterns of
    interaction among them.
  <LI>
    (critical) Modularity. This is a very important kind of simplicity, which
    the current HTTP lacks. This includes both layering and other kinds of
    modularity.
  <LI>
    (critical) Evolvability. The most used protocol on the Internet (HTTP) is
    being asked to serve an ever-growing variety of purposes. It has already
    absorbed several evolutions, and more are coming. This axis is about how
    easy it is to make a protocol evolution "in isolation", and how easy it is
    to make a correct evolution in the full context of the web (i.e., other
    evolutions made, often independently, in the past, concurrent present, and
    future).
  <LI>
    Suitability for extension by WebDAV. This axis is not about extensibility
    in the abstract, but readiness for a particular extension that is of great
    importance. This may be a non-trivial issue because WebDAV changes the nature
    of the web, from one where clients mainly read/use resources to one where
    clients also author resources.
  <LI>
    (critical) Expressiveness. The RPC layer needs to enable expression of interfaces
    equivalent to current HTTP, and of the extensions we see coming down the
    pike. Easily identified extensions include the work of the webdav, acap,
    ipp, and mmusic WGs of the IETF. This is not a matter of whether the interface
    can be expressed at all (it always can, although sometimes with the loss
    of a small or a large amount of detail), but how useful the expression is.
  <LI>
    (critical) Security. This includes the maximum strengths available, the variety
    of choices available, and the flexibility of the negotiation of these choices.
    When looking at strength, don't ignore denial-of-service attacks. Should
    support both public key and secret key mechanisms. Must respect the fact
    that the web spans multiple, very independent security domains. It is desirable
    to support the full variety of policy making and enforcing structures of
    various organizations. This includes, and is certainly not limited to,
    facilitating the job of a firewall (and its administrator).
  <LI>
    Support of liberty. The HTTP design should place as few limits as possible
    on what a client or server does and who he/she/it requires/trusts to do things
    for him/her/it.
  <LI>
    Transport flexibility. It is desirable to be able to run the Web over transport
    protocols other than TCP. More different even than Transactional TCP,
    state-sharing TCP, and MUXing TCP. At least because there are people who
    want to use HTTP* over something other than the TCP-like protocols of the
    Internet. Perhaps also because we might find we can't get ideal TCP-like
    services from the Internet initially, and we'll have to support a gradual
    shift (e.g., from TCP to T/TCP).
  <LI>
    Support for resource migration: ability to redirect requests, to update pointers,
    to garbage collect unreferenced resources and/or forwarding pointers. Supporting
    migration is fairly important, but garbage collection is less important.
  <LI>
    Support for resource replication. This naturally includes support for maintaining
    an appropriate consistency between a cache and its sources. This might include
    ways for a client to pick a good replica. This might include fine-grained
    delegation of rights to caches. This may interact with the WebDAV extension.
  <LI>
    Support for privacy.
  <LI>
    Limited trust exposures. That is, how little trust has to be extended to
    other parties for a given party to get its job done.
  <LI>
    Support for nested and recursive RPCs. It would be a shame if the RPC mechanism
    prohibited, or introduced deadlocks in, these cases.
  <LI>
    Support for small clients and/or small servers. For embedded applications,
    where a client or server can't call on much CPU, memory, disk, etc.
  <LI>
    Support for internationalization.
  <LI>
    Support for Quality Of Service negotiations. As in ATM and IP (i.e., RSVP).
    This is relatively unimportant.
  <LI>
    Support for application robustness. An application should be able to control
    its usage of various resources. This may involve limiting or shedding load
    at several levels of abstraction. It may, in general, be useful to let the
    peer know the reason when an interaction is rejected or aborted due to resource
    limits.
  <LI>
    Support for intellectual property rights management, including payment.
  <LI>
    Support for disconnection operation.
</OL>
<H2>
  Part II Short Term Goals
</H2>
<P>
By the end June 1998 we intend to produce a design and prototype that demonstrate
the following things.
<OL>
  <LI>
    The three-layer structure - transport, RPC, and web interfaces - described
    in the
    <A HREF="http://www.w3.org/Protocols/HTTP-NG/Activity.html#Charter">HTTP-NG
    project charter</A>. We do not expect that any of the details involved (e.g.,
    MUX design, choice/design of RPC system, particular web interfaces) will
    necessarily appear in the final HTTP-NG. The point here is simply to demonstrate
    feasibility with this kind of technology.
  <LI>
    The performance and efficiency gains of the MUX and W3NG protocols. These
    are not the only performance gains that could be addressed for HTTP-NG in
    general - but the limited time frame permits examination of only a few of
    the identifiable opportunities. Indeed, since these are new protocols, it's
    not at all clear that we'll have time to implement and tune them to the point
    where they show actual improvements. Furthermore, there has been some debate
    whether we can expect to measure the improvements in our testbed, due to
    both the issues of creating circumstances under which these protocols give
    improvements and the magnitude of the improvements. Finally, since we do
    not intend to focus on local processing costs, there is the issue of how
    to make convincing measurements of the aspects on which we *would* focus.
  <LI>
    The scalability of the existing web (except for local processing cost
    considerations). That is, we'll follow the existing web's completely
    decentralized architecture, and we won't make the networking costs noticeably
    worse. We are ignoring local processing costs only as a matter of expediency
    - we can only work on so much in the given time.
  <LI>
    The extensibility of existing distributed object technology. That is, we
    won't try to add any new features corresponding to HTTP+(PEP|mandatory)'s
    extensibility by optional/required headers (which is not to say that existing
    technology can't model them in any way). We will show ways in which existing
    distributed object technology can handle extensibility concerns.
</OL>
<P>
The prototype will be tested/demonstrated in a testbed. The testbed includes
modified versions of existing servers (and clients, if we have the time),
where an ILU implementation of the NG protocol substack is available instead
of or in addition to the server's original HTTP substack. The testbed will
also include robotic clients, to produce controlled loads. The WCG will deliver
characterizations of the loads for us to apply.
<P>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">
Copyright</A> &nbsp;&copy;&nbsp; 1998 <A href="http://www.w3.org">W3C</A>
(<A href="http://www.lcs.mit.edu">MIT</A>,
<A href="http://www.inria.fr/">INRIA</A>,
<A href="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer">liability,</A>
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks">trademark</A>,
<A href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use </A>and
<A href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing </A>rules apply.
  <HR>
<ADDRESS>
  <A HREF="http://www.parc.xerox.com/csl/members/spreitze/">Michael
  Spreitzer</A>, <A HREF="http://www.w3.org/People/Frystyk/">Henrik Frystyk
  Nielsen<BR>
  </A>@(#) $id: Overview.html,v 1.12 1997/11/11 02:27:32 frystyk Exp $
</ADDRESS>
</BODY></HTML>